CVE-2026-54775: CoreWCF Kafka DoS Vulnerability

CVE-2026-54775 Overview

CVE-2026-54775 affects CoreWCF, a port of the service side of Windows Communication Foundation (WCF) to .NET Core. The vulnerability exists in the KafkaTransportPump component used by CoreWCF services listening on Kafka topics. When the transport pump receives a null-value tombstone record, it stops processing new records from that topic. This produces a persistent endpoint denial of service condition against the affected service. Any authenticated attacker with produce permission on the target Kafka topic can trigger the condition. The issue is fixed in CoreWCF versions 1.8.1 and 1.9.1.

Critical Impact
An attacker with Kafka produce permission can permanently halt message consumption on a CoreWCF endpoint by publishing a single tombstone record, resulting in service-level denial of service.

Affected Products

CoreWCF versions prior to 1.8.1
CoreWCF versions prior to 1.9.1 (in the 1.9.x branch)
Applications using the CoreWCF.Kafka transport package

Discovery Timeline

2026-07-08 - CVE-2026-54775 published to NVD
2026-07-08 - Last updated in NVD database

Technical Details for CVE-2026-54775

Vulnerability Analysis

CoreWCF exposes WCF-style services over Kafka using the KafkaTransportPump class in src/CoreWCF.Kafka/src/CoreWCF/Channels/KafkaTransportPump.cs. The pump runs a continuous consume loop that reads records from a subscribed Kafka topic and dispatches them to service dispatchers. When a null-value tombstone record arrives on the topic, downstream processing raises an unhandled exception. The pre-patch consume loop treats any exception as fatal, logs it, and breaks out of the loop. Once the loop exits, the endpoint no longer consumes new records and requires a service restart to recover. The weakness is classified as [CWE-248] Uncaught Exception.

Root Cause

The root cause is unsafe exception handling in the Kafka consume loop combined with lack of validation for tombstone records. Kafka tombstones — records with a non-null key and a null value — are a legitimate protocol construct used to signal record deletion in compacted topics. The transport pump did not account for the null payload, and its outer catch block responded to the resulting exception with break, terminating the pump instead of continuing to poll.

Attack Vector

Exploitation requires network access to the Kafka broker and produce permission on the topic the CoreWCF service consumes. No user interaction is needed. An attacker publishes a single record with a null value to the topic, which causes the target service's consume loop to exit and stop processing further messages, including legitimate traffic from other producers.

text

                 }
                 catch (Exception e)
                 {
-                    _logger.LogCritical(e, "Unexpected error");
-                    break;
+                    _logger.LogCritical(e, "Unexpected error in consume loop; continuing");
+                    try
+                    {
+                        await Task.Delay(TimeSpan.FromMilliseconds(100), _cts.Token);
+                    }
+                    catch (OperationCanceledException)
+                    {
+                        break;
+                    }
                 }
             }
             _mres.Set();

Source: CoreWCF Commit Fix

The patch replaces the unconditional break with a short delay and continues the loop, preserving pump availability across transient consume errors.

Detection Methods for CVE-2026-54775

Indicators of Compromise

Log entries containing "Unexpected error" or "Unexpected error in consume loop" emitted at Critical level by the CoreWCF Kafka transport.
Sudden drop of Kafka consumer lag increase on a topic served by a CoreWCF endpoint with no corresponding process crash.
Kafka producer activity from unexpected client IDs publishing records with null values on service topics.

Detection Strategies

Monitor KafkaTransportPump log output for critical exceptions followed by cessation of consumer offset commits.
Compare producer identities and payload sizes against an allowlist for each Kafka topic consumed by CoreWCF services.
Correlate service-level request timeouts with lack of new offsets committed by the CoreWCF consumer group.

Monitoring Recommendations

Instrument the CoreWCF service host with health checks that verify recent message consumption progress and alert when consumer lag stops decreasing.
Enable Kafka broker audit logging for produce operations and review records with null values.
Track process uptime alongside consumer offset advancement to detect stalled pumps without service restarts.

How to Mitigate CVE-2026-54775

Immediate Actions Required

Upgrade CoreWCF to version 1.8.1 or 1.9.1, matching the branch currently deployed.
Restrict Kafka Produce ACLs on service topics to trusted producer identities only.
Restart any CoreWCF service instance that has stopped consuming records to restore availability while patching.

Patch Information

The fix is available in CoreWCF releases v1.8.1 and v1.9.1. Technical details are described in the CoreWCF Security Advisory GHSA-m744-jhq9-ppw6. The patch modifies KafkaTransportPump.cs so the consume loop tolerates exceptions, delays briefly, and resumes polling instead of terminating.

Workarounds

Apply Kafka ACLs that limit Produce permission on CoreWCF-consumed topics to a small set of trusted service principals.
Deploy a supervisor or orchestrator liveness probe that restarts the CoreWCF host when the consumer group stops advancing offsets.
Where feasible, isolate CoreWCF topics from compacted topics so tombstone records are not expected on the service consumer path.

bash

# Kafka ACL example restricting Produce to a specific service principal
kafka-acls.sh --bootstrap-server broker:9092 \
  --add \
  --allow-principal User:corewcf-producer \
  --operation Write \
  --topic corewcf-service-topic

kafka-acls.sh --bootstrap-server broker:9092 \
  --add \
  --deny-principal User:* \
  --operation Write \
  --topic corewcf-service-topic