CyberRota Analysis
AI-GeneratedLemonldap::NG::Portal versions prior to 2.23.4 for Perl are vulnerable to a PKCE bypass in "PKCE or secret" mode, allowing public Relying Parties to issue authorization codes without proper validation of the client secret. This flaw enables attackers to intercept authorization codes and exchange them for access, ID, and refresh tokens, undermining the security intended by PKCE. Organizations using affected versions should prioritize patching to mitigate the risk of unauthorized access to user tokens.
Original NVD 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.