Erlang TFTP CVE-2026-21620 Path Traversal: Patch and Harden Now

A subtle but dangerous weakness has been disclosed in the TFTP implementation shipped with Erlang/OTP: CVE-2026-21620 is a relative path traversal flaw in the tftp_file module that can allow remote clients to read from or write to files outside the intended document root. The issue arises from an undocumented initial-state option that concatenates the requested filename to a configured root path without normalizing or enforcing directory boundaries, enabling the classic "../" attack. Erlang maintainers have released a patch that constrains local file operations to the configured directory tree and clarified documentation and defaults; administrators and developers who run the TFTP server bundled with Erlang/OTP need to treat this as a high-priority configuration and patching task even if the official severity scores record the vulnerability as low based on impact metrics.

Background​

Trivial File Transfer Protocol (TFTP) is an extremely lightweight file transfer protocol commonly used for network bootstrap, firmware updates, embedded systems, routers, switch images, and other constrained environments where a full FTP or HTTP stack is unnecessary. Because it is designed for simplicity—no authentication, simple read/write semantics, and a very small code footprint—TFTP servers rely heavily on correct configuration and sandboxing to avoid exposing host files.
Path traversal (a.k.a. directory traversal) vulnerabilities with TFTP servers are historically common: server implementations that simply concatenate a client-supplied filename to a server-side root path without normalization can be made to access files outside the intended directory by including sequences such as "../" (or their platform equivalents). On Unix-like systems, these directory components move upward in the path hierarchy; on Windows, both forward and backward slashes can sometimes be accepted. The result is unauthorized disclosure or modification of files, and in some scenarios it can lead to privilege escalation if system files are replaced or sensitive credentials are written.
Erlang/OTP includes a TFTP application designed for developers and networked systems that use Erlang as the runtime. The affected code is in the tftp_file module, where an initial state option named root_dir was intended to restrict file operations to a directory. In practice the request-handling logic concatenated the incoming request filename directly to that directory path, allowing a crafted filename to break out of the directory and reach arbitrary filesystem locations accessible to the Erlang VM process.

---

What happened: technical summary of CVE-2026-21620​

The vulnerable behavior​

• The TFTP server implementation exposed an undocumented initial state option—[{root_dir, Dir}]—meant to indicate a local root directory for file operations.
• When that option was set, the implementation concatenated the client-supplied filename directly onto Dir without normalizing path separators or rejecting upward traversal tokens.
• A remote attacker able to send TFTP read or write requests could include "../" components in the filename to navigate above Dir and access files elsewhere on the filesystem that the Erlang runtime user can read or write.
• The default TFTP server configuration, by contrast, was clarified to allow read and write access to any files readable or writable by the Erlang VM user—meaning that simply running the server under an unprivileged account is not a sufficient safeguard unless combined with filesystem isolation.

The fix​

• Erlang/OTP maintainers implemented a change that makes the root_dir option enforce a real directory boundary: local file operations are now restricted to Dir and its subdirectories.
• Documentation for the TFTP application was updated to make default behavior and configuration risks explicit.
• The fix was packaged as a tftp application update (tftp-1.1.1.1 in the OTP patch series) and rolled into relevant OTP point releases.
• The fix and supporting commits were reviewed and merged by the Erlang/OTP team.

Scope and affected versions​

• The vulnerability is present in the TFTP implementation as shipped in a wide range of OTP releases where the tftp application exists and the problematic code path is used.
• Systems running older OTP releases or instances that included the tftp application (or inets components with tftp) prior to the fix are potentially vulnerable if they:
• Run a TFTP server using the built-in tftp application, and
• Either used the [{root_dir, Dir}] option in a way that was intended to constrain file operations, or relied on defaults that expose filesystem access.
• The maintainers note that the initial-state option had been undocumented, so the number of deployments that relied on it in production is likely small, but any exposed TFTP service that runs with broad filesystem privileges should be assumed at risk until patched and reconfigured.

---

Why this matters: impact and risk analysis​

Path traversal failures in TFTP servers are more than theoretical: TFTP's lack of authentication combined with its use in network boot and device provisioning makes it attractive to attackers scanning networks for exposed services. The practical impact depends on two factors:

• The privileges of the user running the Erlang VM (and therefore the TFTP server).
• Whether the TFTP server binds to public interfaces or is reachable from untrusted networks.

If the VM runs as a privileged user or as a system account with write access to important locations, an attacker could use the traversal to overwrite boot scripts, configuration files, or service binaries—creating opportunities for persistence, further compromise, or denial-of-service. If the VM runs as a strictly unprivileged service account and the filesystem permissions restrict access to only innocuous directories, the practical confidentiality/integrity impacts are limited. That said, the ability to read arbitrary files can still disclose secrets such as keys, configuration tokens, or personally identifiable information if the service account can read them.
Key risk factors:

• Exposed service: Any TFTP server reachable from the Internet or large internal networks is high risk. Attackers can discover TFTP servers during network scans and attempt traversal patterns automatically.
• Shared runtime: Erlang is often embedded into applications that run multi-tenant services; a compromised TFTP service in such a runtime could have outsized effects.
• Default misconfiguration: The TFTP defaults documented by the maintainers make it clear that the default server configuration can grant wide read/write access. Administrators who left the server running without explicit lockdown have increased exposure.

Mitigating factors:

• The maintainers’ fix ensures that the documented root_dir works as originally intended.
• The vulnerability appears to be a classic traversal exploit rather than an arbitrary code execution primitive; in many workflows it is limited to information disclosure or file tampering on the filesystem level rather than immediate remote code execution.
• The issue is unlikely to be widespread via the undocumented option alone, but the clarification that default configuration is permissive elevates the need for action.

---

Practical guidance: detection, mitigation, and remediation​

If you manage systems that include Erlang/OTP or run Erlang-based appliances, follow these steps immediately.

1. Inventory: find exposed TFTP instances​

• Search your infrastructure for services responding on UDP port 69 (the standard TFTP port).
• Look for Erlang-based appliances or software stacks that embed the OTP runtime and might expose the bundled TFTP application.
• Check configuration management databases, container images, and device images for the presence of the tftp application or inets/tftp modules.

2. Patch: apply the Erlang/OTP update​

• Identify affected OTP versions on your systems and determine if the tftp application is present.
• Install the official patch or updated OTP point release that includes the tftp application fix (the maintainers released a tftp-1.1.1.1 patch in the OTP patch stream).
• For packaged distributions (Linux distros, containers), apply vendor-supplied packages or rebuild images with the patched OTP packages.
• Prioritize internet-facing and cross-network-exposed hosts first.
• If you cannot immediately patch, temporarily disable the TFTP service or firewall port 69/udp until you can update.

3. Configuration hardening​

• Avoid the default server configuration unless you have explicitly evaluated its implications. The default can open read and write access to files accessible by the VM user.
• Where possible, use an OS-level sandbox (chroot or container) or run the Erlang VM as a dedicated, minimal-privilege user account whose filesystem view and permissions are tightly constrained.
• If you must use a root_dir option, verify that it is set after applying the fix and test that traversal attempts are rejected. After patching, confirm that local file operations remain within the intended directory tree.

4. Network controls​

• Restrict access to TFTP to trusted subnets and management networks only.
• Use firewall rules to permit TFTP traffic only from authorized hosts (e.g., PXE servers, network management stations).
• Monitor and restrict access via network access control lists or host-based firewalls on critical infrastructure.

5. Detection and logging​

• Enable and centralize logs for TFTP activity where possible. Look for unusual filenames containing "../" or other traversal sequences.
• Set up IDS/IPS rules to flag TFTP requests with directory traversal patterns or unusually long filenames.
• If file integrity monitoring is used on systems that run the TFTP server, investigate any unexpected modifications to system files or configuration files.

6. Incident response if you find evidence of exploitation​

• Immediately isolate the host from the network to prevent further exfiltration or tampering.
• Preserve logs and run forensic snapshots to capture the state of the filesystem and any modified files.
• Look for indicators of additional compromise (web shells, scheduled tasks, unauthorized services).
• Rebuild or reinstall compromised hosts from a known-good image and rotate any secrets or keys that may have been exposed.

---

For developers: secure-by-design recommendations​

Erlang/OTP users who embed the TFTP server into products or appliances should adopt secure coding and deployment patterns to reduce the attack surface.

• Do not assume undocumented options are safe to rely on. Documented behavior is the contract you should depend on; if you need nonstandard behavior, prefer explicit, well-tested configuration options.
• Validate and normalize all user-supplied paths before using them in filesystem operations. Use platform-native canonicalization APIs and check that the canonical path begins with the intended canonical root directory.
• Adopt least privilege for runtime accounts and prefer running file-serving code inside containers or chroots that limit what the process can access.
• Audit third-party libraries and runtime components in your product supply chain; a vulnerability in a library (e.g., tftp module) can become a product-level security defect.
• Provide fail-safe defaults: servers shipped with products should deny write access by default and must never expose broad filesystem write permissions to unauthenticated network clients.

