CVE-2026-126083: Action Pack: Possible IP spoofing in Action Dispatch RemoteIp
Impact 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.
Details The 8.1.0 change (2d084af8) switched ActionDispatch::RemoteIp from reading X-Forwarded-For directly to Rack's forwardedfor, in order to reuse Rack's port handling. Rails continues to honor Forwarded, the standard header.
In the fixed releases, when config.actiondispatch.ipspoofingcheck is enabled (the default), ActionDispatch::RemoteIp also compares the first untrusted client address in Forwarded with the first untrusted client address in X-Forwarded-For, as exact strings, and raises ActionDispatch::RemoteIp::IpSpoofAttackError when both headers are present and the addresses differ. Deployments whose proxies report the client address inconsistently between the two headers will receive this error after upgrading. See the actionpack CHANGELOG.
Affected applications 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.
Mitigation - Upgrade to a fixed version of actionpack. - Configure reverse proxies to remove or overwrite any client-supplied Forwarded header.
Workarounds Applications whose proxies set X-Forwarded-For can make Rack ignore the Forwarded header, restoring the client address resolution of Rails 8.0, by setting Rack::Request.forwardedpriority = [:xforwarded] in an initializer. This setting is available in Rack 3.0.0 and later, and it also causes Rack to ignore Forwarded when determining the request scheme, host, and port.
Releases The fixed releases are available at the normal locations.
Patches for those who cannot upgrade at once: - 8.1: https://github.com/rails/rails/commit/2a01a5ac521184419d9a92fa2c25e102e68cd227.patch
Versions affected - actionpack >= 8.1, < 8.1.4.1
Credit This issue was responsibly reported by HackerOne researcher luryus.
Other sources
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.
— MITRE
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
rubygems/actionpackto a version that resolves this vulnerability.Fixed in 8.1.4.1 - Upgrade
Upgrade
actionpackto a version that resolves this vulnerability.Fixed in 8.1.4.1 - Configuration
Configure the reverse proxy to remove or overwrite any client-supplied Forwarded header.
Reverse proxy Forwarded header handling = remove or overwrite client-supplied Forwarded headers - Configuration
In an initializer, set Rack::Request.forwarded_priority = [:x_forwarded] when the proxy sets X-Forwarded-For, so Rack ignores Forwarded when determining the client address.
Rack Rack::Request.forwarded_priority = [:x_forwarded]