CoreWCF CVE-2026-54784
HIGH
GHSA-2288-8h3r-cqgg
Severity by source
AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N
Network-reachable and unauthenticated (AV:N, PR:N), but requires on-path observation of the SCT handshake and a non-TLS configuration (AC:H); session keys recovered yield full read/forge of session traffic (C:H/I:H), no availability impact (A:N).
Primary rating from Vendor (https://github.com/CoreWCF/CoreWCF).
CVSS VectorVendor: https://github.com/CoreWCF/CoreWCF
Lifecycle Timeline
3DescriptionCVE.org
Impact
When the proof key recovered from the RSTR can be observed by a party that is not the legitimate client, that party can impersonate the authenticated Windows principal for the lifetime of the SCT (default ~10 hours) and decrypt or forge any subsequent WS‑SecureConversation traffic that uses keys derived from the SCT.
Preconditions
Using security mode TransportWithMessageCredential with client credential type Windows, along with session establishment (which triggers use of WS-SecureConversation).
Patches
Fixed in CoreWCF v1.9.1
Workarounds
Ensure communication is protected by SSL/TLS to prevent capturing of SCT negotiation handshake.
AnalysisAI
Authenticated principal impersonation in CoreWCF (versions >=1.9.0, <1.9.1) occurs because the SPNEGO SecurityContextToken proof key returned in the RequestSecurityTokenResponse (RSTR) is wrapped without confidentiality protection, allowing any on-path observer to recover it. An attacker who captures the unprotected handshake can impersonate the authenticated Windows principal for the SCT lifetime (~10 hours) and decrypt or forge subsequent WS-SecureConversation traffic. No public exploit identified at time of analysis, but the vendor-confirmed advisory (GHSA-2288-8h3r-cqgg) and CVSS 7.4 indicate a meaningful confidentiality/integrity exposure for affected .NET WCF replacement deployments.
Technical ContextAI
CoreWCF is the community-maintained .NET (Core) port of Windows Communication Foundation, distributed as the nuget package CoreWCF.Primitives. The flaw lives in the SPNEGO-based SecurityContextToken (SCT) negotiation used by WS-Trust/WS-SecureConversation: the proof key returned inside the RSTR is not properly encrypted (wrapped) for the client, exposing the symmetric key material to any party that observes the message. This maps to CWE-311 (Missing Encryption of Sensitive Data) - the protocol-level confidentiality control that should protect the bootstrap key material is absent, so all derived session keys can be reconstructed by the observer. Because the SCT establishes the cryptographic context for an entire WS-SecureConversation session, recovery of the proof key undermines both confidentiality and message-origin authentication for the session's lifetime.
RemediationAI
Vendor-released patch: CoreWCF 1.9.1 - upgrade the CoreWCF.Primitives NuGet package to 1.9.1 or later as the primary fix, per advisory https://github.com/CoreWCF/CoreWCF/security/advisories/GHSA-2288-8h3r-cqgg. Where immediate patching is not possible, the vendor-supplied workaround is to ensure the channel is protected by SSL/TLS so that the SCT negotiation handshake cannot be captured by an on-path observer; operationally this means enforcing HTTPS transport on the WCF endpoint and rejecting plaintext HTTP bindings, with the trade-off of needing valid server certificates and possible client compatibility testing. As a defense-in-depth measure, environments that do not require WS-SecureConversation sessions can switch the binding away from TransportWithMessageCredential with Windows credentials (for example to Transport security with Windows auth without message-level session establishment), at the cost of losing message-level credential flows.
Same weakness CWE-311 – Missing Encryption of Sensitive Data
View allSame technique Information Disclosure
View allShare
External POC / Exploit Code
Leaving vuln.today