CVE-2026-41670

Admidio is an open-source user management solution. Prior to version 5.0.9, the SAML IdP implementation in Admidio's SSO module uses the AssertionConsumerServiceURL value directly from incoming SAML AuthnRequest messages as the destination for the SAML response, without validating it against the registered ACS URL (smc_acs_url) stored in the database for the corresponding service provider client. An attacker who knows the Entity ID of a registered SP client can craft a SAML AuthnRequest with an arbitrary AssertionConsumerServiceURL, causing the IdP to send the signed SAML response -- containing user identity attributes (login name, email, roles, profile fields) -- to an attacker-controlled URL. This issue has been patched in version 5.0.9.

Admidio is an open-source user management solution. Prior to version 5.0.9, the SAML IdP implementation in Admidio's SSO module uses the AssertionConsumerServiceURL value directly from incoming SAML AuthnRequest messages as the destination for the SAML response, without validating it against the registered ACS URL (smc_acs_url) stored in the database for the corresponding service provider client. An attacker who knows the Entity ID of a registered SP client can craft a SAML AuthnRequest with an arbitrary AssertionConsumerServiceURL, causing the IdP to send the signed SAML response -- containing user identity attributes (login name, email, roles, profile fields) -- to an attacker-controlled URL. This issue has been patched in version 5.0.9.

Summary

The SAML IdP implementation in Admidio's SSO module uses the AssertionConsumerServiceURL value directly from incoming SAML AuthnRequest messages as the destination for the SAML response, without validating it against the registered ACS URL (smc_acs_url) stored in the database for the corresponding service provider client. An attacker who knows the Entity ID of a registered SP client can craft a SAML AuthnRequest with an arbitrary AssertionConsumerServiceURL, causing the IdP to send the signed SAML response -- containing user identity attributes (login name, email, roles, profile fields) -- to an attacker-controlled URL.

Details

The vulnerability is in src/SSO/Service/SAMLService.php, in handleSSORequest() at lines 439-465:

// Line 439: ACS URL extracted directly from the AuthnRequest (attacker-controlled)
$clientACS = $request->getAssertionConsumerServiceURL();

// ...

// Line 456: Used as the Destination of the SAML Response
$response->setDestination($clientACS);

// Lines 463-465: Also used as the Recipient in SubjectConfirmationData
$subjectConfirmationData = new \LightSaml\Model\Assertion\SubjectConfirmationData();
$subjectConfirmationData
    ->setRecipient($clientACS) // Required recipient URL

There is no code that compares $clientACS against the client's registered smc_acs_url column value. The SAML 2.0 specification and OASIS security considerations explicitly require IdPs to verify that the AssertionConsumerServiceURL matches one of the SP's registered ACS endpoints.

Signature validation is conditional and does not prevent this attack:

At lines 417-419:

if ($client->getValue('smc_require_auth_signed') || $client->getValue('smc_validate_signatures')) {
    $this->validateSignature($client, $request, $client->getValue('smc_require_auth_signed'));
}

If neither smc_require_auth_signed nor smc_validate_signatures is enabled for the SP client (which is the default when creating a new client), the AuthnRequest is processed without any signature verification. This means an attacker only needs to know the SP's Entity ID (which is often publicly discoverable from the SP's metadata endpoint) to craft a malicious AuthnRequest.

Even when signatures ARE validated, the ACS URL should still be checked against the registered value, because:

• Signature validation proves the request came from the SP, not that the ACS URL is authorized
• If the SP's signing key is compromised, the ACS URL becomes the last line of defense
• This follows the defense-in-depth principle mandated by SAML 2.0 Profiles Section 4.1.4.1

The same pattern exists in the error response path at lines 323-326:

} elseif (method_exists($request, 'getAssertionConsumerServiceURL')) {
    $response->setDestination($request->getAssertionConsumerServiceURL());
} else {
    $response->setDestination($client->getValue('smc_acs_url'));
}

Attack flow:

