CVE-2026-34830: Rack :Sendfile Header-based X-Accel-Mapping Regex Injection Vulnerability
MODERATECVE-2026-34830 is a MODERATE (CVSS 5.9) :sendfile header-based x-accel-mapping regex injection vulnerability (CWE-625: Permissive Regular Expression) affecting Rack libraries in the RubyGems ecosystem. The issue involves :sendfile header-based x-accel-mapping regex injection enables unauthorized x-accel-redirect. Remediation is available by upgrading affected packages to version 2.2.23, 3.1.21, 3.2.6.
CVE-2026-34830 at a Glance
Security Impact
CVSS: 5.9
The security impact metrics below are parsed directly from the CVSS v3.1 vector string (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N).
How to Fix CVE-2026-34830
To remediate this vulnerability, upgrade all affected Rack dependencies to a patched release. Both direct and transitive dependencies should be checked, as frameworks or security libraries may pull in vulnerable versions transitively.
Upgrade rack to 2.2.23
Upgrade rack to 3.1.21
Upgrade rack to 3.2.6
Run the following command in your project directory to verify that all resolved dependencies use the patched release:
inspect dependencies for rack
How to Check if You Are Affected
To determine whether your application is affected by CVE-2026-34830, inspect your project dependencies for Rack:
inspect dependencies for rack
Analyze the terminal output to locate any version of Rack in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than 2.2.23), your application is affected.
Note: Verify declared build manifests and deployed runtime container environments.
Technical Details
Vulnerability Mechanism & Technical Analysis
This vulnerability is classified under CWE-625: Permissive Regular Expression, where the product uses a regular expression that does not sufficiently restrict the set of allowed values. In Rack, software state validation or input boundaries are circumvented during processing. Review the official source advisory statement below for specific affected components, classes, and reproduction details.
Source Advisory Statement
CVE-2026-34830 Affected Rack Versions
3 component(s)References
Frequently Asked Questions
What is CVE-2026-34830?
Which Rack versions are affected?
What version fixes CVE-2026-34830?
Is rack affected?
What is the CVSS score of CVE-2026-34830?
What CWE is associated with CVE-2026-34830?
How can I check RubyGems dependencies for CVE-2026-34830?
Machine-readable OSV JSON
OSV v1.5 Schema
{
"schema_version" : "1.4.0",
"id" : "GHSA-qv7j-4883-hwh7",
"modified" : "2026-05-13T16:18:57Z",
"published" : "2026-04-02T20:35:23Z",
"aliases" : [ "CVE-2026-34830" ],
"summary" : "Rack::Sendfile header-based X-Accel-Mapping regex injection enables unauthorized X-Accel-Redirect",
"details" : "## Summary\n\n`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.\n\nIn deployments using `Rack::Sendfile` with `x-accel-redirect`, this can allow an attacker to cause nginx to serve unintended files from configured internal locations.\n\n## Details\n\n`Rack::Sendfile#map_accel_path` processes header-supplied mappings using logic equivalent to:\n\n```ruby\nmapping.split(',').map(&:strip).each do |m|\n internal, external = m.split('=', 2).map(&:strip)\n new_path = path.sub(/\\A#{internal}/i, external)\n return new_path unless path == new_path\nend\n```\n\nHere, `internal` comes from the `HTTP_X_ACCEL_MAPPING` request header and is inserted directly into a regular expression without escaping. This gives the header value regex semantics rather than treating it as a literal prefix.\n\nAs a result, an attacker can supply metacharacters such as `.*` or capture groups to alter how the path substitution is performed. For example, a mapping such as:\n\n```http\nX-Accel-Mapping: .*=/protected/secret.txt\n```\n\ncauses the entire source path to match and rewrites the redirect target to a clean attacker-chosen internal path.\n\nThis differs from the documented behavior of the header-based mapping path, which is described as a simple substitution. While application-supplied mappings may intentionally support regular expressions, header-supplied mappings should be treated as literal path prefixes.\n\nThe issue is only exploitable when untrusted `X-Accel-Mapping` headers can reach Rack. One realistic case is a reverse proxy configuration that intends to set `X-Accel-Mapping` itself, but fails to do so on some routes, allowing a client-supplied header to pass through unchanged.\n\n## Impact\n\nApplications using `Rack::Sendfile` with `x-accel-redirect` may be affected if the backend accepts attacker-controlled `X-Accel-Mapping` headers.\n\nIn affected deployments, an attacker may be able to control the `X-Accel-Redirect` response header and cause nginx to serve files from internal locations that were not intended to be reachable through the application. This can lead to unauthorized file disclosure.\n\nThe practical impact depends on deployment architecture. If the proxy always strips or overwrites `X-Accel-Mapping`, or if the application uses explicit configured mappings instead of the request header, exploitability may be eliminated.\n\n## Mitigation\n\n* Update to a patched version of Rack that treats header-supplied `X-Accel-Mapping` values as literal strings rather than regular expressions.\n* Strip or overwrite inbound `X-Accel-Mapping` headers at the reverse proxy so client-supplied values never reach Rack.\n* Prefer explicit application-configured sendfile mappings instead of relying on request-header mappings.\n* Review proxy sub-locations and inherited header settings to ensure `X-Accel-Mapping` is consistently set on all backend routes.",
"severity" : [ {
"type" : "CVSS_V3",
"score" : "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N"
} ],
"affected" : [ {
"package" : {
"ecosystem" : "RubyGems",
"name" : "rack"
},
"ranges" : [ {
"type" : "ECOSYSTEM",
"events" : [ {
"introduced" : "0"
}, {
"fixed" : "2.2.23"
} ]
} ]
}, {
"package" : {
"ecosystem" : "RubyGems",
"name" : "rack"
},
"ranges" : [ {
"type" : "ECOSYSTEM",
"events" : [ {
"introduced" : "3.0.0.beta1"
}, {
"fixed" : "3.1.21"
} ]
} ]
}, {
"package" : {
"ecosystem" : "RubyGems",
"name" : "rack"
},
"ranges" : [ {
"type" : "ECOSYSTEM",
"events" : [ {
"introduced" : "3.2.0"
}, {
"fixed" : "3.2.6"
} ]
} ]
} ],
"references" : [ {
"type" : "WEB",
"url" : "https://github.com/rack/rack/security/advisories/GHSA-qv7j-4883-hwh7"
}, {
"type" : "ADVISORY",
"url" : "https://nvd.nist.gov/vuln/detail/CVE-2026-34830"
}, {
"type" : "PACKAGE",
"url" : "https://github.com/rack/rack"
}, {
"type" : "WEB",
"url" : "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/rack/CVE-2026-34830.yml"
} ],
"database_specific" : {
"cwe_ids" : [ "CWE-625" ],
"severity" : "MODERATE",
"github_reviewed" : true,
"github_reviewed_at" : "2026-04-02T20:35:23Z",
"nvd_published_at" : "2026-04-02T17:16:26Z"
}
}