CVE-2026-66835 in OTPinfo

Summary

by MITRE • 09/01/2026

Path Equivalence vulnerability in Erlang/OTP inets httpd allows a remote unauthenticated attacker to read files inside a mod_auth protected directory by prefixing the request path with an extra slash.

httpd_request:validate_uri/1 normalises the request URI with uri_string:normalize/1, which performs RFC 3986 dot-segment removal but does not collapse empty path segments, so a doubled slash survives. mod_alias:real_name/3 concatenates the document root with that URI, and mod_auth:secret_path/3 then decides whether the result lies inside a protected directory block by running the configured directory path as an unanchored regular expression against it. The doubled slash breaks the contiguous substring the regex needs, so the request is treated as unprotected and no authentication challenge is issued, while mod_get opens the same path and the operating system collapses the doubled slash and returns the protected file. The same path mismatch also evades the per-path accounting in mod_security.

This issue affects OTP from OTP 17.0 before OTP 27.3.4.17, from OTP 28.0 before OTP 28.5.0.6, and from OTP 29.0 before OTP 29.0.6, corresponding to inets from 5.10 before 9.3.2.7, from 9.4 before 9.6.2.3, and from 9.7 before 9.7.2. Whether OTP before OTP 17.0, corresponding to inets before 5.10, is affected is unknown.

If you want to get the best quality for vulnerability data then you always have to consider VulDB.

Analysis

by VulDB Data Team • 09/01/2026

The vulnerability described constitutes a critical path equivalence flaw within the Erlang/OTP inets httpd module, specifically impacting versions prior to OTP 27.3.4.17, OTP 28.5.0.6, and OTP 29.0.6. This security defect allows remote unauthenticated attackers to bypass authentication mechanisms protecting sensitive directories by exploiting inconsistencies in URI normalization and path validation logic. The core of the issue lies in how the httpd_request:validate_uri/1 function processes incoming request URIs using uri_string:normalize/1. While this function correctly implements RFC 3986 dot-segment removal, it fails to collapse empty path segments resulting from consecutive slashes. Consequently, a request URI containing double slashes, such as //protected/resource, retains these redundant separators rather than being normalized to /protected/resource.

The exploitation of this flaw relies on the subsequent processing steps within mod_alias and mod_auth modules. When mod_alias:real_name/3 constructs the file system path by concatenating the document root with the unnormalized URI, it preserves the double slashes in the resulting string. However, when mod_auth:secret_path/3 evaluates whether this constructed path falls within a protected directory block, it employs an unanchored regular expression to check for substring matches against the configured directory paths. The presence of the extra slash disrupts the contiguous character sequence required by the regex pattern. For instance, if the protected directory is defined as /var/www/html/secret, the regex expects this exact string without interruption. A path like /var/www/html//secret does not match because the double slash breaks the substring continuity, causing the authentication check to fail silently and treat the request as unprotected.

Despite bypassing the authentication layer, the actual file retrieval operation proceeds through mod_get, which interacts with the underlying operating system's file handling routines. Modern operating systems typically normalize path components during file access operations, effectively treating /var/www/html//secret identically to /var/www/html/secret. As a result, while the Erlang application logic incorrectly determines that no authentication is required, the OS successfully opens and serves the protected file contents to the attacker. This discrepancy between the application-level security check and the operating system's path resolution creates a direct authorization bypass, allowing unauthorized access to restricted resources without valid credentials.

The operational impact of this vulnerability extends beyond simple data exfiltration. Because mod_security also relies on similar per-path accounting mechanisms that are susceptible to the same path equivalence issue, attackers can evade logging and monitoring controls associated with sensitive resource access. This evasion capability complicates incident response efforts by obscuring the true scope of unauthorized access from security information and event management systems or audit logs. The vulnerability is classified under CWE-284 Improper Access Control, as it represents a failure to enforce proper restrictions on authenticated users regarding specific resources, specifically through an authorization bypass technique. In terms of MITRE ATT&CK framework mapping, this behavior aligns with T1078 Valid Accounts and potentially T1530 Data from Local System Archives if the accessed files contain sensitive data, though the primary vector is unauthorized access via path manipulation rather than credential theft.

Mitigation strategies must focus on updating the Erlang/OTP environment to patched versions that correct the URI normalization logic or adjust application-level configurations to enforce stricter path validation. Organizations running affected OTP releases should upgrade immediately to OTP 27.3.4.17, OTP 28.5.0.6, or OTP 29.0.6, which correspond to inets versions 9.3.2.7, 9.6.2.3, and 9.7.2 respectively. For environments where immediate patching is not feasible, administrators can implement compensating controls at the reverse proxy level before requests reach the Erlang httpd service. Configuring a front-end web server such as Nginx or Apache to normalize URIs by collapsing consecutive slashes into single slashes prior to forwarding them to the backend application will effectively neutralize this attack vector. Additionally, reviewing and hardening mod_auth configurations to use anchored regular expressions that account for potential path anomalies can provide an additional layer of defense against similar bypass attempts in other contexts.

Responsible

EEF

Reservation

08/17/2026

Disclosure

09/01/2026

Moderation

accepted

CPE

ready

EPSS

0.00000

KEV

no

Activities

very low

Sources

Might our Artificial Intelligence support you?

Check our Alexa App!