CVE-2026-54781: CoreWCF Auth Bypass Vulnerability

CVE-2026-54781 Overview

CVE-2026-54781 is an authentication bypass vulnerability [CWE-287] in CoreWCF, the .NET Core port of the service side of Windows Communication Foundation (WCF). The flaw resides in SamlSecurityTokenHandler where SAML token validation does not enforce SubjectConfirmation method URIs or holder-of-key proof keys. An attacker can present a SAML assertion using an unrecognized confirmation method or downgrade a holder-of-key assertion, and CoreWCF will authenticate the subject without the caller proving authority over the assertion. Versions prior to 1.8.1 and 1.9.1 are affected, and the issue is fixed in 1.8.1 and 1.9.1.

Critical Impact
Remote attackers can authenticate as arbitrary subjects to CoreWCF services that accept SAML tokens, breaking service authentication and enabling impersonation without proof-of-possession of a key.

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 using SamlSecurityTokenHandler for SAML 1.1 token validation

Discovery Timeline

2026-07-08 - CVE-2026-54781 published to NVD
2026-07-08 - Last updated in NVD database
GHSA-48pq-2xq3-c2m4 - GitHub Security Advisory published by the CoreWCF project

Technical Details for CVE-2026-54781

Vulnerability Analysis

SAML 1.1 assertions carry a <SubjectConfirmation> element declaring how the caller proves it is the subject named in the assertion. The standard methods are bearer, sender-vouches, and holder-of-key. The holder-of-key method requires a <SubjectConfirmationData> containing a <KeyInfo> proof key, and the relying party must verify the caller controls that key. In vulnerable CoreWCF releases, SamlSecurityTokenHandler accepts the assertion without inspecting the confirmation method URI and without requiring a proof key for holder-of-key.

This allows two attack shapes. First, an attacker can submit an assertion declaring an arbitrary or unrecognized confirmation method, and CoreWCF still returns a populated ClaimsPrincipal. Second, an attacker can present a holder-of-key assertion with no <KeyInfo>, effectively downgrading it to bearer semantics without ever proving possession of the key referenced by the issuing IdP.

Root Cause

The root cause is missing validation logic in the token handler pipeline. Before the fix, SamlSecurityTokenHandler.ValidateToken passed the assertion directly to the internal validator without calling a method to enforce confirmation semantics. The patch introduces ValidateSubjectConfirmations(samlToken.Assertion) and two new resource strings, SAMLHolderOfKeyRequiresKeyInfo and SAMLUnrecognizedConfirmationMethod, restricting accepted methods to the three defined by SAML 1.1 and requiring <KeyInfo> for holder-of-key.

Attack Vector

Exploitation occurs over the network against any CoreWCF endpoint that authenticates callers via SAML tokens. The attacker crafts or replays a SAML assertion whose <SubjectConfirmation> element either omits <KeyInfo> while claiming holder-of-key, or specifies a non-standard confirmation method URI. No user interaction is required. Attack complexity is high because the attacker must still obtain or generate an assertion that the configured issuer signing key trusts.

text

// Security patch: src/CoreWCF.Primitives/src/CoreWCF/IdentityModel/Tokens/SamlSecurityTokenHandler.cs
                throw DiagnosticUtility.ExceptionUtility.ThrowHelperArgument(nameof(token), SR.Format(SR.ID1034));
            }

+           ValidateSubjectConfirmations(samlToken.Assertion);
+
            string assertionXML = samlToken.AssertionXML;
            SamlTokenValidationParameters tokenValidation = new SamlTokenValidationParameters();
            ClaimsPrincipal claim = _internalSamlSecurityTokenHandler.ValidateToken(assertionXML,

// New resource strings enforced by ValidateSubjectConfirmations:
+  SAMLHolderOfKeyRequiresKeyInfo: "The SamlSubject specifies the holder-of-key confirmation
+    method but does not contain a SubjectConfirmationData <KeyInfo>. Holder-of-key tokens
+    require a proof key."
+  SAMLUnrecognizedConfirmationMethod: "The SamlSubject contains an unrecognized confirmation
+    method '{0}'. Only the bearer, sender-vouches, and holder-of-key methods defined by
+    SAML 1.1 are accepted."

Source: CoreWCF commit 6a99df3

Detection Methods for CVE-2026-54781

Indicators of Compromise

SAML assertions received by CoreWCF services where <SubjectConfirmationMethod> is not one of urn:oasis:names:tc:SAML:1.0:cm:bearer, urn:oasis:names:tc:SAML:1.0:cm:sender-vouches, or urn:oasis:names:tc:SAML:1.0:cm:holder-of-key.
holder-of-key assertions lacking a <SubjectConfirmationData><KeyInfo> element accepted by pre-patch CoreWCF hosts.
Successful authentications to CoreWCF endpoints originating from unexpected client IPs, ASNs, or workload identities.
Multiple distinct subjects authenticating from a single caller within a short window, indicating assertion reuse.

Detection Strategies

Enable SAML request logging on CoreWCF services and parse <SubjectConfirmation> elements for confirmation method URI and presence of <KeyInfo>.
Deploy a filtering proxy or WCF IDispatchMessageInspector that rejects assertions failing the same rules the patch enforces.
Correlate CoreWCF authentication events with IdP issuance logs to identify assertions consumed against endpoints they were not scoped for.

Monitoring Recommendations

Alert on any CoreWCF service still running an installed package version below 1.8.1 or 1.9.1.
Monitor .NET process telemetry for CoreWCF.Primitives.dll versions and flag hosts pinned to vulnerable releases.
Track spikes in SAML validation exceptions after patching, which surface external actors probing with malformed confirmation elements.

How to Mitigate CVE-2026-54781

Immediate Actions Required

Upgrade CoreWCF.Primitives and dependent CoreWCF packages to 1.8.1 for the 1.8.x branch or 1.9.1 for the 1.9.x branch.
Inventory all .NET services referencing CoreWCF NuGet packages and confirm their resolved versions after rebuild.
Rotate any keys or signing certificates trusted by CoreWCF SAML validators if abuse is suspected during the exposure window.
Restrict CoreWCF endpoints that accept SAML tokens to trusted network segments until the patched build is deployed.

Patch Information

The CoreWCF maintainers released fixed builds tagged v1.8.1 and v1.9.1. The fix is implemented across commits 6a99df3, 86dd323, and 9eb9b46, and documented in GHSA-48pq-2xq3-c2m4.

Workarounds

Replace the default SamlSecurityTokenHandler with a custom handler that calls a validator inspecting SubjectConfirmation method URIs and enforcing <KeyInfo> for holder-of-key.
Disable SAML authentication on CoreWCF services and switch to an alternate credential type until the packages can be upgraded.
Terminate SAML validation at an upstream gateway that enforces confirmation method and proof-key policy before the request reaches CoreWCF.

bash

# Upgrade CoreWCF packages in a .NET project
dotnet add package CoreWCF.Primitives --version 1.9.1
dotnet add package CoreWCF.Http --version 1.9.1
dotnet add package CoreWCF.WebHttp --version 1.9.1

# Or, for projects pinned to the 1.8.x branch
dotnet add package CoreWCF.Primitives --version 1.8.1

# Verify resolved versions
dotnet list package --include-transitive | grep -i corewcf