CVE-2026-126083

### Impact Since Rails 8.1.0, `ActionDispatch::RemoteIp` derives `request.remote_ip` from `Rack::Request#forwarded_for`, 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.remote_ip` 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.remote_ip`, possibly bypassing IP-based access controls and rate limits keyed on the client address (including the default `by:` of `rate_limit`), and falsifying the client address in logs. ### Details The 8.1.0 change ([2d084af8](https://github.com/rails/rails/commit/2d084af8444a7b6b868c7cbb256172007871e78d)) switched `ActionDispatch::RemoteIp` from reading `X-Forwarded-For` directly to Rack's `forwarded_for`, in order to reuse Rack's port handling. Rails continues to honor `Forwarded`, the standard header. In the fixed releases, when `config.action_dispatch.ip_spoofing_check` 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, `forwarded_for` reads only `X-Forwarded-For`. - Is served behind a proxy that does not remove or overwrite a client-supplied `Forwarded` header. - Relies on `request.remote_ip` for access control, rate li