| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Weak authentication in Azure Key Vault allows an unauthorized attacker to bypass a security feature over a network. |
| Weak authentication in Active Directory Federation Services (AD FS) allows an unauthorized attacker to perform spoofing over a network. |
| Weak authentication in Active Directory Federation Services (AD FS) allows an unauthorized attacker to perform spoofing over a network. |
| Weak authentication in Network Device Enrollment Service (NDES) allows an unauthorized attacker to execute code over a network. |
| Weak authentication in Windows Error Reporting allows an authorized attacker to elevate privileges locally. |
| Weak authentication in Microsoft Input Method Editor (IME) allows an authorized attacker to elevate privileges locally. |
| Weak authentication in Windows Print Spooler Components allows an authorized attacker to elevate privileges locally. |
| Weak authentication in Windows Projected File System allows an authorized attacker to elevate privileges locally. |
| Weak authentication in Windows Resilient File System (ReFS) Deduplication Service allows an authorized attacker to elevate privileges locally. |
| Weak authentication in Windows Modern Device Management (MDM) allows an authorized attacker to perform tampering locally. |
| Weak authentication in Microsoft Exchange Server allows an authorized attacker to elevate privileges over a network. |
| Weak authentication in Active Directory Federation Services (AD FS) allows an unauthorized attacker to bypass a security feature over a network. |
| Weak authentication in Active Directory Federation Services (AD FS) allows an unauthorized attacker to bypass a security feature over a network. |
| Weak authentication in Windows Kernel allows an authorized attacker to bypass a security feature over a network. |
| Weak authentication in Network Device Enrollment Service (NDES) allows an authorized attacker to perform spoofing over a network. |
| Weak authentication in Microsoft PowerToys allows an authorized attacker to perform tampering locally. |
| LiteLLM contains a weak authentication vulnerability that allows an attacker holding a valid JWT from the configured identity provider to authenticate as any existing user by exploiting an email-based fallback lookup in the JWT authentication flow without verifying the email_verified claim. Attackers can present a token with an unverified email address matching a victim's account to inherit the victim's role, including proxy_admin privileges, and permanently overwrite the victim's stored identity binding to retain persistent unauthorized access to administrative endpoints exposing API keys and user management. |
| 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. |
| 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. |
| An HTTP endpoint intended for provisioning enterprise and reseller organisations is reachable without any session. The authentication middleware is bound only to an explicit list of controllers, and the enterprise controller is not on that list, so no authentication runs for these routes.
The endpoint's only check is that the request body carries a token bearing a valid signature from the instance secret. It does not check what that token was issued for. Login tokens are signed with the same secret and carry no purpose, audience or expiry claim, so an ordinary user's own session token satisfies the check.
Presented with such a token, the endpoint creates a new organisation holding the highest subscription tier, flagged as lifetime and with a channel allowance far above any sold plan, creates an organisation-owner account alongside it, and returns the new organisation's API key in the response body. That key is immediately valid against the public API. |
