RACK · CVE-2026-125109 · Package
FIX → 3.2.8 +1
Rack's host_with_port, base_url and url methods return an invalid Host, X-Forwarded-Host or Forwarded value unchanged, so URLs the application builds can carry attacker-chosen characters. An attacker can use this to bypass URL or host allowlist checks and redirect generated links or Location headers.
first public Oct 30, 2026 · 1 source
Could this affect your app?
Free first check from your website. Connect your repo for the full answer.
Applications on Rack 3.0 through 3.1.22 or 3.2 through 3.2.7 that build absolute URLs, redirects or origin-dependent checks from request host values and do not enforce a host allowlist. Rails overrides these methods and is not expected to be affected; Rack 2.2 is affected but has no fix in this advisory.
Not affected if host-allowlist-enforced, proxy-overwrites-forwarded-host, rails
Who cares rack, ruby, self-hosted, sinatra
bundle exec gem list rack should show a fixed version.req.url, req.base_url or req.host_with_port without a host allowlist.Rack::Protection::HostAuthorization or is enabled.Rack::Request#host_with_port, and therefore #base_url and #url, return the raw authority string when it fails validation. An attacker-controlled Host, X-Forwarded-Host, or Forwarded: host= value containing characters that are not permitted in an authority is embedded verbatim in URLs generated by the application.
This completes the fix for CVE-2026-34835 (GHSA-g2pf-xv49-m2h5), which made #host and #hostname return nil for an invalid authority but left this path unchanged.
Rack::Request#host_with_port splits the authority with split_authority. When the AUTHORITY pattern does not match, no components are returned and falls back to returning the unvalidated authority string. is and appends the full path, so both inherit the raw value.
Check it with your coding agent
It reads this page and tells you if your code is affected.
Are you affected?
Ask from here. InfraStack checks the affected versions against your stack and answers in your inbox.
InfraStack checks the affected versions against your stack and answers in Slack, with the evidence and the fix.
config.hostsUpgrade to 3.2.8 +1
3.1.233.2.8host_with_portbase_url"#{scheme}://#{host_with_port}"urlFor a request with Host: evil.com/@legit.com, host returns nil while host_with_port returns evil.com/@legit.com and base_url returns http://evil.com/@legit.com. A valid Host together with an invalid X-Forwarded-Host produces the same result, because forwarded headers take priority by default.
Applications that build absolute URLs, redirects, or origin-dependent checks from req.url, req.base_url, or req.host_with_port, and that do not enforce a host allowlist, may emit URLs containing attacker-chosen characters such as @, /, ?, #, spaces, or angle brackets. Generated links and Location headers can be redirected through userinfo tricks, string-based URL checks can be bypassed, and markup is reflected where the application does not escape the value. For example, redirect in Sinatra behind a proxy that forwards X-Forwarded-Host emits the raw invalid authority in Location.
Rails overrides these methods in Action Dispatch and is not expected to be affected. Rack 3.1 and 3.2 are affected. Rack 2.2 did not receive the CVE-2026-34835 change and returns the raw value from every host method.
host_with_port returns nil for an invalid authority and base_url falls back to the server's own name.Rack::Protection::HostAuthorization, config.hosts in Rails, or at the reverse proxy, and configure the proxy to overwrite X-Forwarded-Host and Forwarded.rack.request.config :authority key where available.