CVE-2026-92288 in Lemonldap::NG
Summary
by MITRE • 09/25/2026
Lemonldap::NG::Portal versions from 2.20.0 before 2.21.6, from 2.22.0 before 2.23.4 for Perl allow unauthenticated OAuth2 token introspection because checkEndPointAuthenticationCredentials does not verify the client secret of a public Relying Party.
checkEndPointAuthenticationCredentials() skips the secret comparison for a Relying Party marked public and still returns the authentication method deduced from the request, client_secret_basic or client_secret_post. introspection() rejects a caller only when that method is missing or none, so a request carrying a public client_id and an arbitrary or empty secret passes the endpoint's authentication check.
An attacker who holds an access token and knows the client_id of any public Relying Party can confirm the token is active and read its metadata, including scope, audience, expiry and the sub claim. The sub claim is computed with the calling Relying Party's user identifier attribute, so an attacker can translate a user identifier from one Relying Party to another, defeating per-client and pseudonymous identifiers.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/25/2026
The vulnerability in Lemonldap::NG::Portal versions ranging from 2.20.0 up to but not including 2.21.6, and from 2.22.0 up to but not including 2.23.4 for Perl environments, represents a critical failure in the authentication logic governing OAuth2 token introspection endpoints. This flaw stems directly from an implementation error within the checkEndPointAuthenticationCredentials function, which is responsible for validating client credentials before allowing access to sensitive identity management operations. Specifically, when handling requests from Relying Parties designated as public clients, the system incorrectly bypasses the verification of the client secret. According to OAuth2 standards defined in RFC 6749 and related specifications like RFC 8252 for native applications, public clients are indeed not required to authenticate with a client secret because they cannot securely store one. However, the introspection endpoint implementation fails to distinguish correctly between the absence of authentication requirements for public clients and the actual validation process, leading it to return an authentication method such as client_secret_basic or client_secret_post even when no valid credentials were provided. This logical error allows any request carrying a known public client_id along with an arbitrary or empty secret string to successfully pass the endpoint's initial authentication gate.
The operational impact of this vulnerability is severe because it enables unauthenticated access to token introspection data for any active OAuth2 bearer token issued by the system. An attacker who possesses a valid access token and knows the client identifier associated with any public Relying Party can query the introspection endpoint to confirm whether that specific token is currently active, expired, or revoked. Beyond simple status verification, this flaw allows the extraction of detailed metadata embedded within the token response. This includes sensitive attributes such as the scope permissions granted to the token, its intended audience, expiration timestamps, and crucially, the subject claim which identifies the end-user associated with the session. The ability to read these fields transforms a standard authorization bypass into a comprehensive information disclosure event that compromises both system integrity and user privacy.
A particularly dangerous consequence of this vulnerability is the potential for cross-client identity correlation and pseudonymity breaking. In many multi-tenant or federated identity architectures, different Relying Parties are assigned distinct user identifiers to maintain separation between services and protect user anonymity across platforms. The introspection endpoint computes the sub claim based on the calling Relying Party's configured user identifier attribute. By exploiting this flaw with a public client_id from one service, an attacker can retrieve the internal user identifier associated with that specific party. If the underlying identity provider uses consistent or linkable identifiers for users across different services, or if the attacker can correlate data from multiple such breaches, they can map identities across distinct applications. This defeats security controls designed to provide per-client isolation and pseudonymous identification, effectively allowing an adversary to track user activity and profile individuals without their consent by linking accounts that were intended to remain separate.
From a classification perspective, this vulnerability aligns with CWE-287 Improper Authentication, as the system fails to properly verify credentials for public clients in contexts where authentication logic is incorrectly applied or bypassed improperly. It also relates closely to CWE-359 Exposure of Private Information Within an Info Page, given that sensitive token metadata and user identifiers are exposed without proper authorization checks. In terms of offensive security frameworks such as MITRE ATT&CK, this behavior facilitates the T1078 Valid Accounts technique by allowing attackers to leverage valid tokens for reconnaissance, and potentially supports T1528 Steal Application Access Token if combined with other initial access vectors. The vulnerability essentially turns a standard OAuth2 introspection endpoint into an unauthenticated information leak channel that undermines the trust model of the entire identity infrastructure.
Mitigation strategies must prioritize immediate patching to versions 2.21.6 or later for the older branch and 2.23.4 or later for the newer branch, as these releases contain corrections to the checkEndPointAuthenticationCredentials logic. Until patches are applied, administrators should consider disabling token introspection endpoints if they are not strictly required by their architecture, thereby removing the attack surface entirely. Additionally, implementing strict IP whitelisting on the introspection endpoint can limit exposure to trusted internal networks only, reducing the risk of remote exploitation. It is also advisable to review configuration settings for public clients and ensure that no sensitive user identifiers or cross-service correlation data are included in token claims unless absolutely necessary. Regular auditing of access logs for unusual patterns of introspection requests from unknown or unexpected client IDs can help detect potential exploitation attempts early, providing an additional layer of defense-in-depth while the underlying code defect is addressed.