CVE-2026-54775: CoreWCF Kafka Denial of Service via Tombstone Records

Technical summary

The vulnerability resides in CoreWCF's KafkaTransportPump component, which handles message consumption from Kafka topics in service endpoints. The defect involves improper exception handling or validation when processing null-value tombstone records. When such a record is encountered, the pump enters a failed state and ceases polling for new messages, effectively halting all inbound message processing on the affected topic. The root cause maps to CWE-248 (uncaught exception), CWE-754 (improper error handling), and CWE-755 (improper handling of exceptional conditions), indicating that the component fails to gracefully handle or validate the tombstone message format. No authentication bypass, data exfiltration, or integrity compromise occurs—impact is strictly availability-focused.

Business impact

Services relying on CoreWCF for Kafka-based messaging face application-level downtime without requiring service compromise or privilege escalation. For organizations using CoreWCF endpoints as critical integration points (event processing, order handling, real-time analytics), a single malicious tombstone record can trigger persistent outages affecting dependent downstream systems. Recovery requires manual intervention—service restart or Kafka topic reset—introducing operational friction. The attack is particularly impactful in multi-tenant or shared Kafka environments where an attacker with producer credentials (intentional or leaked) can disrupt unrelated services. This creates a secondary risk vector if Kafka credentials are compromised elsewhere in the supply chain.

Affected systems

Any CoreWCF service version 1.8.0 or earlier, or version 1.9.0, that uses Kafka transport is vulnerable. The defect is specific to the Kafka transport pump; services using other CoreWCF transports (HTTP, named pipes, TCP) are unaffected. Organizations should audit their CoreWCF deployments for Kafka-based endpoints. The vulnerability does not affect the original Windows Communication Foundation (WCF) on the .NET Framework—only the CoreWCF port on .NET Core.

Exploitability

Exploitability is straightforward for any actor holding valid Kafka producer credentials for the target topic. No special tooling is required; standard Kafka producers (kafka-console-producer, librdkafka, confluent-kafka) can craft and send a null-value tombstone record. The attack is reliable and deterministic—one malicious message reliably disables the endpoint. Barrier to exploitation is moderate: attacker must identify a vulnerable CoreWCF service on Kafka and possess or obtain producer permissions. In containerized environments with shared Kafka clusters or where Kafka credentials are stored in configuration files, this is a realistic threat. The attack leaves minimal forensic traces, as the triggering message is legitimate Kafka protocol syntax.

Remediation

Upgrade CoreWCF to version 1.8.1 or later (for the 1.8.x branch) or version 1.9.1 or later (for the 1.9.x branch). Verify the exact version in your environment via dotnet list package or NuGet package manager, then update through your dependency management process. Additionally, restrict Kafka producer ACLs to only authenticated and authorized services; avoid granting broad produce permissions to shared credentials or service accounts. Isolate Kafka topics handling CoreWCF traffic from untrusted producers where possible, and monitor Kafka topic activity for anomalous tombstone records.

Patch guidance

1. Identify all projects and services referencing the CoreWCF NuGet package. Check your build configuration files (*.csproj, packages.config) and NuGet package manager for the installed version. 2. Upgrade CoreWCF to 1.8.1 or 1.9.1 or later by updating the package reference. If you are on an older major version, consult the CoreWCF release notes for migration guidance. 3. Recompile and test your service integration with Kafka in a staging environment to ensure no behavioral changes. 4. Deploy the updated service alongside updated Kafka ACL policies restricting producer access. 5. Monitor the Kafka topic in production for tombstone records and unusual producer activity immediately after deployment. 6. Consider disabling or auditing any non-critical producer clients with credentials to the affected topics.

Detection guidance

Search build artifacts, container images, and runtime diagnostics for CoreWCF versions <1.8.1 or 1.9.0 using SBOM tools, SCA scanners, or package listing commands (dotnet list package --outdated). Monitor Kafka topic logs and broker metrics for tombstone records (null-value messages) being produced to topics consumed by CoreWCF services. Alert on any CoreWCF Kafka consumer groups that stop committing offsets, as this indicates pump failure. Review Kafka ACL audit logs for unexpected or dormant producer identities with access to CoreWCF-consumed topics. Instrument CoreWCF endpoints with Application Insights or similar observability to detect message-processing halts (sudden drop in inbound message rate with no corresponding error logs).

Why prioritize this

This vulnerability merits medium-high priority despite the MEDIUM CVSS score because it enables trivial, undetected denial of service against critical message-driven services. Organizations using CoreWCF for event-driven architectures should prioritize patching, especially if Kafka topics handle payment processing, order fulfillment, or real-time alerts. The low barrier to exploitation and lack of KEV status (not yet in active exploitation) make this a window for proactive remediation before widespread tooling emerges.

Risk score, explained

CVSS 3.1 base score of 6.5 (MEDIUM) reflects high availability impact (A:H) but limited scope and lack of confidentiality or integrity exposure. The attack vector is Network (AV:N), complexity is Low (AC:L), and requires Low privileges (PR:L—valid Kafka producer credentials). The score appropriately penalizes the availability impact but does not account for operational context: a persistent outage on a critical service may warrant internal risk elevation beyond the base score. Organizations should apply business context multipliers (service criticality, blast radius, recovery difficulty) to determine actual remediation urgency.

Frequently asked questions