TCP port forwarder buffers unbounded pre-connect data from published container ports

## Impact An attacker that can reach a container's published TCP port may be able to force the host's forwarding process to buffer an unbounded amount of that client's data in memory, for as long as the backend container connection takes to complete — with no cap on how much accumulates or how long the wait can be stretched. ## Affected code Affected: `ConnectHandler` in `Sources/SocketForwarder/ConnectHandler.swift`, reachable via `TCPForwarder` (`Sources/SocketForwarder/TCPForwarder.swift`) for any container run with a published TCP port. Present since TCP/UDP port forwarding was introduced (`apple/container#338`, 2025-07-18), first released in 0.3.0. **Not affected:** `UDPForwarder` queues pre-connect datagrams in a separate, small, bounded structure and is not part of this finding, though it received a defensive cap in the same fix for consistency. ## Mitigations 1. Upgrade to `container` 1.2.0 or later. 2. If you cannot upgrade immediately, avoid publishing container TCP ports to interfaces reachable by untrusted clients — bind published ports to `127.0.0.1` rather than `0.0.0.0` unless remote access is required. 3. Monitor the memory usage of the host's `container-runtime-linux` process per running container; an unexplained, sustained climb while a container is otherwise idle is consistent with this issue being triggered, whether accidentally (client sending data before your own container app is ready to accept) or deliberately. 4. Where possible, run containers whose application accepts connections promptly and with a backlog sized for expected concurrency — the vulnerable window is bounded by how long the backend takes to accept, so a fast-accepting backend narrows exposure even before upgrading. ## Verifying whether you are affected This does not leave a durable on-disk artifact, since the exposure is an in-memory buffer during an active connection rather than a persistent state change. To check whether a given build is patched without relying on the version string, publish a TCP port from a container whose backend deliberately does not accept() its listening socket, connect to the published port, send data immediately, and watch the memory (RSS) of the corresponding container-runtime-linux process. Sustained growth proportional to data sent, with no plateau, indicates the vulnerable behavior; a fixed host will show no growth from the frontend data until the backend connects (or the connection is dropped after the connect timeout). ## References - Fix: [apple/container#2027](https://github.com/apple/container/pull/2027)

Severity from

GitHub (reviewed advisory)

• github.com/apple/container/security/advisories/GHSA-wg28-286f-56v6
• github.com/apple/container