https://db.gcve.eu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Fri, 13 Nov 2026 11:36:31 +0000 https://db.gcve.eu/vuln/fkie_cve-2026-126083 <p>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.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. 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 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 i…</p> <p>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.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. 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 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 i…</p> https://db.gcve.eu/vuln/fkie_cve-2026-126083 https://db.gcve.eu/vuln/ghsa-2gff-2mmg-m73p <p><strong>Affected:</strong> RubyGems: actionpack</p> <p>### 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.</p> <p>### 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&#39;s `forwarded_for`, in order to reuse Rack&#39;s port handling. Rails continues to honor `Forwarded`, the standard header.</p> <p>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 prox…</p> <p><strong>Affected:</strong> RubyGems: actionpack</p> <p>### 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.</p> <p>### 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&#39;s `forwarded_for`, in order to reuse Rack&#39;s port handling. Rails continues to honor `Forwarded`, the standard header.</p> <p>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 prox…</p> https://db.gcve.eu/vuln/ghsa-2gff-2mmg-m73p https://db.gcve.eu/vuln/ubuntu-cve-2026-126083 <p><strong>Affected:</strong> Ubuntu:Pro:16.04:LTS: rails, Ubuntu:Pro:18.04:LTS: rails, Ubuntu:Pro:20.04:LTS: rails, Ubuntu:Pro:22.04:LTS: rails, Ubuntu:24.04:LTS: rails, Ubuntu:26.10: rails, Ubuntu:26.04:LTS: rails</p> <p>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.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. 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 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 i…</p> <p><strong>Affected:</strong> Ubuntu:Pro:16.04:LTS: rails, Ubuntu:Pro:18.04:LTS: rails, Ubuntu:Pro:20.04:LTS: rails, Ubuntu:Pro:22.04:LTS: rails, Ubuntu:24.04:LTS: rails, Ubuntu:26.10: rails, Ubuntu:26.04:LTS: rails</p> <p>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.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. 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 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 i…</p> https://db.gcve.eu/vuln/ubuntu-cve-2026-126083 https://db.gcve.eu/vuln/wid-sec-w-2026-4317 <p>Ein Angreifer kann mehrere Schwachstellen in Ruby on Rails ausnutzen, um beliebigen Programmcode auszuführen, um einen Denial of Service Angriff durchzuführen, um Informationen offenzulegen, um Daten zu manipulieren, um falsche Informationen darzustellen, um einen Cross-Site Scripting Angriff durchzuführen und um Sicherheitsvorkehrungen zu umgehen.</p> <p>Ein Angreifer kann mehrere Schwachstellen in Ruby on Rails ausnutzen, um beliebigen Programmcode auszuführen, um einen Denial of Service Angriff durchzuführen, um Informationen offenzulegen, um Daten zu manipulieren, um falsche Informationen darzustellen, um einen Cross-Site Scripting Angriff durchzuführen und um Sicherheitsvorkehrungen zu umgehen.</p> https://db.gcve.eu/vuln/wid-sec-w-2026-4317