Skip to main content

PHP CVE-2026-41671

| EUVDEUVD-2026-28283 MEDIUM
Improper Authentication (CWE-287)
2026-04-29 https://github.com/Admidio/admidio GHSA-9xx5-cv6j-x533
Authentication Bypass PHP
6.8
CVSS 3.1 · GitHub Advisory
Share

Severity by source

GitHub Advisory PRIMARY
6.8 MEDIUM
AV:N/AC:H/PR:N/UI:N/S:C/C:N/I:H/A:N

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

CVSS VectorGitHub Advisory

CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:N/I:H/A:N
Attack Vector
Network
Attack Complexity
High
Privileges Required
None
User Interaction
None
Scope
Changed
Confidentiality
None
Integrity
High
Availability
None

Lifecycle Timeline

1
CVE Published
Apr 29, 2026 - 21:58 nvd
MEDIUM 6.8

DescriptionGitHub 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:

php
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:

php
} 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

bash
# 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:

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

Analysis

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:

php
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:

php
} 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

bash
# 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:

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

More in PHP

View all
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-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
CVE-2024-46506 CRITICAL POC
10.0 May 13

NetAlertX (formerly PiAlert) versions 23.01.14 through 24.x before 24.10.12 allow unauthenticated command injection thro
CVE-2024-8353 CRITICAL POC
9.8 Sep 28

The GiveWP - Donation Plugin and Fundraising Platform plugin for WordPress is vulnerable to PHP Object Injection in all

Same weakness CWE-287 – Improper Authentication

View all
CVE-2020-0688 HIGH POC
8.8
CVE-2023-46805 HIGH POC
8.2
CVE-2015-1187 CRITICAL POC
9.8
CVE-2024-7593 CRITICAL POC
9.8
CVE-2017-7921 CRITICAL POC
9.8
CVE-2024-53704 CRITICAL POC
9.8
CVE-2015-7755 CRITICAL POC
9.8
CVE-2013-0625 CRITICAL POC
9.8

Same technique Authentication Bypass

View all
CVE-2023-22515 CRITICAL POC
9.8
CVE-2012-4681 CRITICAL POC
9.8
CVE-2013-2465 CRITICAL POC
9.8
CVE-2011-3544 CRITICAL POC
9.8
CVE-2012-1723 CRITICAL POC
9.8
CVE-2017-10271 HIGH POC
7.5
CVE-2015-1427 CRITICAL POC
9.8
CVE-2025-3248 CRITICAL POC
9.8

Share

CVE-2026-41671 vulnerability details – vuln.today
Back

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