UBUNTU-CVE-2026-126083: Medium severity ubuntu/rails vulnerability
Action Pack is a framework for handling and responding to web requests. From 8.1 until 8.1.4.1, Since Rails 8.1.0, ActionDispatch::RemoteIp derives request.remoteip from Rack::Request#forwardedfor, which under Rack 3 reads the RFC 7239 Forwarded header in preference to X-Forwarded-For. When a reverse proxy appends the client address to X-Forwarded-For but passes a client-supplied Forwarded header through unchanged, request.remoteip returns an address chosen by the client, and the IP spoofing check does not raise, because it compares only Client-Ip with the forwarded addresses. An unauthenticated attacker could therefore spoof request.remoteip, possibly bypassing IP-based access controls and rate limits keyed on the client address (including the default by: of ratelimit), and falsifying the client address in logs. An application is affected if it meets all of these requirements: Runs Rails 8.1.0 through 8.1.4 with Rack 3. Under Rack 2.2, forwardedfor reads only X-Forwarded-For. Is served behind a proxy that does not remove or overwrite a client-supplied Forwarded header. Relies on request.remoteip for access control, rate limiting, or auditing. The fix detects a spoofed Forwarded header only when the proxy also sets X-Forwarded-For. An application whose proxy passes a client-supplied Forwarded header through and sets no X-Forwarded-For remains exposed after upgrading, and should configure the proxy to remove or overwrite Forwarded, or apply the workaround below. This issue is fixed in version 8.1.4.1.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Action Packto a version that resolves this vulnerability.Fixed in 8.1.4.1 - Configuration
Configure the proxy to remove or overwrite a client-supplied Forwarded header, particularly when it passes Forwarded through and does not set X-Forwarded-For.
reverse proxy Forwarded = remove or overwrite client-supplied values
Event History
Frequently Asked Questions
Which deployments are affected?
An application is affected only if it runs Rails 8.1.0 through 8.1.4 with Rack 3, is behind a proxy that preserves a client-supplied Forwarded header, and uses request.remote_ip for access control, rate limiting, or auditing. Rack 2.2 is not affected by this behavior because forwarded_for reads only X-Forwarded-For.
What does an attacker need to exploit this?
The attacker does not need authentication. They need to be able to send a client-controlled Forwarded header through a reverse proxy that appends to X-Forwarded-For but does not remove or overwrite Forwarded.
What is the practical impact of successful exploitation?
An attacker can cause request.remote_ip to contain an address they choose. This can bypass IP-based access controls or client-address rate limits, including the default by: behavior of rate_limit, and can make logs record a falsified client address.
How can exposure be reduced before patching?
Configure the reverse proxy to remove or overwrite client-supplied Forwarded headers before forwarding requests to the application. This prevents an untrusted Forwarded value from being preferred over the proxy-managed X-Forwarded-For chain.