CVE-2026-47736

What it actually does

When Puma is configured to accept PROXY protocol v1 headers, it attempts to determine whether the start of a TCP connection contains a PROXY line by reading bytes until it sees a CRLF terminator. A remote unauthenticated client can keep sending data without CRLF, causing Puma to retain an ever-growing in-process buffer and repeatedly rescan that buffer. The result is attacker-controlled memory growth and increased CPU consumption, which can exhaust worker resources and make the web service unavailable. The flaw affects Puma versions from 5.5.0 up to the fixed 7.2.1 and 8.0.2 releases when PROXY protocol v1 support is enabled.

Why it matters to the business

Internet-facing Ruby/Rack applications using Puma behind load balancers or reverse proxies can be knocked offline with low-complexity network traffic if PROXY protocol v1 is enabled. Successful exploitation can cause application downtime, failed customer transactions, degraded API availability, autoscaling cost increases, and operational incidents. Although there is no evidence from the provided data of known exploited status, ransomware use, or mature public exploitation, the high availability impact and network-reachable attack surface make timely patching important.

How an attack unfolds

An attacker first identifies a Puma service that accepts direct TCP connections on a listener where PROXY protocol v1 support is enabled. Instead of sending a normal HTTP request or a valid PROXY v1 header ending in CRLF, the attacker opens one or more TCP connections and continuously transmits bytes without the terminating CRLF sequence. Puma keeps appending the received bytes to its internal buffer while attempting to decide whether a valid PROXY line is present. As the buffer grows, memory usage rises and CPU time is consumed scanning the increasingly large buffer. Repeating this across connections or sustaining the traffic can exhaust Puma worker memory, trigger process crashes, invoke container or supervisor restarts, or saturate service capacity, resulting in denial of service.

How to fix it

Upgrade Puma to a fixed release: 7.2.1 or later on the 7.x branch, or 8.0.2 or later on the 8.x branch. For deployments on older affected versions beginning with 5.5.0, move to a supported fixed branch as soon as practical. If immediate upgrade is not possible, disable PROXY protocol v1 support on Puma listeners unless it is strictly required. Ensure Puma is only reachable from trusted load balancers or reverse proxies when PROXY protocol is used; block direct internet access to backend Puma ports. Enforce connection-level protections at the edge, such as TCP idle/read timeouts, maximum header or preface size limits where supported by the proxy, connection rate limits, and per-source connection limits. Use process/container memory limits and supervised restarts as a containment measure, but do not treat them as a substitute for upgrading.

How to confirm the fix worked

Confirm the running Puma version with application dependency metadata, package lockfiles, container image SBOMs, or runtime commands such as checking the installed puma gem version. Validate that all deployed instances are running 7.2.1 or later, 8.0.2 or later, or are not using PROXY protocol v1. Review Puma configuration and launch options for PROXY protocol enablement. Confirm network controls prevent untrusted clients from connecting directly to Puma backend listeners. In a controlled non-production environment, test that incomplete PROXY-preface traffic without CRLF is rejected, limited, or disconnected without unbounded process memory growth. Monitor Puma process RSS, CPU, connection counts, and restart events after remediation to ensure resource usage remains bounded under malformed connection attempts.

Typical attack path

1. Discover or target a Ruby/Rack application served by Puma on a reachable TCP port.
2. Determine or assume that the listener has PROXY protocol v1 support enabled, commonly used behind load balancers or reverse proxies.
3. Open TCP connections to the Puma listener.
4. Send a continuous stream of bytes that does not include a CRLF terminator.
5. Keep connections open and continue transmitting data to force Puma to grow the internal buffer.
6. Repeat across multiple connections if needed to amplify memory and CPU pressure.
7. Cause Puma workers or containers to exhaust resources, restart, or stop serving legitimate requests.

How to detect it

To assess prior exploitation, correlate network, load balancer, reverse proxy, host, container, and application telemetry around periods of Puma memory growth, CPU spikes, worker crashes, container OOM kills, or availability drops. Review load balancer and firewall logs for unusual numbers of long-lived TCP connections to Puma backend ports, especially connections with high inbound byte counts but no completed HTTP request. Check host and container telemetry for steadily increasing RSS memory in Puma processes, sudden OOMKilled events, SIGKILL terminations, supervisor restarts, or crash loops. Inspect reverse proxy logs for backend connection failures, upstream timeouts, connection resets, and periods where requests to Puma returned 502/503/504 while backend resource use was elevated. Packet captures, flow logs, or IDS telemetry may show clients sending continuous data to the Puma listener without CRLF or without completing a recognizable HTTP request. Because this is a denial-of-service condition rather than code execution, durable host artifacts are unlikely; focus on time-correlated resource exhaustion and network behavior rather than file changes or persistence indicators.

What your security team should do

• Inventory all Ruby/Rack services using Puma, including container images and platform buildpacks, and identify versions from 5.5.0 through unfixed 7.x/8.x releases.
• Prioritize externally reachable Puma deployments and any deployment with PROXY protocol v1 enabled.
• Upgrade to Puma 7.2.1 or later, or 8.0.2 or later, and redeploy all affected services.
• Disable PROXY protocol v1 wherever it is not required; where required, restrict Puma listeners so only trusted proxies or load balancers can connect.
• Add or verify edge protections for connection rate limiting, read timeouts, idle timeouts, and maximum connection duration.
• Create monitoring alerts for abnormal Puma memory growth, CPU spikes, elevated open TCP connections, worker restarts, and HTTP availability degradation.
• Review recent logs and telemetry for signs of resource-exhaustion attempts against Puma listeners, especially shortly before crashes or restarts.
• Document accepted residual risk for any service that cannot be upgraded immediately and apply compensating network controls until patching is complete.