CVE-2026-54784: 
C# 脆弱性の分析と軽減

CVE-2026-54784 is a cryptographic flaw in CoreWCF (the open-source .NET implementation of WCF) where the SPNEGO SecurityContextToken (SCT) proof key is wrapped without confidentiality protection during WS-SecureConversation session establishment. An attacker who can observe the Request Security Token Response (RSTR) can recover the proof key and subsequently impersonate the authenticated Windows principal for the lifetime of the SCT (default ~10 hours). The vulnerability affects CoreWCF.Primitives NuGet package versions >= 1.9.0 and < 1.9.1. It was published on June 16, 2026, and carries a CVSS v3.1 base score of 7.4 (High) (GitHub Advisory, CoreWCF Advisory).

The root cause is classified under CWE-311 (Missing Encryption of Sensitive Data) and CWE-523 (Unprotected Transport of Credentials). During WS-SecureConversation session establishment using SPNEGO with TransportWithMessageCredential security mode and Windows client credential type, the proof key included in the RSTR is not wrapped with confidentiality protection. This means any network-adjacent party capable of intercepting the SCT negotiation handshake can extract the proof key in plaintext. The attack requires high complexity (network interception of the handshake), no privileges, and no user interaction, but is limited to deployments using the specific security mode and credential type combination (GitHub Advisory, CoreWCF Advisory).

A successful attacker who recovers the proof key can impersonate the authenticated Windows principal for the full SCT lifetime (approximately 10 hours by default), and can decrypt or forge any subsequent WS-SecureConversation traffic whose session keys are derived from the compromised SCT. This results in high confidentiality and integrity impact — sensitive business data transmitted over the WCF channel can be read or tampered with — though availability is not directly affected. The scope is limited to services configured with TransportWithMessageCredential and Windows credentials using session-based security (GitHub Advisory).

1. Reconnaissance: Identify CoreWCF-based services (version 1.9.0) configured with TransportWithMessageCredential security mode and Windows client credential type, which trigger WS-SecureConversation session establishment.
2. Network Positioning: Gain a network-adjacent position capable of intercepting traffic between the WCF client and server — e.g., via ARP spoofing, rogue network device, or passive tap on an unencrypted network segment.
3. Capture RSTR: Intercept the WS-Trust Request Security Token Response (RSTR) message exchanged during the SCT negotiation handshake, which contains the proof key wrapped without confidentiality protection.
4. Extract Proof Key: Parse the RSTR message to recover the plaintext proof key from the unencrypted wrapper.
5. Impersonate Principal: Use the recovered proof key to derive the SCT session keys, enabling decryption of all subsequent WS-SecureConversation traffic and/or forging messages as the authenticated Windows principal for up to ~10 hours (GitHub Advisory).

• Network: Unexpected ARP traffic or duplicate MAC/IP mappings suggesting ARP spoofing on segments hosting CoreWCF services; passive capture of WS-Trust RSTR messages on unencrypted network paths.
• Logs: WCF service logs showing authenticated sessions from unexpected source IP addresses or unusual geographic locations using valid Windows credentials; repeated or anomalous SCT issuance events within short timeframes.
• Application Behavior: Decrypted WS-SecureConversation messages appearing to originate from a legitimate Windows principal but with anomalous request patterns or payloads inconsistent with normal client behavior.

The vulnerability is fixed in CoreWCF v1.9.1 (NuGet package CoreWCF.Primitives); upgrading to this version is the recommended remediation (GitHub Advisory, CoreWCF Advisory). As a workaround for deployments that cannot immediately upgrade, ensure all communication between WCF clients and servers is protected by SSL/TLS, which prevents an attacker from capturing the SCT negotiation handshake and observing the proof key. Organizations should also audit their CoreWCF service configurations to confirm whether TransportWithMessageCredential with Windows credentials and session establishment is in use, as only those deployments are affected.