CVE-2026-49284: 
PHP Analyse et atténuation des vulnérabilités

CVE-2026-49284 is an authentication/authorization bypass vulnerability in SimpleSAMLphp affecting its SAML Service Provider (SP) Assertion Consumer Service (ACS) path. The flaw allows a response from an unexpected Identity Provider (IdP) to be accepted when an unsigned samlp:Response/@InResponseTo is combined with a signed assertion that lacks SubjectConfirmationData/InResponseTo. It affects SimpleSAMLphp versions >= 2.5.0 and <= 2.5.1, as well as <= 2.4.6. The vulnerability was originally published on May 29, 2026, and added to the GitHub Advisory Database on July 2, 2026. It carries a CVSS v3.1 base score of 7.1 (High) (GitHub Advisory).

The root cause is classified as CWE-345 (Insufficient Verification of Data Authenticity). SimpleSAMLphp's ACS path fails to enforce that the responding IdP matches the ExpectedIssuer stored in the SP's saved login state — when a mismatch is detected, the code logs a warning but continues processing rather than rejecting the response. This behavior becomes exploitable when combined with a second flaw: the SP accepts an unsigned samlp:Response/@InResponseTo attribute to bind a response to SP state, even when the signed assertion's SubjectConfirmationData does not include its own InResponseTo field. Together, these two weaknesses allow a response issued by one trusted IdP (e.g., a lower-trust IdP B) to be bound to SP state originally created for a different IdP (e.g., higher-trust IdP A), effectively crossing IdP trust boundaries (GitHub Advisory, SimpleSAMLphp Advisory).

The primary impact is authentication and authorization bypass in multi-IdP SimpleSAMLphp deployments. A lower-trust IdP can satisfy SP login state intended for a higher-trust IdP, potentially allowing an attacker to circumvent IdP-specific access controls, tenant boundaries, or assurance-level requirements. This is especially severe when application authorization logic depends on which IdP authenticated the user, as an attacker could gain access to resources or roles intended only for users authenticated by a more trusted IdP. The vulnerability also bypasses the enable_unsolicited = false configuration intended to prevent IdP-initiated logins. Availability is not impacted, but confidentiality (low) and integrity (high) are at risk (GitHub Advisory).

1. Reconnaissance: Identify a target SimpleSAMLphp SP deployment (versions <= 2.4.6 or 2.5.0–2.5.1) that trusts multiple IdPs with different assurance levels or tenant boundaries.
2. Obtain lower-trust IdP access: Authenticate to or control a lower-trust IdP (IdP B) that is listed as a trusted IdP in the target SP's configuration.
3. Initiate SP-initiated login for higher-trust IdP: Trigger an SP-initiated login flow targeting the higher-trust IdP (IdP A), causing the SP to create a saved state with ExpectedIssuer = IdP A and a valid InResponseTo request ID.
4. Craft a malicious SAML response: Using IdP B, generate a valid signed SAML assertion (IdP-initiated style, without SubjectConfirmationData/InResponseTo) and wrap it in a samlp:Response that includes the InResponseTo value from the SP state created in step 3 (unsigned at the Response level).
5. Submit to ACS: POST the crafted SAML response to the SP's ACS endpoint. The SP detects the issuer mismatch but only logs a warning and continues processing; it then accepts the unsigned Response/@InResponseTo to bind the response to the IdP A SP state.
6. Achieve authorization bypass: The SP completes authentication using IdP B's assertion while the session is associated with the IdP A login flow, potentially granting access to resources or roles restricted to IdP A-authenticated users (GitHub Advisory, SimpleSAMLphp Advisory).

• Logs: SimpleSAMLphp warning log entries indicating an issuer mismatch at the ACS (e.g., messages referencing ExpectedIssuer not matching the received Issuer in the SAML response); these warnings appearing without a corresponding authentication failure should be treated as suspicious.
• Logs: Authentication events where the authenticated IdP in session logs differs from the IdP the user was routed to during SP-initiated login.
• Network: Unexpected SAML POST requests to the ACS endpoint originating from an IdP that was not the one selected during the SP-initiated flow, particularly with InResponseTo values matching active SP state for a different IdP.
• Application: Successful logins to high-assurance resources by accounts associated with lower-trust IdPs, especially in deployments with strict IdP-based access controls (GitHub Advisory).

SimpleSAMLphp has released patched versions 2.5.2 and 2.4.7 that address this vulnerability. Administrators should upgrade immediately to one of these versions. As a compensating control prior to patching, deployments should review whether multiple IdPs with differing trust levels are configured and consider temporarily restricting the SP to a single IdP or enforcing strict issuer validation at the application layer. No specific configuration-only workaround is documented in the advisory (GitHub Advisory, SimpleSAMLphp Advisory).

The vulnerability was reported by security researcher kamil-sawicki and published by SimpleSAMLphp maintainer tvdijen on May 29, 2026. No significant broader media coverage or notable social media commentary has been identified beyond the official GitHub advisory (SimpleSAMLphp Advisory).