CVE-2026-92289 Affecting lemonldap-ng package, versions <2.23.4+ds-1
Threat Intelligence
The probability is the direct output of the EPSS model, and conveys an overall sense of the threat of exploitation in the wild. The percentile measures the EPSS probability relative to all known EPSS scores. Note: This data is updated daily, relying on the latest available EPSS model version. Check out the EPSS documentation for more details.
Do your applications use this vulnerable package?
In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.
Test your applications- Snyk IDSNYK-DEBIANUNSTABLE-LEMONLDAPNG-20125767
- published25 Sept 2026
- disclosed25 Sept 2026
Introduced: 25 Sep 2026
CVE-2026-92289 (opens in a new tab)How to fix?
Upgrade Debian:unstable lemonldap-ng to version 2.23.4+ds-1 or higher.
NVD Description
Note: Versions mentioned in the description apply only to the upstream lemonldap-ng package and not the lemonldap-ng package as distributed by Debian.
See How to fix? for Debian:unstable relevant fixed versions and status.
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.