Description

Lemonldap::NG::Portal versions from 2.23.0 before 2.23.4 for Perl allow a PKCE bypass for public Relying Parties in "PKCE or secret" mode because checkEndPointAuthenticationCredentials does not verify the client secret. With oidcRPMetaDataOptionsRequirePKCE set to 2, the authorization endpoint issues a code even when the request carries no code_challenge, and token() admits the exchange as long as a challenge was stored or an authentication method was returned for the caller. checkEndPointAuthenticationCredentials() skips the secret comparison for a Relying Party marked public and still returns the method deduced from the request, so any Basic or form credential satisfies the secret branch. validatePKCEChallenge() then passes, because neither a challenge nor a verifier is present. An attacker who intercepts an authorization code issued to a public Relying Party can exchange it for the user's access, ID and refresh tokens by replaying the client_id with an arbitrary secret, which is the attack PKCE prevents. Dynamic client registration creates every Relying Party in this mode.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.1",
  "pubDate": "2026-09-25T01:16:48.943Z",
  "pubdate": "2026-09-25T01:16:48.943Z",
  "executiveSummary": "Lemonldap::NG::Portal versions 2.23.0 through 2.23.3 contain a critical authentication bypass vulnerability related to Proof Key for Code Exchange (PKCE) validation.\nThe vulnerability allows an attacker to bypass PKCE requirements for public Relying Parties when the 'PKCE or secret' mode is active, even when the oidcRPMetaDataOptionsRequirePKCE configuration is set to 2.\nBy failing to properly enforce client secret verification during the token exchange process, the system permits unauthorized parties to successfully exchange intercepted authorization codes for valid access, ID, and refresh tokens.\nThis flaw effectively negates the security guarantees provided by PKCE, enabling attackers to perform unauthorized authentication flows.\nThe vulnerability is particularly severe because dynamic client registration defaults to this vulnerable configuration.\nSuccessful exploitation requires the attacker to intercept an authorization code issued to a legitimate public Relying Party. Once obtained, the attacker can replay the request with an arbitrary client secret to complete the token exchange, leading to potential account takeover or unauthorized data access.",
  "technicalDetails": "The root cause of this vulnerability lies in the implementation of the checkEndPointAuthenticationCredentials function within Lemonldap::NG::Portal. When a Relying Party (RP) is designated as 'public,' the function intentionally skips the validation of the client secret.\nIn the vulnerable versions, specifically when oidcRPMetaDataOptionsRequirePKCE is set to 2, the authorization endpoint incorrectly issues an authorization code even if the initial request lacks a code_challenge parameter.\nDuring the token exchange process, the token() function relies on the outcome of checkEndPointAuthenticationCredentials(). Because this function erroneously returns a valid authentication method for public RPs without verifying the secret, any Basic authentication or form-based credential provided by the requester is accepted as valid.\nFurthermore, the validatePKCEChallenge() function fails to enforce security requirements because it does not properly handle the absence of both a code_challenge and a code_verifier. If neither parameter is present in the request, the function proceeds without raising an error, allowing the authorization code exchange to complete.\nThe attack flow follows these steps: 1. An attacker intercepts a legitimate authorization code issued to a public Relying Party. 2. The attacker initiates a token exchange request to the portal, supplying the intercepted code and the targeted client_id. 3. Because the RP is public, checkEndPointAuthenticationCredentials() bypasses secret validation. 4. Since no challenge or verifier was required during the initial issuance, validatePKCEChallenge() returns success. 5. The portal issues the access, ID, and refresh tokens to the attacker.\nThis behavior affects all components relying on the portal's OIDC implementation for public clients, and the issue is compounded by the fact that dynamic client registration defaults to this vulnerable 'PKCE or secret' configuration, significantly widening the attack surface for installations that rely on automated client onboarding."
}