CVE-2026-34830: Rack Path Traversal Vulnerability

CVE-2026-34830 Overview

A regex injection vulnerability exists in Rack, the modular Ruby web server interface, that allows attackers to manipulate file serving behavior through crafted HTTP headers. The vulnerability resides in the Rack::Sendfile#map_accel_path method, which directly interpolates the value of the X-Accel-Mapping request header into a regular expression without proper escaping. This allows an attacker to inject regex metacharacters and control the generated X-Accel-Redirect response header, potentially causing nginx to serve unintended files from configured internal locations.

Critical Impact

Attackers can bypass intended file serving restrictions and cause nginx to serve arbitrary files from internal locations by injecting malicious regex patterns into the X-Accel-Mapping header.

Affected Products

• Rack versions prior to 2.2.23
• Rack versions prior to 3.1.21
• Rack versions prior to 3.2.6

Discovery Timeline

• 2026-04-02 - CVE CVE-2026-34830 published to NVD
• 2026-04-02 - Last updated in NVD database

Technical Details for CVE-2026-34830

Vulnerability Analysis

This vulnerability is classified under CWE-625 (Permissive Regular Expression). The flaw exists because Rack::Sendfile trusts and directly incorporates user-controlled input from the X-Accel-Mapping HTTP request header into a regular expression pattern used for path rewriting. When Rack processes requests in environments configured to use x-accel-redirect (a common nginx internal redirect mechanism), the header value is interpolated without any escaping or sanitization of regex metacharacters.

An attacker can exploit this by supplying specially crafted values in the X-Accel-Mapping header that contain regex metacharacters such as .*, |, (), or other pattern-matching constructs. These injected patterns alter the behavior of the path-matching logic, allowing the attacker to influence which files nginx ultimately serves through the X-Accel-Redirect response header.

Root Cause

The root cause is improper input validation in the Rack::Sendfile#map_accel_path method. The method fails to escape or sanitize the contents of the X-Accel-Mapping header before using it to construct a regular expression. This violates the security principle that user-controlled data should never be directly incorporated into executable patterns (whether code, SQL, or regex) without proper sanitization. The fix in patched versions properly escapes or validates the header input before regex construction.

Attack Vector

The attack is network-accessible and requires no authentication or user interaction, though it does require specific deployment conditions. The attacker must be able to:

1. Send HTTP requests to a backend application using Rack::Sendfile
2. The deployment must be configured to use the x-accel-redirect mechanism (typically with nginx as a reverse proxy)
3. The attacker supplies a malicious X-Accel-Mapping header value containing regex metacharacters

When these conditions are met, the attacker can inject regex patterns that manipulate path matching, potentially causing nginx to serve files from unintended internal locations. This could lead to information disclosure of sensitive files that should not be publicly accessible.

Detection Methods for CVE-2026-34830

Indicators of Compromise

• Unusual or malformed values in X-Accel-Mapping request headers containing regex metacharacters such as .*, |, ^, $, (), [], or {}
• Unexpected X-Accel-Redirect response headers pointing to internal paths that differ from normal application behavior
• Access log entries showing requests with suspicious header values targeting file-serving endpoints
• nginx access logs showing internal location redirects for paths that shouldn't be accessible

Detection Strategies

• Implement web application firewall (WAF) rules to detect and block requests containing regex metacharacters in the X-Accel-Mapping header
• Monitor application logs for anomalous file access patterns, particularly access to files outside expected directories
• Deploy header inspection rules that flag requests with unexpected characters in X-Accel-Mapping values
• Review nginx internal redirect logs for unusual access patterns to protected locations

Monitoring Recommendations

• Configure alerting for requests containing X-Accel-Mapping headers with special characters
• Monitor nginx error logs for unexpected internal redirect failures or path resolution issues
• Implement logging of all X-Accel-Redirect response headers to establish baseline behavior and detect anomalies
• Review Ruby application logs for Rack::Sendfile activity patterns

How to Mitigate CVE-2026-34830

Immediate Actions Required

• Upgrade Rack to patched versions: 2.2.23, 3.1.21, or 3.2.6 depending on your current version branch
• If immediate patching is not possible, consider disabling the x-accel-redirect feature in your nginx configuration temporarily
• Implement WAF rules to block or sanitize requests containing regex metacharacters in the X-Accel-Mapping header
• Audit nginx configuration to minimize exposure of internal locations

Patch Information

Security patches have been released for all affected version branches. The fix addresses the regex injection by properly sanitizing or escaping the X-Accel-Mapping header value before incorporating it into regular expression patterns. Upgrade to one of the following versions based on your deployment:

• For Rack 2.x: Upgrade to version 2.2.23 or later
• For Rack 3.1.x: Upgrade to version 3.1.21 or later
• For Rack 3.2.x: Upgrade to version 3.2.6 or later

For additional details, refer to the GitHub Security Advisory.

Workarounds

• Configure nginx to strip or ignore the X-Accel-Mapping header from incoming client requests before they reach the Rack application
• Disable the x-accel-redirect feature if it is not required for your deployment
• Implement request filtering at the reverse proxy layer to reject requests with suspicious X-Accel-Mapping values
• Restrict nginx internal locations to the minimum necessary paths and ensure sensitive files are not accessible via internal redirects

# Example nginx configuration to strip X-Accel-Mapping header
location / {
    proxy_set_header X-Accel-Mapping "";
    proxy_pass http://backend;
}