CoreWCF SAML Token Replay Cache Bypass Vulnerability
CoreWCF is a port of the service side of Windows Communication Foundation (WCF) to .NET Core. Prior to 1.8.1 and 1.9.1, CoreWCF SAML token replay protection is inoperative because DefaultTokenReplayCache.TryAdd does not reject duplicate tokens when DetectReplayedTokens is enabled, allowing a captured token to be reused. This issue is fixed in versions 1.8.1 and 1.9.1.
Quick answer
CoreWCF Project CoreWCF should be reviewed and updated if it matches the affected versions. The recommended fix is to apply the vendor-supported patched version or the mitigation steps below, then retest the public website with Fixnx.
Who is affected
Affected versions
- CoreWCF before 1.8.1
- CoreWCF 1.9.0 before 1.9.1
Fixed versions
- 1.8.1
- 1.9.1
How to fix it
CoreWCF before 1.8.1 and 1.9.1 can fail to reject duplicate SAML tokens even when replay detection is enabled. Upgrade CoreWCF and review SAML token replay controls for affected services.
- Identify CoreWCF services that rely on SAML token replay detection.
- Upgrade CoreWCF to 1.8.1, 1.9.1, or later.
- Verify DetectReplayedTokens and replay cache settings are enabled for sensitive services.
- Expire current SAML sessions and reduce token validity during the patch window.
- Review access logs for repeated token IDs, duplicate assertions, or repeated SOAP envelopes.
- Restrict access to SAML-backed endpoints until replay controls are confirmed.
- Tune replay cache retention to cover the full accepted token lifetime.
Scan now. Google sign-in is only needed to unlock fix guidance.
Verify the fix
- Confirm patched CoreWCF packages are running.
- Replay a previously accepted SAML token in a safe test and confirm it is rejected.
- Verify replay cache metrics or logs show duplicate detection.
- Review authentication logs for repeated assertion IDs.
- Run a Fixnx scan and confirm affected endpoints are not unnecessarily public.
Related categories
Trusted references
FAQ
What is affected by CVE-2026-54779?
CoreWCF Project CoreWCF versions listed as affected should be reviewed: CoreWCF before 1.8.1, CoreWCF 1.9.0 before 1.9.1.
What should I fix first?
Start with internet-facing sites, admin panels, login flows, plugins, themes, modules, packages, and systems that process user-controlled input or sensitive data.
How do I confirm the fix worked?
Apply the patched version or mitigation, clear caches where relevant, retest the affected workflow, and run a new Fixnx scan to verify public website exposure signals.
Why can this risk appear in multiple categories?
A vulnerability can belong to more than one platform or ecosystem. Fixnx keeps one canonical risk page while also listing it in every relevant category.