CVE-2026-41671: Admidio OIDC Auth Bypass Vulnerability

CVE-2026-41671 Overview

CVE-2026-41671 is an authentication bypass vulnerability in Admidio, an open-source user management solution. Versions prior to 5.0.9 ship a broken OpenID Connect (OIDC) token introspection endpoint at /modules/sso/index.php/oidc/introspect. The endpoint always responds with {"active": true} regardless of the token submitted. It performs no authentication of the calling resource server and no validation of the token. The companion revocation endpoint /oidc/revoke similarly returns {"revoked": true} without invalidating any token. Resource servers that depend on Admidio for token validation will accept attacker-supplied, expired, or fabricated tokens as authorized [CWE-287].

Critical Impact

Any resource server relying on Admidio's OIDC introspection accepts forged or expired tokens as valid, enabling complete authentication bypass and preventing revocation of compromised credentials.

Affected Products

• Admidio versions prior to 5.0.9
• Admidio OIDC token introspection endpoint (/modules/sso/index.php/oidc/introspect)
• Admidio OIDC token revocation endpoint (/oidc/revoke)

Discovery Timeline

• 2026-05-07 - CVE-2026-41671 published to NVD
• 2026-05-07 - Last updated in NVD database

Technical Details for CVE-2026-41671

Vulnerability Analysis

Admidio implements an OIDC provider that exposes RFC 7662 token introspection and RFC 7009 token revocation endpoints. Resource servers call introspection to verify whether a bearer token is still active before granting access to protected resources. In affected versions, the introspection handler skips both client authentication and token verification. It unconditionally returns a JSON document with active set to true. The revocation endpoint exhibits the same defect, returning a success response without touching token state.

The practical consequence is that any downstream service trusting Admidio's introspection output treats every request as authenticated. An attacker can submit a random string, an expired token, or a token revoked by an administrator and still receive access. Because revocation also silently fails, defenders cannot disable stolen tokens through the standard OIDC flow.

Root Cause

The root cause is missing authentication logic in the OIDC endpoint handlers. The introspection route does not verify the caller's client_id and client_secret, does not look up the submitted token in storage, and does not check expiration, signature, or revocation flags. The revocation route lacks the corresponding lookup and update operations. Both endpoints return hardcoded success payloads, mapping to [CWE-287: Improper Authentication].

Attack Vector

The vulnerability is reachable over the network without prior authentication. An attacker presents any value as a bearer token to a resource server that delegates validation to a vulnerable Admidio instance. The resource server queries /modules/sso/index.php/oidc/introspect, receives {"active": true}, and authorizes the request. Exploitation requires that a third-party resource server is configured to use Admidio for OIDC token validation, which is the documented integration pattern.

No verified exploit code is published. The behavior is described in the GitHub Security Advisory GHSA-9xx5-cv6j-x533.

Detection Methods for CVE-2026-41671

Indicators of Compromise

• HTTP requests to /modules/sso/index.php/oidc/introspect originating from unexpected source addresses or without valid client credentials in the Authorization header.
• Successful authentication events on resource servers that correlate with introspection responses returning active: true for tokens not present in the Admidio token store.
• Calls to /oidc/revoke followed by continued use of the supposedly revoked token against protected resources.

Detection Strategies

• Inspect Admidio web server access logs for introspection and revocation requests, and compare submitted token values against the application's issued token database.
• Deploy a synthetic test that submits a clearly invalid token to the introspection endpoint; a response of {"active": true\} confirms the vulnerable code path.
• Correlate OIDC client traffic with downstream resource server authorization decisions to identify approvals based on tokens that were never issued.

Monitoring Recommendations

• Alert on any HTTP 200 response from /oidc/introspect where the request body lacks a properly formatted JWT or opaque token from the issuer.
• Track Admidio version strings via banner or build metadata and flag instances reporting versions earlier than 5.0.9.
• Monitor authentication failure-to-success ratios on resource servers integrated with Admidio for sudden drops that may indicate exploitation.

How to Mitigate CVE-2026-41671

Immediate Actions Required

• Upgrade all Admidio installations to version 5.0.9 or later, which contains the fix.
• Until patched, disable OIDC single sign-on in Admidio or block external access to /modules/sso/index.php/oidc/introspect and /oidc/revoke at the reverse proxy.
• Rotate OIDC client secrets and force re-issuance of all access and refresh tokens after upgrading.

Patch Information

The fix is included in Admidio 5.0.9. Release notes and source changes are available in the GitHub Release v5.0.9. The advisory describing the issue is published as GHSA-9xx5-cv6j-x533.

Workarounds

• Configure resource servers to validate tokens locally using the issuer's signing keys and the JWT exp, iat, and aud claims rather than relying on Admidio introspection.
• Restrict the introspection and revocation endpoints to trusted resource server IP ranges via web server access control rules.
• Require mutual TLS or HTTP Basic authentication at the reverse proxy in front of /oidc/introspect and /oidc/revoke to limit which clients can invoke them.

# Example nginx restriction for the introspection and revocation endpoints
location ~ ^/(modules/sso/index\.php/oidc/introspect|oidc/revoke)$ {
    allow 10.0.0.0/8;        # trusted resource server subnet
    deny  all;
    proxy_pass http://admidio_backend;
}