CVE-2026-54772 Overview
CVE-2026-54772 is a denial-of-service vulnerability in CoreWCF, the .NET Core port of the service side of Windows Communication Foundation (WCF). Versions prior to 1.8.1 and 1.9.1 mishandle premature end-of-file (EOF) conditions during the framing handshake used by NetTcpBinding, NetNamedPipeBinding, and UnixDomainSocketBinding endpoints. An unauthenticated remote attacker who can reach these endpoints can trigger a tight loop in the framing decoder, pinning one server thread-pool worker at full CPU per connection. The weakness is classified under [CWE-400: Uncontrolled Resource Consumption].
Critical Impact
Each attacker connection consumes a full CPU core on the server. A small number of connections is sufficient to exhaust available thread-pool workers and render the service unresponsive.
Affected Products
- CoreWCF versions prior to 1.8.1 (1.8.x branch)
- CoreWCF versions prior to 1.9.1 (1.9.x branch)
- Services exposing NetTcpBinding, NetNamedPipeBinding, or UnixDomainSocketBinding endpoints
Discovery Timeline
- 2026-07-08 - CVE-2026-54772 published to NVD
- 2026-07-08 - Last updated in NVD database
Technical Details for CVE-2026-54772
Vulnerability Analysis
The CoreWCF net.tcp, net.pipe, and net.uds transports use a framing handshake to negotiate the session before any application-layer messages are exchanged. During this handshake, the middleware reads bytes from a System.IO.Pipelines.PipeReader and feeds them into ServerSessionDecoder until the decoder reaches the PreUpgradeStart state. When the peer closes the TCP or pipe connection before sending a valid via record, PipeReader.ReadAsync() returns a completed ReadResult with an empty buffer.
The vulnerable code does not check readResult.IsCompleted in conjunction with buffer.IsEmpty. Instead, the outer while loop calls ReadAsync again, which immediately returns synchronously with the same empty completed result. The decoder never advances, no exception is thrown, and the worker thread spins indefinitely. A similar defect exists in RawStream.ReadAsync, which loops when the underlying pipe is completed with no data available.
Root Cause
The root cause is missing termination logic for a completed PipeReader in two locations: DuplexFramingMiddleware and RawStream, both under src/CoreWCF.NetFramingBase/src/CoreWCF/Channels/Framing/. Neither call site treated a closed peer connection as a terminal condition, so a synchronous empty read result produced an unbounded CPU-bound loop rather than a graceful EOF.
Attack Vector
Exploitation requires only network reachability to a vulnerable framing endpoint. No authentication, credentials, or user interaction are needed. The attacker opens a TCP connection (or named pipe / Unix domain socket connection) to the CoreWCF service and immediately closes it without transmitting a via record. The server-side handshake enters the tight loop and consumes 100% of one thread-pool worker. Repeating the pattern across multiple connections exhausts the thread pool and denies service to legitimate clients.
// Patch: src/CoreWCF.NetFramingBase/src/CoreWCF/Channels/Framing/DuplexFramingMiddleware.cs
ReadOnlySequence<byte> buffer;
while (decoder.CurrentState != ServerSessionDecoder.State.PreUpgradeStart)
{
- System.IO.Pipelines.ReadResult readResult = await connection.Input.ReadAsync();
+ System.IO.Pipelines.ReadResult readResult = await connection.Input.ReadAsync(connection.ChannelInitializationCancellationToken);
buffer = readResult.Buffer;
+ if (readResult.IsCompleted && buffer.IsEmpty)
+ {
+ // The peer closed the connection before sending the via record. Surface
+ // this as a premature EOF; otherwise PipeReader.ReadAsync would keep
+ // returning synchronously with an empty buffer and the outer loop would
+ // never make progress.
+ throw DiagnosticUtility.ExceptionUtility.ThrowHelperError(decoder.CreatePrematureEOFException());
+ }
+
while (buffer.Length > 0)
{
int bytesDecoded = decoder.Decode(buffer);
// Source: https://github.com/CoreWCF/CoreWCF/commit/03ddbced349931a2da6c0efcdf745c0722eff77c
The companion fix in RawStream.cs returns 0 when the PipeReader result is completed, signaling end-of-stream to callers:
// Patch: src/CoreWCF.NetFramingBase/src/CoreWCF/Channels/Framing/RawStream.cs
readableBuffer.CopyTo(destination.Span);
return count;
}
+
+ if (result.IsCompleted)
+ {
+ // Treat a closed PipeReader as end-of-stream instead of looping;
+ // otherwise an empty + completed result would cause this read to
+ // make no progress.
+ return 0;
+ }
}
finally
{
// Source: https://github.com/CoreWCF/CoreWCF/commit/03ddbced349931a2da6c0efcdf745c0722eff77c
Detection Methods for CVE-2026-54772
Indicators of Compromise
- Sustained high CPU usage in the CoreWCF host process with no corresponding increase in completed WCF requests.
- Short-lived TCP connections to net.tcp listener ports (default 808/tcp) that terminate immediately after the TCP handshake without sending framing data.
- Growth in the number of active thread-pool worker threads while ServicePointManager connection counts remain low.
- Application logs showing no PrematureEOFException entries prior to the patch, despite abnormal connection churn.
Detection Strategies
- Instrument the CoreWCF host with .NET runtime counters (System.Runtime and Microsoft-AspNetCore-Server-Kestrel) and alert on threadpool-thread-count climbing without matching requests-per-second.
- Deploy network monitoring on ports serving NetTcpBinding endpoints to identify sources that open TCP sessions and close them before transmitting the initial via record.
- Correlate process CPU consumption with per-connection lifetime; connections lasting milliseconds but leaving worker threads busy indicate the loop condition.
Monitoring Recommendations
- Enable ETW or EventPipe tracing for Microsoft-Extensions-Logging inside CoreWCF and forward events to a centralized log platform for baseline analysis.
- Track thread-pool starvation metrics and alert when queued work items exceed a rolling baseline.
- Review firewall and load-balancer logs for repeated connection resets from single source IPs against net.tcp listeners.
How to Mitigate CVE-2026-54772
Immediate Actions Required
- Upgrade CoreWCF to 1.8.1 or 1.9.1 (or later) using the NuGet package manager and redeploy affected services.
- Inventory all services exposing NetTcpBinding, NetNamedPipeBinding, or UnixDomainSocketBinding endpoints and prioritize internet-reachable listeners.
- Restrict network access to CoreWCF framing endpoints so that only trusted client networks can reach them until the patch is deployed.
Patch Information
The fixes are delivered in CoreWCF Release v1.8.1 and CoreWCF Release v1.9.1. The corrective changes are documented in commits 03ddbce, 7ddd966, and c421298. Full advisory context is available in GitHub Security Advisory GHSA-p86g-xrr2-pf7c.
Workarounds
- Place the CoreWCF service behind a reverse proxy or firewall that enforces short idle timeouts and rate-limits incoming TCP connections per source IP.
- Disable NetTcpBinding, NetNamedPipeBinding, and UnixDomainSocketBinding endpoints where they are not required, and prefer HTTP-based bindings until the upgrade is complete.
- Configure the host with a bounded thread-pool ceiling and connection concurrency limits so a spike in stuck workers cannot fully starve the process.
# Update CoreWCF via the .NET CLI to a patched version
dotnet add package CoreWCF.NetTcp --version 1.9.1
dotnet add package CoreWCF.Primitives --version 1.9.1
dotnet add package CoreWCF.NetFramingBase --version 1.9.1
# Verify installed versions
dotnet list package | grep -i CoreWCF
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.