---

Detection recipes and hunting queries​

Here are practical, non-exploit detection ideas for enterprise defenders and operators—tailor them to your environment and logging capabilities.

• IDS/IPS signatures: flag UDP/69 traffic whose filename fields include "../" or URL-encoded variants ("%2e%2e/").
• SIEM query: search logs for TFTP requests that contain path traversal tokens or unexpected long filenames.
• File integrity monitoring: alert on changes to privileged paths (e.g., /etc, /bin, /usr/local/bin, boot config directories) originating from the Erlang VM process owner.
• Network scanning: use controlled scanning to detect TFTP servers in your environment and mark them for patching or access restriction.

Avoid sending malicious probes to third-party hosts; always scan only your own network or hosts under explicit authorization.

---

Why this disclosure matters beyond Erlang​

This vulnerability is a reminder of two recurring themes in modern software security:

• Small, simple protocols like TFTP are deceptively dangerous. Their simplicity reduces the surface needed to implement them, but also means that a tiny logic error (a concatenation without canonicalization) can expose critical host resources.
• Default configurations matter. Software defaults that favor convenience (allowing read/write to any file the runtime user can access) significantly increase risk when combined with network-facing services.

Organizations that ship network services must treat sane defaults and clear documentation as part of their security posture. The maintainers’ post-fix documentation changes are an important corrective step—developers and deployers now have clearer expectations about how the TFTP service behaves and what must be done to harden it.

---

What we know about exploitation in the wild​

At the time of disclosure there is no public evidence of widespread weaponization or exploitation in the wild tied directly to CVE-2026-21620. The vulnerability is a path traversal issue—an allowed remote read/write where permitted by server privileges—and such vulnerabilities are commonly scanned for and abused once widely publicized. Enterprises should treat the lack of current exploit reports as temporary and act on the assumption that scanning and opportunistic exploitation attempts will increase after disclosures propagate.
If you operate a TFTP service in a production environment, do not assume that a low CVSS score (which may reflect limited impact in some scoring models) equates to low operational risk. The practical consequences depend on environment configuration and where the server is reachable.

---

Responsible disclosure timeline and credits​

Security researchers reported the issue to the maintainers; the maintainers corrected the file-handling logic and improved documentation, and updates were released in the OTP patch stream. The public advisory and patch series identify the reporter and the pull request(s) that implemented the fix. This coordinated approach—discovery, responsible reporting, patching, and documentation—represents the best practice in vulnerability management and reduces friction for downstream packagers and operators.

---

Checklist: immediate actions for operators (quick reference)​

• If you run TFTP as part of an Erlang/OTP deployment:
• Stop or block access to TFTP ports from untrusted networks until patched.
• Apply the official tftp application patch or upgrade to a patched OTP release.
• Verify that any use of root_dir (if required) properly restricts file operations after the patch.
• Run hunts for suspicious TFTP requests with traversal tokens in logs.
• Ensure the Erlang VM runs under a restrictive service account and that file permissions limit what the VM process can access.
• If you ship products that include Erlang/OTP:
• Rebuild images with the patched tftp component.
• Update customer advisories and provide clear instructions for updating appliances.
• Consider disabling TFTP functionality by default or limiting it to specific, authenticated workflows.

---

Longer-term recommendations for system architects​

• Treat legacy protocols like TFTP as high-risk components when used on modern networks; replace them with authenticated, integrity-checked transfer mechanisms where practical.
• Standardize on packaging and update workflows that allow rapid distribution of security patches for runtime components such as Erlang/OTP.
• Introduce runtime confinement for language VMs used in production services (OS-level sandboxes, minimal filesystem images, container runtimes).
• Maintain a continuously updated inventory of network-exposed services to avoid surprises from rarely-used components such as embedded TFTP servers.

---

Conclusion​

CVE-2026-21620 is a vivid example of how a simple path-concatenation mistake in a small module can create outsized risk for any system exposing that functionality. Although the vulnerability arises in an undocumented option and the maintainers' fix reduces the chance of accidental misuse, the public disclosure should prompt immediate action: inventory, patch, restrict, and monitor.
Administrators should treat this disclosure as a prompt to re-evaluate TFTP's place in their environment: is it necessary; who can reach it; and what files does the associated runtime account actually control? Developers and product teams should treat the fix as a reminder to document options clearly, enforce canonical path handling, and ship safe defaults. The steps to harden, patch, and detect misuse are well understood; implementing them promptly will materially reduce the operational risk posed by this class of vulnerability.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center