Apache Qpid Proton C versions up to 0.40.0 contain an authentication bypass vulnerability due to improper handling of SASL frames during peer authentication. This flaw allows AMQP frames masquerading as SASL frames to bypass authentication, potentially granting unauthorized access. The impact depends on how the application handles the absence of a username, as authentication is considered incomplete in such cases. The issue is fixed in version 0.41.1.
CVE-2026-10537 is an authentication bypass vulnerability in BMC Control-M/Enterprise Manager and Control-M/Server. It arises from a misconfiguration that allows unauthenticated remote users to access certain service functionalities. This could lead to information exposure or impact service availability. The issue affects Control-M/Enterprise Manager and Control-M/Server versions from 9.0.20 up to but not including 9.0.22, as well as potentially earlier unsupported versions. The vulnerability has a medium severity rating with a CVSS score of 6.9.
## Summary
nginx-ui supports two second-factor methods — TOTP (OTP) and WebAuthn passkeys —
and reports an account as 2FA-enabled when **either** is configured. However, the
password login endpoint (`POST /api/login`) only enforces a second factor when a
**TOTP secret** is present. An account that has registered a **passkey but no
TOTP** is logged in after password verification alone — the passkey is never
requested. This silently downgrades a passkey-protected account to single-factor
(password-only) authentication.
## Details
The account's 2FA policy treats passkeys as a valid factor (`model/user.go`):
```go
func (u *User) EnabledOTP() bool { return len(u.OTPSecret) != 0 }
func (u *User) EnabledPasskey() bool { /* true if a passkey row exists */ }
func (u *User) Enabled2FA() bool { return u.EnabledOTP() || u.EnabledPasskey() }
func (u *User) AfterFind(_ *gorm.DB) error {
u.EnabledTwoFA = u.Enabled2FA() // exposed to the UI as `enabled_2fa`
return nil
}
```
But the login handler only checks `EnabledOTP()` (`api/user/auth.go`, `Login`):
```go
u, err := user.Login(json.Name, json.Password)
...
if u.EnabledOTP() { // <-- only TOTP is enforced
if json.OTP == "" && json.RecoveryCode == "" {
c.JSON(http.StatusOK, LoginResponse{Message: "The user has enabled 2FA", Code: Enabled2FA}) // 199
user.BanIP(clientIP)
return
}
if _, err = user.VerifyOTP(u, json.OTP, json.RecoveryCode); err != nil { /* ... */ }
secureSessionID = user.SetSecureSessionID(u.ID)
}
// Passkey-only accounts fall through to here and receive a full session token:
accessToken, err := user.GenerateJWT(u)
```
No branch requires a WebAuthn assertion during password login when
`EnabledPasskey()` is true. The root cause is the mismatch between the
**policy definition** (`Enabled2FA()` = OTP **or** passkey) and the
**enforcement check** (`EnabledOTP()` only).
The same `EnabledOTP()`-only gating in `RequireSecureSession()`
(`internal/middleware/secure_session.go`) means passkey-only users are also
exempted from step-up on sensitive actions.
## Proof of Concept
Tested against nginx-ui built from source (`go build -tags unembed`) on
`127.0.0.1:9000`, with WebAuthn configured and a victim account that has a
registered passkey and **no** TOTP. The vulnerable code is identical on the
production `main` branch (`api/user/auth.go` `Login` gates on `u.EnabledOTP()`
only; verified at commit `6c86e5a`, 2026-05-17).
Account state advertised by `GET /api/2fa_status`:
```json
{"enabled":true,"otp_status":false,"passkey_status":true, ...}
```
Attacker logs in with **password only** (`POST /api/login`, encrypted params as
the client normally sends):
```
HTTP 200
{"message":"ok","code":200,"token":"eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...."}
```
`code: 200` + a valid JWT = an authenticated session, with the passkey never
used. For comparison, the identical account with a TOTP secret instead correctly
returns the second-factor challenge:
```
HTTP 200
{"message":"The user has enabled 2FA","code":199}
```
| Account state | `POST /api/login` (password only) |
|---|---|
| Passkey registered, no TOTP | `code 200` + JWT — **2FA NOT enforced** |
| TOTP registered | `code 199` — 2FA challenge enforced |
This isolates the defect: the login path enforces OTP but ignores passkeys.
## Impact
- Any account protected **only** by a passkey is reduced to password-only
authentication. An attacker who obtains the password (phishing, reuse, leak)
gains full access despite the registered security key.
- In nginx-ui all authenticated users are effectively administrators and the
terminal feature grants a host shell, so account takeover leads to full
control of the managed nginx instance / host.
- Users are given a false sense of security: the UI shows the account as
2FA-enabled while the second factor is not enforced at login.
## Remediation
- Gate the second-factor decision on `u.Enabled2FA()` (not `u.EnabledOTP()`) in
`Login`, in both SSO callbacks, and in `RequireSecureSession()`.
- For a passkey-only user logging in with a password, return a
"passkey assertion required" challenge and complete login only after a
successful WebAuthn assertion (the `begin_passkey_login` / `finish_passkey_login`
flow already exists and should be required as the second step).
- Centralize session-token issuance so no login entry point can skip the 2FA
decision.
## Affected components
- `api/user/auth.go` — `Login`
- `model/user.go` — `EnabledOTP`, `EnabledPasskey`, `Enabled2FA`, `AfterFind`
- `api/user/2fa.go` — `get2FAStatus`
- `internal/middleware/secure_session.go` — `RequireSecureSession`
CVE-2026-77185 is a critical authentication bypass vulnerability in Apache MINA SSHD versions 2.0.0 to 2.19.0 and 3.0.0-M1 to 3.0.0-M5. It affects the asynchronous authentication mechanism in the sshd-core component, potentially allowing signature checks to be skipped in public-key or hostbased authentication. The flaw arises from a logic error in the implementation of asynchronous authentication, which must be explicitly used by the server. Fixed in versions 2.20.0 and 3.0.0-M6, these updates also restrict asynchronous authentication to password or keyboard-interactive methods only, closing sessions if misused.
Authentication bypass via LDAP injection in component sshd-ldap in Apache MINA SSHD versions 1.2.0 to 2.19.0 and 3.0.0-M1 to 3.0.0-M5.
Apache MINA SSHD is a Java library for client-side and server-side SSH.
The optional sshd-ldap component provides support for integrating
password and publickey authentication on the server side with an LDAP
server.
sshd-ldap is an optional component. SSH servers implemented with Apache
MINA SSHD are affected only if they use sshd-ldap and do configure it to be used for password of public key authentication.
Other Apache MINA SSHD servers are not affected.
Lack of escaping LDAP filter metacharacters enabled successful authentication with username "*" and password "*".
Users are recommended to upgrade affected applications to version 2.20.0 or 3.0.0-M6, which fix this issue by properly escaping filter parameters according to RFC 4515.
Zscaler MCP Server versions 0.7.0 and 0.7.1 has an issue where HMAC confirmation tokens were not bound to the target resource identifier, allowing an MCP client or agent to replay a token generated for one resource to affect another resource of the same type. This issue is fixed in version 0.7.2.
Authentication Bypass by Primary Weakness vulnerability in team-alembic AshAuthentication allows an unconfirmed user to obtain a session, defeating a mandatory email confirmation requirement.
AshAuthentication.Strategy.Password.Actions.check_user/2 decides whether the attribute named by require_confirmed_with is set using a bare is_nil(Map.get(user, value)). When that attribute is not selected on the loaded record Map.get/2 returns %Ash.NotLoaded{}, and when a field policy denies it for the current actor it returns %Ash.ForbiddenField{}. Neither is nil, so the rejection branch is skipped and sign-i
require_confirmed_with is enforced in two places, and neither holds in every configuration. sign_in_with_token and register are checked only inside AshAuthentication.Strategy.Password.Actions, not on the action itself, so any caller that invokes the action directly skips the check. An API layer such as AshGraphql or AshJsonApi invokes the action directly, so this applies to the default configuration. Where a check does run it compares the confirmation attribute against nil. That attribute holds %Ash.NotLoaded{} or %Ash.ForbiddenField{} when it sets select_by_default?: false, when an API layer narrows the read's select, or when a field policy hides it from the sign-in actor. Neither struct is nil, so those configurations read every user as confirmed.
This issue affects ash_authentication: from 4.3.8 before 4.15.0 and from 5.0.0-rc.0 before 5.0.0-rc.14.
CVE-2026-86207 is a high-severity authentication bypass vulnerability in N-able N-central versions prior to 2026.3.1.13. The flaw allows bypassing authentication in internal-only APIs due to a primary weakness classified as CWE-305. This vulnerability could enable unauthorized access to internal API functions.
An improper access control vulnerability exists in the web management interface of PaperCut MF and PaperCut NG. Under specific conditions, unauthenticated remote requests targeting administrative functions can trigger backend actions prior to the completion of access validation checks. This allows an unauthenticated remote attacker to modify certain system configurations.
CVE-2026-16895 is a logic vulnerability in the Rapid7 Metasploit Framework's JSON-RPC web service interface. The flaw arises when an exception during a database health check causes the internal authentication state to reset improperly, allowing unauthenticated local access. This occurs if the environment variable MSF_WS_JSON_RPC_API_TOKEN is not set, leading the authentication mechanism to mistakenly allow access without credentials. The vulnerability affects versions prior to 6.5.2 and has a medium severity rating.
Punk::Plugin::TOTP versions before 0.05 for Perl contain an authentication bypass vulnerability in the two-factor authentication process. The vulnerability arises because the recovery code verification compares user identifiers numerically, causing identifiers without leading digits to coerce to zero and bypass ownership checks. This allows an attacker who knows a victim's password and has their own recovery code to bypass the victim's second factor and authenticate as the victim.
An improper authentication vulnerability exists in Apache Hive versions 4.0.0 through 4.2.0 when using HiveServer2 with SAML authentication over HTTP transport. This flaw allows an unauthenticated attacker with network access to the HiveServer2 HTTP port to impersonate any Hive user by sending a forged Authorization: Bearer token to the /cliservice endpoint. No Hive credentials, SAML IdP login, or server signing secret knowledge is required. The vulnerability does not affect deployments where Apache Knox handles SSO and HiveServer2 uses LDAP or Kerberos authentication.
CVE-2026-19349 is a critical authentication bypass vulnerability in Lemonldap::NG::Portal affecting certain versions that use the GitHub and LinkedIn OAuth2 backends. The flaw allows an unauthenticated visitor to replay a session identifier used as an OAuth2 state parameter to gain a valid SSO session without proper authentication. This occurs because the state parameter is stored as a regular SSO session lacking user and authentication level attributes, which some default configurations accept. Only deployments with the GitHub or LinkedIn authentication modules enabled are affected.
Authentication bypass by primary weakness vulnerability in Universal Software Inc. E-Municipality allows Exploitation of Trusted Identifiers.
This issue affects E-Municipality: from 20251127 before 20260204.
Passkey entry Bluetooth LE legacy pairing can be bypassed in the RS9116W and SiWx917 by manipulating the temporary key value.
See vulnerability B-E3 in the related paper below.
Re-pairing with a legitimate device can use a lower security level than
previous making brute-forcing the LTK easier. See V4 in the BLERP paper linked below.
A flaw was found in the keycloak-services component of Keycloak. This issue is an incomplete fix for CVE-2026-9798, where brute-force protection checks were added to the Client-Initiated Backchannel Authentication (CIBA) initiation handler but were omitted from the token redemption handler. This allows an attacker with valid client credentials to obtain access and refresh tokens for a user account that has been locked due to brute-force protection, provided the authentication request was started before the lockout occurred and was approved by the user.
Dell Client Platform BIOS contains an Authentication Bypass by Primary Weakness vulnerability. An unauthenticated attacker with physical access could potentially exploit this vulnerability, leading to Information Disclosure.