1. Attacker discovers the Entity ID of a SAML client registered in Admidio (e.g., from the SP's public metadata)
2. Attacker crafts a SAML AuthnRequest with the legitimate Entity ID but an attacker-controlled AssertionConsumerServiceURL
3. Attacker sends this AuthnRequest to Admidio's SSO endpoint (via redirect or auto-submitting form)
4. If the user is already logged in to Admidio, the IdP generates a signed SAML response with the user's identity and attributes
5. The SAML response is POST-binding-sent to the attacker's URL via an auto-submitting HTML form rendered in the victim's browser
6. The attacker receives the signed SAML assertion containing login name, email, full name, roles, and other profile fields
7. The attacker can replay this SAML assertion to the legitimate SP (since it is validly signed by the IdP)

PoC

# Step 1: Generate a malicious SAML AuthnRequest
# This is a base64-encoded SAML AuthnRequest with:
#   - Issuer = the known Entity ID of a registered SP
#   - AssertionConsumerServiceURL = attacker's server

#…

Admidio is an open-source user management solution. Prior to version 5.0.9, the SAML IdP implementation in Admidio's SSO module uses the AssertionConsumerServiceURL value directly from incoming SAML AuthnRequest messages as the destination for the SAML response, without validating it against the registered ACS URL (smc_acs_url) stored in the database for the corresponding service provider client. An attacker who knows the Entity ID of a registered SP client can craft a SAML AuthnRequest with an arbitrary AssertionConsumerServiceURL, causing the IdP to send the signed SAML response -- containing user identity attributes (login name, email, roles, profile fields) -- to an attacker-controlled URL. This issue has been patched in version 5.0.9.

Admidio is an open-source user management solution. Prior to version 5.0.9, the SAML IdP implementation in Admidio's SSO module uses the AssertionConsumerServiceURL value directly from incoming SAML AuthnRequest messages as the destination for the SAML response, without validating it against the registered ACS URL (smc_acs_url) stored in the database for the corresponding service provider client. An attacker who knows the Entity ID of a registered SP client can craft a SAML AuthnRequest with an arbitrary AssertionConsumerServiceURL, causing the IdP to send the signed SAML response -- containing user identity attributes (login name, email, roles, profile fields) -- to an attacker-controlled URL. This issue has been patched in version 5.0.9.

Summary

The SAML IdP implementation in Admidio's SSO module uses the AssertionConsumerServiceURL value directly from incoming SAML AuthnRequest messages as the destination for the SAML response, without validating it against the registered ACS URL (smc_acs_url) stored in the database for the corresponding service provider client. An attacker who knows the Entity ID of a registered SP client can craft a SAML AuthnRequest with an arbitrary AssertionConsumerServiceURL, causing the IdP to send the signed SAML response -- containing user identity attributes (login name, email, roles, profile fields) -- to an attacker-controlled URL.

Details

The vulnerability is in src/SSO/Service/SAMLService.php, in handleSSORequest() at lines 439-465:

// Line 439: ACS URL extracted directly from the AuthnRequest (attacker-controlled)
$clientACS = $request->getAssertionConsumerServiceURL();

// ...

// Line 456: Used as the Destination of the SAML Response
$response->setDestination($clientACS);

// Lines 463-465: Also used as the Recipient in SubjectConfirmationData
$subjectConfirmationData = new \LightSaml\Model\Assertion\SubjectConfirmationData();
$subjectConfirmationData
    ->setRecipient($clientACS) // Required recipient URL

There is no code that compares $clientACS against the client's registered smc_acs_url column value. The SAML 2.0 specification and OASIS security considerations explicitly require IdPs to verify that the AssertionConsumerServiceURL matches one of the SP's registered ACS endpoints.

Signature validation is conditional and does not prevent this attack:

At lines 417-419:

if ($client->getValue('smc_require_auth_signed') || $client->getValue('smc_validate_signatures')) {
    $this->validateSignature($client, $request, $client->getValue('smc_require_auth_signed'));
}

If neither smc_require_auth_signed nor smc_validate_signatures is enabled for the SP client (which is the default when creating a new client), the AuthnRequest is processed without any signature verification. This means an attacker only needs to know the SP's Entity ID (which is often publicly discoverable from the SP's metadata endpoint) to craft a malicious AuthnRequest.

Even when signatures ARE validated, the ACS URL should still be checked against the registered value, because:

• Signature validation proves the request came from the SP, not that the ACS URL is authorized
• If the SP's signing key is compromised, the ACS URL becomes the last line of defense
• This follows the defense-in-depth principle mandated by SAML 2.0 Profiles Section 4.1.4.1

The same pattern exists in the error response path at lines 323-326:

} elseif (method_exists($request, 'getAssertionConsumerServiceURL')) {
    $response->setDestination($request->getAssertionConsumerServiceURL());
} else {
    $response->setDestination($client->getValue('smc_acs_url'));
}

Attack flow:

1. Attacker discovers the Entity ID of a SAML client registered in Admidio (e.g., from the SP's public metadata)
2. Attacker crafts a SAML AuthnRequest with the legitimate Entity ID but an attacker-controlled AssertionConsumerServiceURL
3. Attacker sends this AuthnRequest to Admidio's SSO endpoint (via redirect or auto-submitting form)
4. If the user is already logged in to Admidio, the IdP generates a signed SAML response with the user's identity and attributes
5. The SAML response is POST-binding-sent to the attacker's URL via an auto-submitting HTML form rendered in the victim's browser
6. The attacker receives the signed SAML assertion containing login name, email, full name, roles, and other profile fields
7. The attacker can replay this SAML assertion to the legitimate SP (since it is validly signed by the IdP)

PoC

# Step 1: Generate a malicious SAML AuthnRequest
# This is a base64-encoded SAML AuthnRequest with:
#   - Issuer = the known Entity ID of a registered SP
#   - AssertionConsumerServiceURL = attacker's server

#…