CVE-2026-66835 Overview
CVE-2026-66835 is a path equivalence vulnerability in the Erlang/OTP inetshttpd web server. A remote unauthenticated attacker can read files inside a mod_auth protected directory by prefixing the request path with an extra slash. The URI normalisation routine httpd_request:validate_uri/1 does not collapse empty path segments, so a doubled slash bypasses the regex-based directory check in mod_auth:secret_path/3. The operating system then collapses the doubled slash when the file is opened, returning the protected content without an authentication challenge. The flaw is tracked as CWE-50: Path Equivalence.
Critical Impact
Remote unauthenticated attackers can retrieve files from mod_auth protected directories over the network by inserting a single extra slash in the request path, defeating both authentication and mod_security per-path accounting.
Affected Products
- Erlang/OTP 17.0 before 27.3.4.17 (inets 5.10 before 9.3.2.7)
- Erlang/OTP 28.0 before 28.5.0.6 (inets 9.4 before 9.6.2.3)
- Erlang/OTP 29.0 before 29.0.6 (inets 9.7 before 9.7.2)
Discovery Timeline
- 2026-09-01 - CVE-2026-66835 published to NVD
- 2026-09-01 - Last updated in NVD database
Technical Details for CVE-2026-66835
Vulnerability Analysis
The vulnerability lives in the request-processing pipeline of inetshttpd. The function httpd_request:validate_uri/1 calls uri_string:normalize/1, which implements RFC 3986 dot-segment removal but leaves consecutive slashes intact. As a result, a request path like //protected/secret.txt survives normalisation with the doubled slash preserved.
Downstream, mod_alias:real_name/3 concatenates the document root with the URI, and mod_auth:secret_path/3 evaluates whether the resulting path falls inside a protected directory. That evaluation uses the configured directory path as an unanchored regular expression against the concatenated string. The extra slash breaks the contiguous substring the regex expects, so the request is classified as unprotected. No authentication challenge is issued.
Meanwhile, mod_get opens the same path, and the operating system collapses the doubled slash on the filesystem call, returning the protected file. The same mismatch also evades per-path accounting in mod_security.
Root Cause
The root cause is inconsistent path canonicalisation between the authorization decision and the file-serving action. URI normalisation preserves empty path segments, but the filesystem layer treats them as equivalent to a single slash. The authorization regex is not anchored and depends on exact substring matching, so any perturbation of the path that the OS later collapses creates a bypass.
Attack Vector
The attack is remote, unauthenticated, and requires only a single HTTP request. An attacker issues a GET request against a protected resource with an extra leading slash on the path segment covered by the mod_auth directory directive. The server serves the file without prompting for credentials.
// Security patch: canonicalize request path before mod_auth directory check
// File: lib/inets/src/http_server/httpd_request.erl
{error, _, _} ->
{error, {bad_request, {malformed_syntax, RequestURI}}};
URI ->
- {ok, URI}
+ {ok, collapse_uri_path_slashes(URI)}
+ end.
+
+%% Collapse consecutive slashes in the path component only.
+%% Uses uri_string:parse/1 to avoid mangling "://" in absolute URIs.
+collapse_uri_path_slashes([$/ | _] = Path) ->
+ %% Path-only form (the common case for httpd requests).
+ httpd_util:collapse_slashes(Path);
+collapse_uri_path_slashes(URI) ->
+ case uri_string:parse(URI) of
+ #{path := Path} = Parsed when map_size(Parsed) > 1 ->
+ %% Absolute URI — collapse only the path, recompose.
+ uri_string:recompose(Parsed#{path => httpd_util:collapse_slashes(Path)});
+ _ ->
+ %% Unparseable or path-only without leading slash.
+ httpd_util:collapse_slashes(URI)
end.
Source: GitHub OTP Commit 9641944a. The fix introduces collapse_uri_path_slashes/1, which routes through a new httpd_util:collapse_slashes/1 helper to normalise consecutive slashes before the mod_auth check runs.
Detection Methods for CVE-2026-66835
Indicators of Compromise
- HTTP request logs containing URI paths with two or more consecutive forward slashes (for example //, ///) targeting resources normally covered by mod_auth.
- Successful 200 OK responses to protected paths without a preceding 401 challenge or Authorization header in the same session.
- Access log entries for protected files where the recorded URI differs from the on-disk path by empty path segments.
Detection Strategies
- Parse inetshttpd access logs and flag any request URI whose path component contains the regular expression /{2,} against a resource inside a configured <Directory> block.
- Correlate authentication events with file-access events to surface protected-resource reads that lack a matching authenticated session.
- Compare the URI as received on the wire with the resolved filesystem path in application telemetry; divergence indicates path canonicalisation mismatch.
Monitoring Recommendations
- Add a web application firewall or reverse-proxy rule that rejects or normalises requests containing consecutive slashes before they reach inetshttpd.
- Alert on spikes in requests to sensitive directories that return 200 without an associated Authorization header.
- Track version inventory for Erlang/OTP and inets across the fleet to identify hosts still running vulnerable releases.
How to Mitigate CVE-2026-66835
Immediate Actions Required
- Upgrade Erlang/OTP to a fixed release: 27.3.4.17, 28.5.0.6, or 29.0.6, depending on your major version track.
- Upgrade inets to 9.3.2.7, 9.6.2.3, or 9.7.2 as appropriate.
- Audit HTTP access logs for prior requests containing doubled slashes against mod_auth protected directories.
- Rotate any secrets, tokens, or credentials whose files reside inside protected directories exposed by inetshttpd.
Patch Information
The Erlang Ecosystem Foundation published fixes across three commits: 9641944a, bac19eb3, and d8878de. Each patch canonicalises the request path before the mod_auth directory check by collapsing consecutive slashes in the path component. Full details are available in the GitHub Security Advisory GHSA-r4vv-vc2c-2fw6 and the CNA advisory.
Workarounds
- Place a reverse proxy such as nginx or HAProxy in front of inetshttpd and configure it to collapse consecutive slashes in the request URI before forwarding.
- Restrict network access to inetshttpd endpoints hosting mod_auth protected content until the patch is deployed.
- Move authentication enforcement out of mod_auth regex matching and into an anchored access-control layer that operates on canonicalised paths.
# nginx reverse-proxy example: normalise consecutive slashes before proxying
server {
listen 443 ssl;
server_name app.example.com;
# Collapse multiple slashes in the request path
merge_slashes on;
location / {
proxy_pass http://127.0.0.1:8080;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
}
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

