CoreWCF CVE-2026-54782
CRITICAL
GHSA-xjr9-gg9q-jx3v
Severity by source
AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N
Network-reachable federated endpoint, no auth or interaction required, only public STS certificate needed; scope changes as forged token crosses into relying-party identity context; no availability impact.
Primary rating from Vendor (https://github.com/CoreWCF/CoreWCF).
CVSS VectorVendor: https://github.com/CoreWCF/CoreWCF
Lifecycle Timeline
2DescriptionCVE.org
Impact
Full impersonation of any principal the trusted STS could have issued an assertion for - including administrative principals when the relying party grants them via SAML claims. Affects both SAML 1.1 and SAML 2.0.
Preconditions
Relying-party service is hosted with WSFederationHttpBinding or WS2007FederationHttpBinding (or any binding that triggers FederatedSecurityTokenManager for issued-token validation), and IdentityConfiguration is wired (UseIdentityConfiguration = true). Attacker can reach the service over the network and knows the trusted STS’s public certificate (public certs are by design discoverable).
Patches
Fixed in CoreWCF v1.8.1 and v1.9.1
Workarounds
None
AnalysisAI
Authentication bypass in CoreWCF (NuGet CoreWCF.Primitives) versions prior to 1.8.1 and 1.9.0-1.9.1 allows remote unauthenticated attackers to forge SAML 1.1 and SAML 2.0 assertions and impersonate any principal - including administrative identities - that the trusted STS could issue tokens for. The flaw stems from improper SAML token signature validation (CWE-290) in FederatedSecurityTokenManager, and only the trusted STS's public certificate (discoverable by design) is required. No public exploit identified at time of analysis and the issue is not on the CISA KEV list, but the CVSS 10.0 score with scope change reflects severe trust-boundary impact.
Technical ContextAI
CoreWCF is the community port of Windows Communication Foundation (WCF) to modern .NET, providing SOAP/WS-* services including federated identity flows. The vulnerable code path is reached when a relying-party service uses WSFederationHttpBinding or WS2007FederationHttpBinding (or any binding that engages FederatedSecurityTokenManager) and IdentityConfiguration is enabled (UseIdentityConfiguration = true). In this pipeline, SAML 1.1 and SAML 2.0 issued tokens are validated to confirm they were signed by the trusted STS - the root cause class, CWE-290 (Authentication Bypass by Spoofing), indicates that the signature check is insufficient, so an attacker who possesses only the STS's public certificate can craft assertions that the relying party will accept as if signed by the STS. The affected CPEs are pkg:nuget/corewcf.primitives across two release branches (1.x prior to 1.8.1, and the 1.9.0 line prior to 1.9.1).
RemediationAI
Vendor-released patch: upgrade CoreWCF.Primitives to 1.8.1 if you are on the 1.8.x branch, or to 1.9.1 if you are on the 1.9.x branch, per the GitHub Security Advisory at https://github.com/CoreWCF/CoreWCF/security/advisories/GHSA-xjr9-gg9q-jx3v. The vendor explicitly states there are no workarounds, so patching is the only fix. As compensating controls until the upgrade can be deployed, consider temporarily removing WSFederationHttpBinding / WS2007FederationHttpBinding endpoints from public exposure, setting UseIdentityConfiguration to false where federated SAML acceptance is not required (this disables federated auth on that endpoint), or restricting network reachability of the relying-party service to known client IP ranges via firewall or reverse proxy - each of these breaks federated SAML sign-in functionality for legitimate users, so they are stopgaps rather than substitutes for the patch.
Same weakness CWE-290 – Authentication Bypass by Spoofing
View allSame technique Authentication Bypass
View allShare
External POC / Exploit Code
Leaving vuln.today