VulnerabilityPublished 6 Nov 2026

Forwarded Without Question: How Web Frameworks Overtrust the Forwarded Header

Source Reddit NetSec

Fixed in 8.1.4.1 : update affected systems when convenient.

Data as of 6 Nov 2026, 10:48 UTC

Severity

Medium

Rated by Threat Radar

Patch: Available – fixed in 8.1.4.1

What to do

AI-suggested

Upgrade Rails actionpack to version 8.1.4.1 or later where the spoofing check is implemented. Configure reverse proxies to remove or overwrite any client-supplied Forwarded headers to prevent spoofing. As a workaround, applications can configure Rack to ignore the Forwarded header by setting Rack::Request.forwarded_priority = [:x_forwarded] in an initializer if the proxy sets X-Forwarded-For. This workaround requires Rack 3.0.0 or later.

Discussion

A vulnerability in Ruby on Rails versions 8.1.0 through 8.1.4 allows unauthenticated attackers to spoof the client IP address via the Forwarded HTTP header. This occurs because Rails trusts the Forwarded header by default, which can be manipulated if a reverse proxy does not remove or overwrite client-supplied Forwarded headers. This spoofing can bypass IP-based access controls, rate limits, and falsify client IP information in logs.

r/netsec (opens in a new tab)u/luryus0 points0 comments

Many common web frameworks like Spring and Ruby on Rails trust the Forwarded header by default, even though most proxies don't actually have any support for it. This makes apps vulnerable to request hostname or client IP address spoofing in the default configurations.

I've been researching how the Forwarded header is supported across frameworks and proxies. Rails and Spring recently shipped fixes following my research. There are still other frameworks that need application configuration changes to be secure.

Impact

An unauthenticated attacker can spoof the client IP address in Rails applications running affected versions behind proxies that do not sanitize the Forwarded header. This can lead to bypassing IP-based access controls and rate limiting, as well as falsifying client IP information in logs, potentially undermining security monitoring and auditing.

Summary

Since Rails 8.1.0, ActionDispatch::RemoteIp derives the client IP address from the RFC 7239 Forwarded header via Rack 3, preferring it over X-Forwarded-For. If a reverse proxy appends the client IP to X-Forwarded-For but passes through a client-supplied Forwarded header unchanged, request.remote_ip can be spoofed by an attacker. The IP spoofing check compares Client-Ip with forwarded addresses but does not detect this discrepancy, allowing bypass of IP-based controls and falsification of logs. The issue affects Rails versions >= 8.1 and < 8.1.4.1. Fixed versions (>= 8.1.4.1) add a check comparing the first untrusted client IP in Forwarded and X-Forwarded-For headers and raise an error if they differ, mitigating spoofing. Applications behind proxies that do not remove or overwrite Forwarded headers remain vulnerable unless patched or configured to ignore Forwarded.

References

Community reviews

Loading reviews…

What to do

Discussion

AI analysisMachine-generated, updated 6 Nov 2026, 10:48 UTC

Technical details

References

Community reviews

Related threats