CVE-2026-34830
Received Received - Intake
Regex Injection in Rack::Sendfile Enables Unauthorized File Access

Publication date: 2026-04-02

Last updated on: 2026-04-16

Assigner: GitHub, Inc.

Description
Rack is a modular Ruby web server interface. Prior to versions 2.2.23, 3.1.21, and 3.2.6, Rack::Sendfile#map_accel_path interpolates the value of the X-Accel-Mapping request header directly into a regular expression when rewriting file paths for X-Accel-Redirect. Because the header value is not escaped, an attacker who can supply X-Accel-Mapping to the backend can inject regex metacharacters and control the generated X-Accel-Redirect response header. In deployments using Rack::Sendfile with x-accel-redirect, this can allow an attacker to cause nginx to serve unintended files from configured internal locations. This issue has been patched in versions 2.2.23, 3.1.21, and 3.2.6.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-04-02
Last Modified
2026-04-16
Generated
2026-05-07
AI Q&A
2026-04-02
EPSS Evaluated
2026-05-05
NVD
EUVD
Affected Vendors & Products
Showing 3 associated CPEs
Vendor Product Version / Range
rack rack From 3.0.0 (inc) to 3.1.21 (exc)
rack rack From 3.2.0 (inc) to 3.2.6 (exc)
rack rack to 2.2.23 (exc)
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-625 The product uses a regular expression that does not sufficiently restrict the set of allowed values.
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

CVE-2026-34830 is a vulnerability in the Rack Ruby webserver interface, specifically in the Rack::Sendfile middleware's handling of the X-Accel-Mapping HTTP request header.

The method Rack::Sendfile#map_accel_path directly inserts the value of the X-Accel-Mapping header into a regular expression without escaping it. This allows an attacker who can supply or manipulate this header to inject regex metacharacters, controlling how file path substitutions are performed.

For example, an attacker can use a header like 'X-Accel-Mapping: .*=/protected/secret.txt' to cause the entire path to match and rewrite the redirect target to an internal file chosen by the attacker.

This behavior deviates from the intended literal prefix substitution and can lead to unauthorized file disclosure if untrusted X-Accel-Mapping headers reach the Rack backend.


How can this vulnerability impact me? :

This vulnerability can allow an attacker to manipulate the X-Accel-Redirect response header, causing the nginx server to serve unintended or unauthorized internal files.

If an attacker can supply or control the X-Accel-Mapping header, they can inject regex patterns that rewrite file paths to sensitive files, potentially exposing confidential information.

The impact is unauthorized file disclosure, which can compromise the confidentiality of data served by the web application.


How can this vulnerability be detected on my network or system? Can you suggest some commands?

This vulnerability can be detected by monitoring HTTP requests to the Rack backend for the presence of the X-Accel-Mapping header, especially if it contains suspicious regex metacharacters such as .* or capture groups.

You can use network inspection tools or command-line utilities to capture and analyze HTTP headers for this pattern.

  • Use tcpdump or tshark to capture HTTP traffic and filter for X-Accel-Mapping headers, for example: tcpdump -A -s 0 'tcp port 80 and (((ip[2:2] - ((ip[0]&0xf)<<2)) - ((tcp[12]&0xf0)>>2)) != 0)' | grep 'X-Accel-Mapping'
  • Use curl or httpie to manually send requests with crafted X-Accel-Mapping headers to test if the backend accepts and processes them.
  • Check your reverse proxy or application logs for any unexpected or unescaped X-Accel-Mapping header values.

What immediate steps should I take to mitigate this vulnerability?

Immediate mitigation steps include updating Rack to one of the patched versions: 2.2.23, 3.1.21, or 3.2.6, where the vulnerability has been fixed by treating the X-Accel-Mapping header values as literal strings rather than regex patterns.

Additionally, ensure that your reverse proxy strips or overwrites any inbound X-Accel-Mapping headers to prevent attackers from controlling this header.

Prefer configuring explicit sendfile mappings within your application rather than relying on client-supplied headers.

Verify that all backend routes have consistent proxy header settings to avoid unintentional exposure.


How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:

This vulnerability allows an attacker to cause nginx to serve unauthorized internal files by manipulating the X-Accel-Redirect response header through injection of regex metacharacters in the X-Accel-Mapping request header. Such unauthorized file disclosure can lead to exposure of sensitive or confidential information.

Exposure of sensitive data due to this vulnerability could potentially impact compliance with data protection regulations and standards such as GDPR and HIPAA, which require protection of personal and sensitive information from unauthorized access or disclosure.

Mitigations include updating to patched versions of Rack, stripping or overwriting inbound X-Accel-Mapping headers at the reverse proxy, and ensuring consistent proxy header settings, which help reduce the risk of unauthorized data exposure and thus support compliance efforts.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart