SURIQ
If you run a .NET service that authenticates callers with SAML tokens issued by a trusted security token service, check one thing before anything else: which version of CoreWCF it ships. A flaw disclosed on June 19 lets an attacker forge a SAML assertion and sign in as any identity that service trusts, an administrator included, with no password and no stolen credential. It carries a CVSS score of 10.0, the ceiling. There is no configuration workaround. The patch is the only fix.
The reach is narrower than "everyone on CoreWCF," and getting that distinction right is the difference between an all-nighter and a calm morning. Only services wired for federated, issued-token authentication are exposed. A plain SOAP service built on CoreWCF, with no federation in the picture, is not affected. So the first job is not patching. It is finding out whether you are even in scope.
What CVE-2026-54782 actually is
CoreWCF is the .NET Foundation's port of Windows Communication Foundation (WCF) to modern .NET, the supported path for teams moving legacy SOAP and WS-* services off the old framework. The bug lives in the CoreWCF.Primitives package. When a relying-party service validates an incoming issued SAML token, it does not properly verify the token's cryptographic signature. The advisory tags it as both improper verification of a cryptographic signature (CWE-347) and authentication bypass by spoofing (CWE-290). It applies to SAML 1.1 and SAML 2.0 alike.
A signature check is the one thing standing between a federated service and a forged identity. Break it, and an attacker who holds the trusted token service's public certificate, which federation publishes by design, can craft an assertion the service treats as genuine. The result, in the advisory's terms, is full impersonation of any principal that token service could have vouched for, administrators included when the service maps them through SAML claims.
Are you actually exposed?
Three conditions all have to hold. Walk your service host configuration and check for each:
- The service uses a federation binding,
WSFederationHttpBindingorWS2007FederationHttpBinding, or any binding that routes issued-token validation throughFederatedSecurityTokenManager. - Identity configuration is turned on, that is,
UseIdentityConfiguration = true. - The endpoint is reachable by the attacker over the network.
If any one of those is false, this particular bug does not apply to that service. The affected CoreWCF.Primitives versions are everything before 1.8.1, plus 1.9.0. The fixes are 1.8.1 and 1.9.1.
The three-day window most people missed
Here is a detail worth sitting with. The fixed builds, 1.8.1 and 1.9.1, shipped on June 16 as a servicing release described only as addressing "multiple security vulnerabilities." The detailed advisories, this CVSS 10 among them, did not go public until June 19. That release rolls up thirteen separate advisories.
For three days, a patched binary sat in public while the only public description told defenders nothing about what to prioritize. A patched binary is also a map. Anyone willing to diff 1.9.0 against 1.9.1 had a head start on the exact change that closes an unauthenticated admin-impersonation hole. Quiet servicing releases are not a security control. If you pin CoreWCF, treat any release that mentions security fixes as urgent even before the advisory text lands.
A class of bug that keeps scoring 10
SAML signature validation has a long record of producing full-impersonation flaws across unrelated codebases. ruby-saml, samlify, SSO parser-differential research, and a NetWeaver bypass this same month all share the shape: the assertion looks valid, the signature check has a gap, and the attacker becomes whoever they want. XML signature verification is genuinely hard to implement correctly, and federated auth is where teams most often assume the platform has it covered.
That assumption is the real lesson. The auth stack is exactly where defenders stop looking because they trust the framework, the same blind spot behind the Velvet Ant intrusion, behind Perry shipping a JWT helper that skipped expiry, and behind Quarkus reopening an auth bypass through encoded paths. A control that compiles and passes the happy path is not a control you have tested.
What to do now
Patch CoreWCF.Primitives to 1.8.1 or 1.9.1 today. No setting mitigates this short of the upgrade. Then:
- Inventory which services actually use federated bindings. Those are the ones that matter; everything else can move at normal pace.
- Tune detection around the outcome, not the entry. No credential is stolen and the certificate the attacker uses is public, so nothing looks wrong at the login layer. The signal is a successful federated authentication resolving to a principal that should not appear there, especially one carrying administrative claims. Alert on new or admin-level principals on these endpoints.
- Cut reachability where you can. A federated service that does not need to face a wide network is far less interesting to an attacker who has to reach it to forge anything.
No public exploitation has surfaced yet, and the CVE has not reached the National Vulnerability Database or CISA's exploited-vulnerabilities catalog. With a CVSS 10, no workaround, and a public patch that doubles as a blueprint, that quiet will not last. Patch before it ends.