CoreWCF CVE-2026-54779
MEDIUM
GHSA-9jr3-rj99-8jq3
Severity by source
AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N
AC:H reflects mandatory prior token capture; PR:N because the attacker presents a stolen credential without holding system privileges; I:H for full user impersonation; C:N as no data is directly disclosed by the replay itself.
Primary rating from Vendor (https://github.com/CoreWCF/CoreWCF).
CVSS VectorVendor: https://github.com/CoreWCF/CoreWCF
Lifecycle Timeline
2DescriptionCVE.org
Impact
When enabling DetectReplayedTokens, a token can be replayed and will be detected despite it being reused.
Patches
Fixed in CoreWCF v1.8.1 and v1.9.1
Workarounds
Provide your own implementation of ITokenReplayCache with the correct behavior.
AnalysisAI
SAML token replay protection in CoreWCF.Primitives is silently inoperative when DetectReplayedTokens is explicitly enabled, allowing replay attacks to succeed against WCF services using SAML-based federated authentication. Affected versions of the NuGet package CoreWCF.Primitives include all releases before 1.8.1 and the 1.9.0 release prior to 1.9.1. A network-accessible attacker in possession of a valid, unexpired SAML token can replay it to impersonate a legitimate user, defeating the only control operators may have believed was protecting against token theft - no public exploit code has been identified, and this is not listed in CISA KEV.
Technical ContextAI
CoreWCF is the open-source .NET port of Windows Communication Foundation, and CoreWCF.Primitives (pkg:nuget/corewcf.primitives) provides the foundational token-handling infrastructure including SAML security token validators. CWE-294 (Authentication Bypass by Capture-replay) identifies the root cause: the ITokenReplayCache abstraction, which is supposed to record and reject previously seen token identifiers within their validity window, does not function correctly in affected versions. When a service is configured to call DetectReplayedTokens, the broken cache implementation fails to flag re-presented token IDs as already seen, so the replayed token passes validation as if it were fresh. The flaw undermines a defense-in-depth control that organizations must explicitly opt into, meaning its failure is invisible without active monitoring of duplicate token submissions.
RemediationAI
Vendor-released patches are available: upgrade CoreWCF.Primitives to version 1.8.1 if on the 1.8.x release train, or to version 1.9.1 if on the 1.9.x release train, via NuGet. The advisory is at https://github.com/CoreWCF/CoreWCF/security/advisories/GHSA-9jr3-rj99-8jq3. If immediate patching is not possible, the vendor-endorsed workaround is to provide a custom implementation of the ITokenReplayCache interface with correct replay detection logic, which replaces the broken built-in cache while preserving the DetectReplayedTokens feature - this requires development effort but eliminates the flaw without upgrading. As a last resort, disabling DetectReplayedTokens removes the broken code path, but this entirely removes replay protection; if taken, operators should compensate by enforcing very short SAML token lifetimes (minutes rather than hours) and restricting service endpoints to trusted network segments to narrow the replay window.
Same weakness CWE-294 – Authentication Bypass by Capture-replay
View allSame technique Information Disclosure
View allShare
External POC / Exploit Code
Leaving vuln.today