CVE-2026-47737

What it actually does

Puma incorrectly trusts and re-processes PROXY protocol v1 headers after the first request on a persistent keep-alive connection when `set_remote_address proxy_protocol: :v1` is enabled. The PROXY protocol header is intended to be accepted only once at connection establishment, typically from a trusted load balancer or reverse proxy. Because Puma re-parses a later injected PROXY header on the same TCP connection, an unauthenticated remote attacker can overwrite the Rack `REMOTE_ADDR` value for subsequent requests. This enables source IP spoofing at the application layer and can undermine IP-based access controls, rate limits, audit logging, fraud controls, allowlists, deny lists, and security decisions that rely on `REMOTE_ADDR`.

Why it matters to the business

Applications using affected Puma versions with PROXY protocol v1 enabled may make incorrect trust, access, or logging decisions based on a forged client IP address. This can allow attackers to bypass IP-based restrictions, evade throttling or abuse controls, obscure the real origin of activity, and pollute audit trails used for investigations or compliance. The CVSS score is high because integrity of request metadata can be compromised remotely without authentication, but current EPSS is low and the issue is not listed in CISA KEV, so urgency should be driven primarily by whether affected deployments use Puma behind a proxy with `proxy_protocol: :v1` and rely on client IP for security decisions.

How an attack unfolds

An attacker targets a Puma-backed Ruby/Rack application that accepts PROXY protocol v1 and keeps TCP connections open for multiple HTTP requests. The attacker establishes a connection through a path where Puma will process the initial PROXY header, sends a legitimate first request, and keeps the connection alive. On a later request over the same connection, the attacker injects another PROXY protocol v1 line before the HTTP request. Due to the parsing flaw, Puma treats this second PROXY line as authoritative connection metadata and updates `REMOTE_ADDR` to the attacker-supplied IP address. The application then processes the request as if it originated from that spoofed address, potentially bypassing IP allowlists, appearing as an internal or trusted client, evading per-IP rate limits, or corrupting audit records.

How to fix it

Upgrade Puma to a fixed release: version 7.2.1 or later on the 7.x branch, or version 8.0.2 or later on the 8.x branch. If running an affected 5.5.0 through 7.2.0 release or 8.0.0 through 8.0.1 with `set_remote_address proxy_protocol: :v1`, prioritize the upgrade. If immediate patching is not possible, mitigate by disabling PROXY protocol v1 where it is not strictly required, disabling direct access to Puma from untrusted networks, ensuring only trusted reverse proxies or load balancers can connect to Puma, disabling or reducing persistent keep-alive behavior where operationally acceptable, and avoiding security decisions that rely solely on Rack `REMOTE_ADDR`. Prefer defense-in-depth controls at the edge proxy, such as trusted source enforcement and canonical client IP handling, rather than allowing backend application code to make trust decisions from mutable request metadata.

How to confirm the fix worked

Confirm the deployed Puma version is 7.2.1 or later, or 8.0.2 or later, using package metadata, dependency lockfiles, container image manifests, or runtime startup logs. Review Puma configuration for `set_remote_address proxy_protocol: :v1` to determine exposure. Verify network architecture prevents untrusted clients from connecting directly to Puma and that only trusted proxies can send PROXY protocol traffic. In a safe test environment, validate that a second PROXY protocol v1 line sent over an existing keep-alive connection is not accepted as new client metadata and does not change the Rack `REMOTE_ADDR` value. Also confirm application audit logs preserve the true client identity as supplied by the trusted edge proxy and that rate limiting or allowlist controls are not solely dependent on backend `REMOTE_ADDR` when PROXY protocol handling is enabled.

Typical attack path

1. Identify a Ruby/Rack application served by an affected Puma version where PROXY protocol v1 support is enabled.
2. Confirm the target permits persistent HTTP keep-alive connections to the Puma service through the deployed proxy path.
3. Open a connection and send an initial request that is accepted normally.
4. Reuse the same connection for a subsequent request and include an additional PROXY protocol v1 header before the HTTP request.
5. Cause Puma to overwrite the request `REMOTE_ADDR` value with the attacker-controlled IP address from the injected PROXY header.
6. Use the spoofed source IP to bypass application logic that trusts `REMOTE_ADDR`, such as allowlists, deny lists, geofencing, throttling, abuse controls, or audit attribution.

How to detect it

Look for evidence that PROXY protocol headers were injected after the start of a persistent connection or that backend client IP attribution changed unexpectedly within a single keep-alive session. Useful log sources include edge load balancer logs, reverse proxy access logs, WAF logs, Puma access logs if enabled, Rack application request logs, authentication and authorization logs, rate-limit logs, and packet captures from traffic between the proxy and Puma. Correlate requests by connection identifiers where available, source port, request timing, and upstream proxy metadata. Investigate cases where backend logs show `REMOTE_ADDR` as an internal, trusted, allowlisted, or otherwise unusual address while edge proxy logs show a different originating client. Search for literal PROXY protocol v1 strings, especially `PROXY TCP4` or `PROXY TCP6`, appearing in HTTP request payloads, request lines, malformed requests, 400 responses, or application logs rather than only at the beginning of a backend TCP connection. Review suspicious successful access to IP-restricted endpoints, anomalous rate-limit bypasses, or audit records where many unrelated actions appear to come from the same trusted IP. There are no known public threat actors or KEV-listed exploitation campaigns tied to this issue from the provided data, so detection should focus on protocol anomalies and business-logic outcomes rather than known campaign infrastructure.

• PROXY TCP4
• PROXY TCP6
• set_remote_address proxy_protocol: :v1
• REMOTE_ADDR
• HTTP_PROXY
• proxy_protocol: :v1
• Puma
• puma
• PROXY UNKNOWN

What your security team should do

• Inventory Ruby/Rack services using Puma and identify any deployments running affected versions with `set_remote_address proxy_protocol: :v1` enabled.
• Prioritize upgrading exposed or security-sensitive applications to Puma 7.2.1+ or 8.0.2+, especially where IP allowlists, administrative routes, rate limits, fraud controls, or audit trails depend on `REMOTE_ADDR`.
• Restrict network access so only trusted load balancers or reverse proxies can reach Puma listener ports; block direct internet or untrusted internal access to Puma backends.
• Review application logic for authorization, throttling, abuse prevention, and logging decisions that trust `REMOTE_ADDR`; add compensating controls where necessary.
• Search historical logs for signs of repeated PROXY protocol headers on the same connection, unexpected changes in client IP attribution across keep-alive requests, or requests appearing to originate from trusted/internal IP ranges without matching edge-proxy evidence.
• Add monitoring at proxies, WAFs, and backend logs for PROXY protocol strings appearing after connection establishment or inside HTTP request streams.
• If patching is delayed, consider disabling PROXY protocol v1 support or persistent keep-alive to Puma where this will not break production traffic.
• Because this issue is not currently in KEV and has low EPSS, treat it as configuration-dependent high-impact risk rather than broadly exploited internet-wide activity, while still prioritizing systems where IP-based trust is security-critical.