---
id: CVE-2026-49284
title: >-
  SimpleSAMLphp SP accepts a response from an unexpected IdP when unsigned
  `Response/InResponseTo` is combined with a signed assertion lacking
  `SubjectConfirmationData/InResponseTo`
summary: >-
  SimpleSAMLphp SP accepts a response from an unexpected IdP when unsigned
  `Response/InResponseTo` is combined with a signed assertion lacking
  `SubjectConfirmationData/InResponseTo`
severity: high
cvss: 7.1
cwe:
  - CWE-345
vendor: simplesamlphp
product: simplesamlphp/simplesamlphp
ecosystem: composer
affected:
  - 'simplesamlphp/simplesamlphp >= 2.5.0, <= 2.5.1'
  - simplesamlphp/simplesamlphp <= 2.4.6
patched:
  - simplesamlphp/simplesamlphp 2.5.2
  - simplesamlphp/simplesamlphp 2.4.7
published: '2026-07-02'
updated: '2026-07-02'
source: GHSA
sourceUrl: 'https://github.com/advisories/GHSA-q8r6-xj3f-wrrm'
references:
  - url: >-
      https://github.com/simplesamlphp/simplesamlphp/security/advisories/GHSA-q8r6-xj3f-wrrm
  - url: 'https://github.com/advisories/GHSA-q8r6-xj3f-wrrm'
tags:
  - ghsa
  - composer
ingestedAt: '2026-07-02T21:44:45.094Z'
epss: 0.00222
epssPercentile: 0.11386
---

## Overview

## Summary

SimpleSAMLphp's 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.

That 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's `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.

## Impact

In 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.

The 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.

## Affected packages

- `simplesamlphp/simplesamlphp >= 2.5.0, <= 2.5.1`
- `simplesamlphp/simplesamlphp <= 2.4.6`

## Remediation

Upgrade to a patched release:

- `simplesamlphp/simplesamlphp 2.5.2`
- `simplesamlphp/simplesamlphp 2.4.7`