SimpleSAMLphp SP accepts a response from an unexpected IdP when unsigned `Response/InResponseTo` is combined with a signed assertion lacking `SubjectConfirmationData/InResponseTo` (CVE-2026-49284)
## 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.
AI Analysis
Technical Summary
The vulnerability in SimpleSAMLphp's SAML SP Assertion Consumer Service (ACS) path arises because it does not enforce that the IdP responding matches the expected IdP stored in the SP state for SP-initiated logins. When an unsigned Response element's InResponseTo attribute is combined with a signed assertion missing SubjectConfirmationData/InResponseTo, the SP accepts the response from an unexpected IdP. This allows a lower-trust IdP to satisfy SP state created for a different expected IdP, potentially bypassing restrictions such as disabling unsolicited logins. The issue is particularly impactful in environments trusting multiple IdPs with different assurance levels or attribute namespaces, where application authorization depends on the selected IdP. Exploitation depends on the attacker's ability to obtain a signed assertion from a lower-trust IdP and on how the application maps user identifiers.
Potential Impact
This vulnerability can lead to authentication and authorization bypass in multi-IdP deployments by allowing a response from a lower-trust or unintended IdP to be accepted as valid for a session expecting a different IdP. This undermines the SP's intended routing and trust boundaries, potentially granting unauthorized access or elevated privileges if the application relies on the IdP identity for authorization decisions. The impact is limited to deployments where multiple IdPs with differing trust levels are configured and where the attacker can obtain a signed assertion from a lower-trust IdP.
Mitigation Recommendations
Patch status is not yet confirmed — check the vendor advisory for current remediation guidance. In the meantime, administrators should review their multi-IdP configurations and consider isolating trust boundaries or disabling SP-initiated flows if possible. Monitoring for unexpected IdP responses and applying strict validation of InResponseTo attributes within signed assertions may help mitigate risk until an official fix is available.
SimpleSAMLphp SP accepts a response from an unexpected IdP when unsigned `Response/InResponseTo` is combined with a signed assertion lacking `SubjectConfirmationData/InResponseTo` (CVE-2026-49284)
Description
## 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.
CVSS v3.1
Score 7.1high
Affected software
Run on your own infrastructure? Check whether these packages are installed with threat-finder — our free open-source scanner.
Weaknesses
AI-Powered Analysis
Machine-generated threat intelligence
Technical Analysis
The vulnerability in SimpleSAMLphp's SAML SP Assertion Consumer Service (ACS) path arises because it does not enforce that the IdP responding matches the expected IdP stored in the SP state for SP-initiated logins. When an unsigned Response element's InResponseTo attribute is combined with a signed assertion missing SubjectConfirmationData/InResponseTo, the SP accepts the response from an unexpected IdP. This allows a lower-trust IdP to satisfy SP state created for a different expected IdP, potentially bypassing restrictions such as disabling unsolicited logins. The issue is particularly impactful in environments trusting multiple IdPs with different assurance levels or attribute namespaces, where application authorization depends on the selected IdP. Exploitation depends on the attacker's ability to obtain a signed assertion from a lower-trust IdP and on how the application maps user identifiers.
Potential Impact
This vulnerability can lead to authentication and authorization bypass in multi-IdP deployments by allowing a response from a lower-trust or unintended IdP to be accepted as valid for a session expecting a different IdP. This undermines the SP's intended routing and trust boundaries, potentially granting unauthorized access or elevated privileges if the application relies on the IdP identity for authorization decisions. The impact is limited to deployments where multiple IdPs with differing trust levels are configured and where the attacker can obtain a signed assertion from a lower-trust IdP.
Mitigation Recommendations
Patch status is not yet confirmed — check the vendor advisory for current remediation guidance. In the meantime, administrators should review their multi-IdP configurations and consider isolating trust boundaries or disabling SP-initiated flows if possible. Monitoring for unexpected IdP responses and applying strict validation of InResponseTo attributes within signed assertions may help mitigate risk until an official fix is available.
Technical Details
- Gcve Source
- db.gcve.eu
- Osv Id
- GHSA-q8r6-xj3f-wrrm
- Osv Schema Version
- 1.4.0
- Aliases
- ["CVE-2026-49284"]
- Ecosystems
- ["Packagist"]
- Database Specific Severity
- HIGH
- Cvss Version
- 3.1
Threat ID: 6a46ecae27e9c7971943b8dd
Added to database: 07/02/2026, 22:56:46 UTC
Last enriched: 07/02/2026, 23:05:50 UTC
Last updated: 07/31/2026, 19:22:59 UTC
Views: 61
Community Reviews
0 reviewsCrowdsource mitigation strategies, share intel context, and vote on the most helpful responses. Sign in to add your voice and help keep defenders ahead.
Want to contribute mitigation steps or threat intel context? Sign in or create an account to join the community discussion.
Actions
Updates to AI analysis require Pro Console access. Upgrade inside Console → Billing.
Need more coverage?
Upgrade to Pro Console for AI refresh and higher limits.
For incident response and remediation, OffSeq services can help resolve threats faster.
Latest Threats
Check if your credentials are on the dark web
Instant breach scanning across billions of leaked records. Free tier available.