Severity by source
AV:N/AC:H/PR:N/UI:N/S:C/C:N/I:H/A:N
Network-reachable endpoint requires no authentication (PR:N); AC:H reflects the prerequisite of a resource server being configured to rely on Admidio OIDC; S:C captures integrity impact materializing on downstream federated applications, not Admidio itself.
Primary rating from GitHub Advisory.
CVSS VectorGitHub Advisory
Lifecycle Timeline
3DescriptionGitHub Advisory
Summary
The OIDC token introspection endpoint (/modules/sso/index.php/oidc/introspect) always returns {"active": true} for every request, regardless of whether a valid token is provided, whether the token is expired, revoked, or completely fabricated. The endpoint performs no authentication of the calling resource server and no validation of the submitted token. Any resource server that relies on this introspection endpoint to validate access tokens will accept all requests as authorized, enabling complete authentication bypass.
Additionally, the OIDC token revocation endpoint (/oidc/revoke) returns {"revoked": true} without actually revoking any token, preventing resource servers from invalidating compromised credentials.
Details
The vulnerability is in src/SSO/Service/OIDCService.php, lines 604-619:
public function handleIntrospectionRequest() {
// TODO_RK
if (!$this->isServiceSetup) {
$this->setupService();
}
return new JsonResponse(["active" => true]);
}
public function handleRevocationRequest() {
// TODO_RK
if (!$this->isServiceSetup) {
$this->setupService();
}
return new JsonResponse(["revoked" => true]);
}The introspection endpoint is routed at modules/sso/index.php, line 58-59:
} elseif (strpos($requestUri, '/oidc/introspect') !== false) {
$response = $oidcService->handleIntrospectionRequest();The router comment at line 35 says "Login checks will be done in the individual endpoint handler functions!" but neither handleIntrospectionRequest nor handleRevocationRequest perform any authentication or authorization checks.
Per RFC 7662 (OAuth 2.0 Token Introspection), the introspection endpoint:
- MUST authenticate the calling resource server (Section 2.1)
- MUST validate the submitted token against its database
- MUST return
{"active": false}for invalid, expired, or revoked tokens
The current implementation violates all three requirements.
Attack flow:
- Attacker obtains a resource server's endpoint URL that uses Admidio as its OIDC provider
- Attacker crafts any arbitrary string as a Bearer token
- Resource server sends the fabricated token to
/oidc/introspectfor validation - Admidio returns
{"active": true}without any checks - Resource server accepts the fabricated token as valid and grants access
The revocation bypass compounds this: If a legitimate token is stolen, the resource server or client application cannot revoke it. Calling /oidc/revoke returns success without actually revoking the token in the database, so the stolen token remains usable indefinitely (until its expiry time).
PoC
# Step 1: Confirm the introspection endpoint exists and always returns active
# No valid token needed - any string works
curl -X POST https://TARGET/modules/sso/index.php/oidc/introspect \
-d "token=COMPLETELY_FABRICATED_TOKEN_12345"
# Expected response: {"active":true}
# Step 2: Try with an empty token
curl -X POST https://TARGET/modules/sso/index.php/oidc/introspect \
-d "token="
# Expected response: {"active":true}
# Step 3: Demonstrate that revocation is also broken
curl -X POST https://TARGET/modules/sso/index.php/oidc/revoke \
-d "token=any_valid_token_here"
# Expected response: {"revoked":true}
# But the token is NOT actually revoked in the database
# Step 4: Verify the token is still active after "revocation"
curl -X POST https://TARGET/modules/sso/index.php/oidc/introspect \
-d "token=any_valid_token_here"
# Still returns: {"active":true}Impact
- Authentication Bypass on Resource Servers: Any application (wiki, CMS, project management tool, etc.) configured to validate tokens against this Admidio OIDC introspection endpoint will accept completely fabricated tokens. An attacker can impersonate any user on all connected resource servers.
- Inability to Revoke Compromised Tokens: If a legitimate access token is leaked or stolen, there is no way to revoke it through the standard OIDC revocation flow. The token remains valid until its 1-hour expiry.
- Scope Change (S:C): The vulnerability in the Admidio authorization server directly impacts the security of all connected resource servers (different security authority), which is why the CVSS scope is Changed.
Recommended Fix
Replace the stub implementations with proper token introspection and revocation logic:
public function handleIntrospectionRequest() {
if (!$this->isServiceSetup) {
$this->setupService();
}
$request = $this->getRequest();
// 1. Authenticate the resource server (RFC 7662 Section 2.1)
// The resource server MUST authenticate using client credentials
$clientId = $request->getParsedBody()['client_id'] ?? null;
$clientSecret = $request->getParsedBody()['client_secret'] ?? null;
if (!$clientId || !$this->clientRepository->validateClient($clientId, $clientSecret, null)) {
return new JsonResponse(['error' => 'invalid_client'], 401);
}
// 2. Get and validate the token
$tokenValue = $request->getParsedBody()['token'] ?? '';
if (empty($tokenValue)) {
return new JsonResponse(['active' => false]);
}
try {
// Validate the token using the resource server
$validatedRequest = $this->resourceServer->validateAuthenticatedRequest(
$request->withHeader('Authorization', 'Bearer ' . $tokenValue)
);
$tokenId = $validatedRequest->getAttribute('oauth_access_token_id');
// Check if token is revoked
if ($this->accessTokenRepository->isAccessTokenRevoked($tokenId)) {
return new JsonResponse(['active' => false]);
}
$token = $this->accessTokenRepository->getToken($tokenId);
// Check expiry
if ($token->getExpiryDateTime() < new \DateTimeImmutable()) {
return new JsonResponse(['active' => false]);
}
return new JsonResponse([
'active' => true,
'sub' => $token->getUserIdentifier(),
'client_id' => $token->getClient()->getIdentifier(),
'exp' => $token->getExpiryDateTime()->getTimestamp(),
'scope' => implode(' ', array_map(fn($s) => $s->getIdentifier(), $token->getScopes())),
]);
} catch (\Exception $e) {
return new JsonResponse(['active' => false]);
}
}
public function handleRevocationRequest() {
if (!$this->isServiceSetup) {
$this->setupService();
}
$request = $this->getRequest();
// Authenticate the client
$clientId = $request->getParsedBody()['client_id'] ?? null;
$clientSecret = $request->getParsedBody()['client_secret'] ?? null;
if (!$clientId || !$this->clientRepository->validateClient($clientId, $clientSecret, null)) {
return new JsonResponse(['error' => 'invalid_client'], 401);
}
$tokenValue = $request->getParsedBody()['token'] ?? '';
if (!empty($tokenValue)) {
try {
$validatedRequest = $this->resourceServer->validateAuthenticatedRequest(
$request->withHeader('Authorization', 'Bearer ' . $tokenValue)
);
$tokenId = $validatedRequest->getAttribute('oauth_access_token_id');
$this->accessTokenRepository->revokeAccessToken($tokenId);
} catch (\Exception $e) {
// RFC 7009: The server responds with HTTP 200 even for invalid tokens
}
}
return new JsonResponse([], 200);
}AnalysisAI
Admidio's OIDC SSO module (versions ≤ 5.0.8) ships stub placeholder implementations for both token introspection and token revocation that unconditionally return success responses without performing any validation, enabling any attacker to fabricate a bearer token and gain unauthorized access to all resource servers federated through Admidio as their OIDC provider. The introspection handler in src/SSO/Service/OIDCService.php (lines 604-619) is marked // TODO_RK and bypasses all three mandatory RFC 7662 requirements - resource server authentication, token database validation, and returning active:false for invalid tokens. A public proof-of-concept using simple curl commands is included in the GitHub Security Advisory GHSA-9xx5-cv6j-x533; no CISA KEV listing exists and EPSS sits at 0.04%, reflecting the product's niche footprint rather than low attack difficulty.
Technical ContextAI
Admidio is an open-source PHP membership management application (Composer package admidio/admidio) with an optional SSO module implementing OpenID Connect. The flaw resides in src/SSO/Service/OIDCService.php where handleIntrospectionRequest() and handleRevocationRequest() are unfinished stub methods that return hardcoded JSON responses immediately after an internal setup check. The introspection endpoint is routed at /modules/sso/index.php/oidc/introspect and the revocation endpoint at /oidc/revoke; the router comment explicitly defers auth to the individual handlers, but both handlers contain no such logic. CWE-287 (Improper Authentication) is the correct root cause classification - the system does not verify the identity of the caller (resource server) nor the validity of the submitted credential (access token). This violates RFC 7662 Section 2.1 (resource server MUST authenticate), RFC 7662 Section 2.2 (token MUST be validated against the authorization server's database), and RFC 7009 (token revocation MUST persist). The affected package is pkg:composer/admidio_admidio at all versions prior to 5.0.9.
RemediationAI
Upgrade to Admidio v5.0.9 immediately; the vendor release notes at https://github.com/Admidio/admidio/releases/tag/v5.0.9 explicitly state this version fixes security vulnerabilities and strongly recommend updating. For deployments that cannot patch immediately, the most targeted compensating control is to restrict access to the OIDC introspection endpoint (/modules/sso/index.php/oidc/introspect) and revocation endpoint (/oidc/revoke) via web server ACLs or WAF rules to only allow requests from the IP addresses of known, trusted resource servers - this prevents arbitrary attackers from directly calling the endpoints while preserving functionality for legitimate federation partners, though it does not fix the underlying broken validation logic. As a more complete mitigation with higher disruption, disconnecting all resource servers from the Admidio OIDC provider and reverting to an alternative authentication mechanism eliminates the exposure entirely until the patch can be applied. Neither workaround substitutes for the v5.0.9 patch, which replaces the stub implementations with proper RFC 7662-compliant introspection and RFC 7009-compliant revocation logic.
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
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
(1) boardData102.php, (2) boardData103.php, (3) boardDataJP.php, (4) boardDataNA.php, and (5) boardDataWW.php in Netgear
The '/common/download_agent_installer.php' script in the Quest KACE System Management Appliance 8.0.318 is accessible by
ProjectSend versions prior to r1720 are affected by an improper authentication vulnerability. Rated critical severity (C
Roundcube Webmail contains a critical PHP object deserialization vulnerability (CVE-2025-49113, CVSS 9.9) that allows au
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
Palo Alto Networks PAN-OS management web interface contains an authentication bypass allowing unauthenticated attackers
Nagios XI version xi-5.7.5 is affected by OS command injection. Rated high severity (CVSS 8.8), this vulnerability is re
Nagios XI version xi-5.7.5 is affected by OS command injection. Rated high severity (CVSS 8.8), this vulnerability is re
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
The Backup Migration plugin for WordPress is vulnerable to Remote Code Execution in all versions up to, and including, 1
Same weakness CWE-287 – Improper Authentication
View allSame technique Authentication Bypass
View allShare
External POC / Exploit Code
Leaving vuln.today
EUVD-2026-28283
GHSA-9xx5-cv6j-x533