GHSA-48PQ-2XQ3-C2M4

Vulnerability from github – Published: 2026-06-19 20:47 – Updated: 2026-06-19 20:47
VLAI
Summary
CoreWCF: SAML SubjectConfirmation methods and holder-of-key proof keys are not enforced
Details

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. Per-method policies that an application or a binding-level policy expects the framework to enforce are silently bypassed.

Preconditions

The service is configured to accept SAML 1.1 tokens via federation. Typical bindings are WS2007FederationHttpBinding and WSFederationHttpBinding, or any custom binding using IssuedSecurityTokenParameters with a SAML 1.1 token type.
The attacker has obtained at least one signed SAML 1.1 assertion of a shape that triggers the bypass.

Patches

Fixed in CoreWCF v1.8.1 and v1.9.1

Workarounds

To exploit this issue, it's required that a trusted STS issues SAML assertions whose SubjectConfirmationMethod is not one of the SAML 1.1 trio, or is willing to issue holder-of-key assertions without KeyInfo. If no trusted STS is willing to issue SAML assertions meeting either of these criteria, then a service isn't vulnerable.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "NuGet",
        "name": "CoreWCF.Primitives"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.8.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "NuGet",
        "name": "CoreWCF.Primitives"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.9.0"
            },
            {
              "fixed": "1.9.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-54781"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287",
      "CWE-345"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-19T20:47:08Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Impact\nThe relying application is given a ClaimsPrincipal for a subject whose authority over the assertion the sender never proved. There are two distinct exploit shapes:\n- 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\u2019s subject without producing the proof key the assertion\u2019s confirmation method would normally require. The service\u2019s reliance on holder-of-key for sensitive actions is bypassed.\n- 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. Per-method policies that an application or a binding-level policy expects the framework to enforce are silently bypassed.\n\n#### Preconditions\nThe service is configured to accept SAML 1.1 tokens via federation. Typical bindings are WS2007FederationHttpBinding and WSFederationHttpBinding, or any custom binding using IssuedSecurityTokenParameters with a SAML 1.1 token type.  \nThe attacker has obtained at least one signed SAML 1.1 assertion of a shape that triggers the bypass.\n\n### Patches\nFixed in CoreWCF v1.8.1 and v1.9.1\n\n### Workarounds\nTo exploit this issue, it\u0027s required that a trusted STS issues SAML assertions whose SubjectConfirmationMethod is not one of the SAML 1.1 trio, or is willing to issue holder-of-key assertions without KeyInfo. If no trusted STS is willing to issue SAML assertions meeting either of these criteria, then a service isn\u0027t vulnerable.",
  "id": "GHSA-48pq-2xq3-c2m4",
  "modified": "2026-06-19T20:47:08Z",
  "published": "2026-06-19T20:47:08Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/CoreWCF/CoreWCF/security/advisories/GHSA-48pq-2xq3-c2m4"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/CoreWCF/CoreWCF"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "CoreWCF: SAML SubjectConfirmation methods and holder-of-key proof keys are not enforced"
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…