Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
8 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
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.
Recommended action: Upgrade to 1.9.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact The attacker, with one captured signed SOAP envelope from a victim and no other privileges, can invoke arbitrary operations on the service as the victim principal for the lifetime of the captured signing key. There is no rate limit on replays. The DetectReplays setting on transport-security bindings does not mitigate the issue because the attack does not reuse the original timestamp — the fresh timestamp in the wsse:Security header is what the replay-detection logic inspects. Patches Fixed in CoreWCF v1.8.1 and v1.9.1 Workarounds Ensure communication is protected by SSL/TLS to prevent capturing of signed SOAP envelope.
Recommended action: Upgrade to 1.9.1 or 1.8.1 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Full impersonation of any principal the trusted STS could have issued an assertion for — including administrative principals when the relying party grants them via SAML claims. Affects both SAML 1.1 and SAML 2.0. Preconditions Relying-party service is hosted with WSFederationHttpBinding or WS2007FederationHttpBinding (or any binding that triggers FederatedSecurityTokenManager for issued-token validation), and IdentityConfiguration is wired (UseIdentityConfiguration = true). Attacker can reach the service over the network and knows the trusted STS’s public certificate (public certs are by design discoverable). Patches Fixed in CoreWCF v1.8.1 and v1.9.1 Workarounds None
Recommended action: Upgrade to 1.9.1 or 1.8.1 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact The relying application is given a ClaimsPrincipal for a subject whose authority over the assertion the sender never proved. There are two distinct exploit shapes: - Holder-of-key downgrade. An attacker who obtains a holder-of-key SAML assertion that was issued without KeyInfo (issuer bug, custom STS shape, or assertion captured from an interaction where KeyInfo was elided) can present it to the service and be authenticated as the assertion’s subject without producing the proof key the assertion’s confirmation method would normally require. The service’s reliance on holder-of-key for sensitive actions is bypassed. - Custom-method bypass. An attacker who can obtain or arrange the issuance of a SAML assertion bearing a non-standard confirmation method URI (a permissive STS that accepts arbitrary method strings, an experimental custom IDP, or an attacker-side construction that the issuer signs without validating the method field) can present the assertion and be authenticated.…
Recommended action: Upgrade to 1.9.1 or 1.8.1 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact CoreWCF’s WS-Security 1.0 receive pipeline validates the SignatureMethod of an incoming ds:SignedInfo against the configured SecurityAlgorithmSuite, but does not validate the DigestMethod declared on each ds:Reference. As a result, a sender can populate ds:SignedInfo with SignatureMethod values the suite accepts (for example rsa-sha256 under Basic256Sha256) while declaring a per-reference DigestMethod the suite rejects (for example http://www.w3.org/2000/09/xmldsig#sha1). The signature is then verified where it permits SHA-1 digests, and the message is accepted. Patches Fixed in CoreWCF v1.8.1 and v1.9.1 Workarounds None
Recommended action: Upgrade to 1.9.1 or 1.8.1 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact When enabling DetectReplayedTokens, a token can be replayed and will be detected despite it being reused. Patches Fixed in CoreWCF v1.8.1 and v1.9.1 Workarounds Provide your own implementation of ITokenReplayCache with the correct behavior.
Recommended action: Upgrade to 1.9.1 or 1.8.1 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact When a service is configured to validate SAML tokens using a method other than X.509 certificate signing, the final signature verification is skipped. Preconditions The service is configured to authenticate using SAML tokens and an out of band token resolver (commonly the IssuerTokenResolver of IssuedTokenServiceCredential) holds a non-X.509 SecurityToken whose key identifier the attacker can reference in the assertion’s <KeyInfo - for example a BinarySecretSecurityToken representing the symmetric proof key issued by a WS-Trust symmetric-key holder-of-key STS. Patches Fixed in CoreWCF v1.8.1 and v1.9.1 Workarounds None
Recommended action: Upgrade to 1.9.1 or 1.8.1 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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).
Recommended action: Upgrade to 1.9.1 or 1.8.1 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.