Facebook proxygen WebTransport use-after-free can expose process data

In proxygen from v2024.10.28.00 until v2026.09.28.00, WebTransportImpl::terminateSessionStreams (WebTransportImpl::destroy in releases before v2025.08.18.00) failed to unregister read callbacks for streams that were no longer open before destroying them. The transport could then invoke a read callback that had been freed.

• Facebook proxygen: affected from v2024.10.28.00 through releases less than v2026.09.28.00, using the supplied semver and lessThan conditions.
• Branch-specific function name: the flaw is described in WebTransportImpl::terminateSessionStreams; in releases before v2025.08.18.00, the corresponding routine is identified as WebTransportImpl::destroy. This is an implementation-name qualifier, not evidence that v2025.08.18.00 is a fixed release.
• The record sets default_status to unaffected and lists no additional products or parallel branches. The status of unlisted branches should not be inferred from this record.

Facebook proxygen manages WebTransport stream read callbacks through WebTransportImpl. A stream that has received data and FIN can no longer be open() while its read callback remains registered with the transport. During session teardown, WebTransportImpl::terminateSessionStreams failed to unregister that callback before destroying the stream handle, allowing the transport to invoke a callback whose object had already been freed. This is a CWE-416 Use After Free condition. In older releases, the corresponding routine is identified as WebTransportImpl::destroy. The associated upstream change tracks callback registration state and unregisters the callback before freeing the handle, but the record does not establish the complete wire-level input sequence required to trigger the flaw.

• Reachability: the flaw is in WebTransport processing that can be reached over the network.
• Conditions: the record describes exploitation without authentication or user interaction and with low attack complexity. A remote peer controls WebTransport traffic that determines stream state, but the exact stream sequence required to reach the vulnerable teardown condition is not documented.
• Exploitation status: the record does not confirm known exploitation, marks public exploit as false, and names no campaign, victim, or specific exploit.
• No confirmed IOC, log signature, or exploit payload is provided by the available evidence.

The flaw may allow the transport to invoke a read callback whose object was freed during WebTransport session teardown. The result can be invalid-memory access and disclosure of process data; the record does not establish code execution, data modification, or service interruption. The documented impact is concentrated on confidentiality, while integrity and availability are not established as affected. Because the described scope is unchanged, consequences remain within the service context running proxygen, but a remote network peer does not need special privileges or user interaction to reach the described processing path.

• Data risk: invoking a callback after its object has been freed can access invalid memory and may expose data held by the process. The record does not establish that actual data exfiltration occurred.
• Priority systems: services using proxygen to provide WebTransport to remote peers, particularly internet-facing services or services that accept traffic from untrusted networks.
• Operational scope: the library may be embedded in downstream applications, so checking only application-level package names can miss vulnerable proxygen copies.
• The record does not establish a specific data-modification or service-disruption consequence; the documented primary concern is confidentiality.

1. Upgrade Facebook proxygen to v2026.09.28.00, the boundary outside the supplied affected range for this branch. Do not treat this wording as confirmation that every later or parallel branch has been independently verified.
2. For source builds, apply the upstream change that tracks and unregisters the read callback before freeing the WebTransport stream handle, then rebuild and redeploy all affected binaries.
3. If an upgrade cannot be completed immediately, restrict network access to WebTransport endpoints using an affected build as a temporary exposure-reduction measure. This is a compensating control, not a fix for the defect.
4. Retest session teardown with a stream that has received data and FIN but is no longer open(), and verify that the transport no longer retains the read callback when the handle is destroyed.
5. After deployment, verify the version in the actual artifact and runtime image, not only in the source tree or dependency lockfile.

1. Inventory binaries, packages, and source builds that embed Facebook proxygen, then compare their exact versions with the affected branch.
2. Identify services that enable or accept WebTransport, especially services reachable from untrusted networks.
3. For source builds, inspect WebTransportImpl::terminateSessionStreams and the older WebTransportImpl::destroy implementation to confirm that the read callback is unregistered before the stream handle is destroyed. Compare the code with the upstream change that adds readCallbackRegistered tracking and corresponding teardown handling.
4. Review memory-safety diagnostics, crash reports, or sanitizer reports involving WebTransport teardown as a precaution, not as a confirmed indicator.
5. Do not treat the absence of a matching crash or log entry as proof of safety because the record provides no specific runtime indicator.