CoreWCF CVE-2026-54774
HIGHSeverity by source
AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N
Network-reachable SAML endpoint (AV:N), no auth needed because the bug bypasses auth (PR:N), high complexity due to required non-X.509 STS configuration and known key identifier (AC:H); impersonation yields C:H/I:H, no availability impact.
Primary rating from Vendor (https://github.com/CoreWCF/CoreWCF).
CVSS VectorVendor: https://github.com/CoreWCF/CoreWCF
Lifecycle Timeline
2DescriptionCVE.org
Impact
When a service is configured to validate SAML tokens using a method other than X.509 certificate signing, the final signature verification is skipped.
Preconditions
The service is configured to authenticate using SAML tokens and an out of band token resolver (commonly the IssuerTokenResolver of IssuedTokenServiceCredential) holds a non-X.509 SecurityToken whose key identifier the attacker can reference in the assertion’s <KeyInfo> - for example a BinarySecretSecurityToken representing the symmetric proof key issued by a WS-Trust symmetric-key holder-of-key STS.
Patches
Fixed in CoreWCF v1.8.1 and v1.9.1
Workarounds
None
AnalysisAI
SAML token signature bypass in CoreWCF (versions <1.8.1 and 1.9.0) allows remote attackers to forge authenticated SAML assertions when the service validates tokens via a non-X.509 signing method. The SamlSerializer silently skips the final SignatureValue verification step, enabling assertion tampering and authentication bypass against WS-Trust holder-of-key configurations using symmetric proof keys. No public exploit identified at time of analysis, but the GitHub Security Advisory (GHSA-rpj7-hr7h-w6p9) confirms the issue and patches are available.
Technical ContextAI
CoreWCF is the community port of Windows Communication Foundation to .NET Core, providing SOAP/WS-* service hosting including WS-Security and WS-Trust. The flaw lives in SamlSerializer's signature verification path: when a SAML assertion's <KeyInfo> references a non-X.509 SecurityToken resolved out-of-band by an IssuerTokenResolver (such as a BinarySecretSecurityToken representing a symmetric proof key from a WS-Trust symmetric-key holder-of-key STS), the code returns before invoking the final SignatureValue cryptographic check. This is a CWE-345 (Insufficient Verification of Data Authenticity) defect - the signature element is parsed and the key is resolved, but the cryptographic comparison that proves the signature was produced by the holder of the key is bypassed entirely, breaking the SAML trust model.
RemediationAI
Vendor-released patch: upgrade CoreWCF.Primitives to 1.8.1 (for the 1.8.x branch) or 1.9.1 (for the 1.9.x branch) as published in GHSA-rpj7-hr7h-w6p9 (https://github.com/CoreWCF/CoreWCF/security/advisories/GHSA-rpj7-hr7h-w6p9). The advisory explicitly states no workarounds are available, so patching is the only supported mitigation; if upgrading must be delayed, operationally restrict SAML authentication to X.509-certificate-signed tokens by reconfiguring IssuedTokenServiceCredential to avoid out-of-band non-X.509 issuer token resolvers - this avoids the vulnerable code path but breaks WS-Trust symmetric-key holder-of-key flows and any federation that depends on BinarySecretSecurityToken-style proof keys. Auditing service authentication logs for unexpected SAML assertions and tightening network access to the SOAP endpoint can reduce exposure window pending the upgrade.
Same technique Denial Of Service
View allShare
External POC / Exploit Code
Leaving vuln.today
GHSA-rpj7-hr7h-w6p9