CoreWCF CVE-2026-54773

Two specific server-side prerequisites - both outside the attacker's direct control - must be satisfied. First, the target CoreWCF endpoint must be configured with an endorsing supporting token binding (a WS-SecurityPolicy binding assertion enabling a second ds:Signature to endorse the primary security token); this is not a default or basic endpoint configuration. Second, the attacker must construct a ds:Signature whose KeyInfo element resolves through the server's receive-side token resolver to a cryptographic key under the attacker's control, which requires the resolver to be configured more permissively than the default issuer-pinned X.509 chain model. Services using the default static certificate pinning resolver are not exploitable. Per the CVSS vector (AV:N/PR:N), no authentication is required and the attack is remotely executable, but the AC:H rating correctly reflects that these two deployment-specific conditions are hard prerequisites, not attacker-adjustable parameters.

The CVSS 3.1 score of 5.9 (AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N) reflects accurate signal: network-reachable, no authentication required, but high attack complexity because two conditions outside the attacker's direct control must be true simultaneously. First, the endpoint must be configured with an endorsing supporting token binding - a non-default WS-SecurityPolicy assertion. Second, the attacker must supply a KeyInfo reference that the server's token resolver will actually resolve to an attacker-controlled key, which requires either a permissive resolver configuration or a key the attacker has somehow introduced into the trust store. Services using the default static issuer-pinned X.509 certificate model are not exploitable via this path. No EPSS score was provided in the source data, so exploitation probability cannot be quantified. The vulnerability is not listed in the CISA KEV catalog and no public proof-of-concept exists. Despite the integrity-only impact label, a successful attack completely undermines SOAP message authentication, which in high-assurance deployments (financial services, healthcare integrations, B2B APIs) is a critical control. Risk is high for affected configurations, moderate across the broader CoreWCF deployment population.

An attacker targeting a CoreWCF service that uses an endorsing supporting token binding obtains or generates a key pair that the server's token resolver will accept - for example, by exploiting a permissive trust store or by possessing a certificate issued by an accepted CA. The attacker crafts a SOAP envelope in which a synthetic header, placed before wsse:Security in document order, embeds a ds:Signature element signed with their private key. When the server processes the message, its document-wide signature lookup resolves to the attacker's injected signature rather than the legitimate one, validates it as authentic, and accepts a message that should have failed integrity verification. No public proof-of-concept has been identified at the time of analysis.