{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.5.1"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "simplesamlphp/simplesamlphp"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.5.0"
            },
            {
              "fixed": "2.5.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.4.6"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "simplesamlphp/simplesamlphp"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.4.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-49284"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-345"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-02T20:47:21Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "## Summary\n\nSimpleSAMLphp\u0027s SAML SP ACS path does not enforce the IdP selected for an SP-initiated login. If a saved SP state contains `ExpectedIssuer = IdP A`, but the ACS receives a valid response from `IdP B`, the code logs a warning and continues processing instead of rejecting the response.\n\nThat behavior becomes security-relevant when combined with the response-processing rule that accepts an unsigned `samlp:Response/@InResponseTo` outside the signed assertion whenever the signed assertion\u0027s `SubjectConfirmationData` does not carry its own `InResponseTo`. A response issued by one trusted IdP can therefore be bound to SP state created for another IdP.\n\n## Impact\n\nIn a multi-IdP deployment, a lower-trust IdP can satisfy SP state created for a different expected IdP. This can bypass an SP flow that intentionally routes the user to a specific IdP, including deployments that set `enable_unsolicited` to `false` to prevent IdP-initiated logins.\n\nThe impact is highest when the SP trusts multiple IdPs with different assurance levels, tenant boundaries, or attribute namespaces, and application authorization depends on the selected/expected IdP. In those deployments this is an authentication/authorization bypass candidate. Impact strongly depends on whether an attacker can obtain a signed IdP-initiated assertion from a lower-trust trusted IdP and whether the downstream application maps identifiers globally.",
  "id": "GHSA-q8r6-xj3f-wrrm",
  "modified": "2026-07-02T20:47:21Z",
  "published": "2026-07-02T20:47:21Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/simplesamlphp/simplesamlphp/security/advisories/GHSA-q8r6-xj3f-wrrm"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/simplesamlphp/simplesamlphp"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "SimpleSAMLphp SP accepts a response from an unexpected IdP when unsigned `Response/InResponseTo` is combined with a signed assertion lacking `SubjectConfirmationData/InResponseTo`"
}