CoreWCF CVE-2026-54773
MEDIUM
GHSA-jc6x-rj79-w4mx
Severity by source
AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N
AC:H reflects mandatory dual non-default prerequisites (endorsing token binding plus attacker-resolvable key); integrity-only impact because signature substitution bypasses authentication without exposing data.
Primary rating from Vendor (https://github.com/CoreWCF/CoreWCF).
CVSS VectorVendor: https://github.com/CoreWCF/CoreWCF
Lifecycle Timeline
2DescriptionCVE.org
Impact
An unauthenticated remote attacker who can place a SOAP header lexically before wsse:Security can embed a ds:Signature of their choosing inside that header and cause the server to verify the attacker-supplied signature instead of the one carried in the security header.
Preconditions
Exploitation requires the endpoint be configured with an endorsing supporting token binding, and the attacker constructs a ds:Signature whose KeyInfo resolves through the receive-side token resolver to a key under the attacker’s control. Both are conditions outside the attacker’s direct control on a generic deployment.
Patches
Fixed in CoreWCF v1.8.1 and v1.9.1
Workarounds
Use a security token resolver that only accepts references to issuer-pinned X.509 chains (the default when expecting a static set of signing certificates).
AnalysisAI
Signature substitution in CoreWCF's WS-Security message processing allows a remote unauthenticated attacker to replace the server's cryptographic integrity check with a signature of the attacker's choosing, effectively forging authenticated SOAP messages. Affected versions of CoreWCF.Primitives perform a document-wide lookup for ds:Signature elements rather than scoping verification to the wsse:Security header, so an attacker-injected signature in a preceding SOAP header is found and verified first. Exploitation is constrained by two non-default server-side prerequisites, limiting widespread risk on generic deployments, but the integrity bypass is complete where those conditions are met. No public exploit code has been identified and this CVE does not appear in the CISA KEV catalog at time of analysis.
Technical ContextAI
CoreWCF is the .NET open-source successor to Windows Communication Foundation, implementing SOAP-based interoperable web services. The affected package is CoreWCF.Primitives (pkg:nuget/corewcf.primitives), which provides the core WS-Security pipeline. WS-Security (OASIS WSS) defines how digital signatures are carried inside a wsse:Security SOAP header to authenticate message content; an endorsing supporting token binding (a WS-SecurityPolicy assertion) requires an additional ds:Signature to endorse the primary token, creating a two-signature model. The root cause (CWE-347: Improper Verification of Cryptographic Signature) is that the receive-side pipeline resolves the ds:Signature element via a document-wide XPath or DOM lookup rather than restricting the search to the wsse:Security header scope. An attacker who controls the order of SOAP headers in the envelope can therefore insert a synthetic header earlier in document order containing a ds:Signature whose KeyInfo resolves to an attacker-held key, causing the verifier to authenticate the wrong signature entirely.
RemediationAI
Upgrade CoreWCF.Primitives to v1.8.1 (for consumers on the 1.x stable branch) or v1.9.1 (for consumers on the 1.9.x branch), as confirmed by the GitHub Security Advisory at https://github.com/CoreWCF/CoreWCF/security/advisories/GHSA-jc6x-rj79-w4mx. If immediate patching is not feasible, apply the documented workaround: configure the receive-side security token resolver to accept only references to issuer-pinned X.509 certificate chains, which is already the default behavior for services that use a static, pre-registered set of signing certificates. This workaround blocks the attack by ensuring no attacker-supplied KeyInfo can resolve to a trusted key, breaking the substitution chain. Trade-off: this workaround prevents dynamic key negotiation scenarios (e.g., federated identity with unregistered issuers) and must be validated against your service's authentication design before applying in production.
More in Jwt Attack
View allWhy is Microsoft republishing a CVE from 2013? We are republishing CVE-2013-3900 in the Security Update Guide to update
Authentication bypass in SimpleHelp 5.5.15 and prior (plus 6.0 pre-release builds) allows remote unauthenticated attacke
Authentication bypass in Fortinet FortiOS, FortiProxy, and FortiSwitchManager allows unauthenticated remote attackers to
ruby-saml provides security assertion markup language (SAML) single sign-on (SSO) for Ruby. Rated critical severity (CVS
ruby-saml provides security assertion markup language (SAML) single sign-on (SSO) for Ruby. Rated critical severity (CVS
The package jsrsasign before 10.5.25 are vulnerable to Improper Verification of Cryptographic Signature when JWS or JWT
A library injection vulnerability exists in Microsoft Teams (work or school) 24046.2813.2770.1094 for macOS. Rated criti
A library injection vulnerability exists in the WebView.app helper app of Microsoft Teams (work or school) 24046.2813.27
A library injection vulnerability exists in the com.microsoft.teams2.modulehost.app helper app of Microsoft Teams (work
The Ruby SAML library is for implementing the client side of a SAML authorization. Rated critical severity (CVSS 9.8), t
cosign is a container signing and verification utility. Rated critical severity (CVSS 9.8), this vulnerability is remote
Biscuit is an authentication and authorization token for microservices architectures. Rated critical severity (CVSS 9.8)
Same technique Information Disclosure
View allShare
External POC / Exploit Code
Leaving vuln.today