The SMS Alert WordPress plugin before 4.0.1 does not verify that the account being logged in is the one the verified one-time code belongs to, allowing unauthenticated attackers to sign in as any user with a stored phone number, including an administrator, by completing a code challenge on a phone they control.
The Contest Gallery WordPress plugin before 33.0.1 does not limit the number of attempts against its front-end registration email-verification step, which relies on a short numeric PIN, allowing unauthenticated attackers to brute-force the PIN and create and activate a WordPress account bound to an email address they do not own, gaining an authenticated session.
The Advanced IP Blocker WordPress plugin up to version 8.13.13 contains a critical authentication bypass vulnerability. This flaw allows unauthenticated attackers to bypass two-factor authentication (2FA) by exploiting improper server-side checks and nonce reuse. Attackers can brute-force a 6-digit TOTP code without rate limiting or lockout, gaining full authenticated sessions and potentially complete site takeover. Exploitation requires only knowledge of a valid user ID with 2FA enabled. The vulnerability is tracked as CVE-2026-104732 with a CVSS score of 9.8.
The Advanced Form Integration — Connect Forms to 300+ Apps WordPress plugin up to version 2.9.0 contains an authentication bypass vulnerability. This flaw allows unauthenticated attackers to change any WordPress user's password, including administrators, by submitting a specially crafted public Contact Form 7 form. The vulnerability arises because the plugin's function handling the Ultimate Member "Update Profile Field" action does not verify the submitter's identity or permissions before updating sensitive user profile fields such as passwords. Exploitation requires prior configuration of the Contact Form 7 integration with the vulnerable action.
Vikunja versions 1.0.0 through 2.3.0 contain an improper authentication vulnerability in the OpenID Connect provider's email fallback feature. When enabled, the system links an SSO login to a local account using only the email claim without verifying the email or requiring the account password. This allows an attacker who obtains a token with a victim's email to log in as that victim without their consent. The issue is fixed in version 2.4.0.
## 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`
TP-Link Tapo C325WB v2 has an unauthenticated authorization bypass vulnerability in its HTTPS JSON API on TCP port 443. An attacker on the adjacent network can exploit this flaw by appending an onboarding-scoped object to a JSON request, bypassing session verification and performing privileged actions without authentication. This can lead to unauthorized access to live video and audio streams, modification of device settings, and exposure of sensitive device information or secrets.
CVE-2026-16823 is a critical improper authentication vulnerability in IBM Security Verify Access and IBM Verify Identity Access. Versions 10.0 through 10.0.9.2 and 11.0 through 11.0.3 are affected. This flaw could allow a remote attacker to bypass security restrictions without authentication, potentially leading to full confidentiality and integrity compromise. No known exploits are reported in the wild. No patch or remediation details are provided in the available data.
CVE-2026-19491 is a critical improper authentication vulnerability in IBM Security Verify Access and IBM Verify Identity Access. Versions 10.0 through 10.0.9.2 and 11.0 through 11.0.3 are affected. This flaw allows a remote attacker to bypass authentication without any privileges or user interaction. The vulnerability has a CVSS score of 9.1, indicating high impact on confidentiality and integrity. No patch information is provided in the available data.
CVE-2026-19494 is a high-severity vulnerability in IBM Security Verify Access and IBM Verify Identity Access that allows a remote authenticated attacker to bypass security restrictions due to improper authentication. It affects versions 10.0 through 10.0.9.2 and 11.0 through 11.0.3. The vulnerability has a CVSS 3.1 score of 8.1, indicating a significant impact on confidentiality and integrity without requiring user interaction. No official patch or remediation details are provided in the available data.
CVE-2026-14502 is a critical improper authentication vulnerability in IBM DataPower Gateway versions 10.5.0.0 through 10.5.0.22, 10.6.0.0 through 10.6.0.10, 10.6.1 through 10.6.6, and 11.0.0.0 through 11.0.0.2. The flaw allows a remote attacker to gain administrative access by exploiting the failure to reject empty passwords during LDAP authentication.
The Ultimate Multisite WordPress plugin before 2.17.0 does not require authentication before a logged-out checkout is linked to, and logged in as, an existing WordPress account matching the submitted email address, and its duplicate-account check normalizes that address differently from the lookup used to create the customer, so an unauthenticated attacker can log in as any existing user, including a Network Super Admin, whose email address they know.
This bypass is not addressed by the 2.15.1 fix for CVE-2026-75957 and remains exploitable in all versions up to and including 2.16.1, the releases that fix was expected to cover. Exploitation requires a checkout form configured without a password field (auto-generated password) and a target account that has no existing customer record in the Ultimate Multisite WordPress plugin before 2.17.0.
AsyncHttpClient versions from 2.1.0 up to 2.16.1 and from 3.0.0 up to but not including 3.0.14 have an improper authentication vulnerability. The enabled-by-default cookie store can overwrite explicitly set Cookie headers in HTTP requests, causing requests to execute under the wrong user session. This bypasses previous remediation efforts and can lead to session confusion. The issue is fixed in version 3.0.14.
wger versions prior to 2.6 contain an improper authentication vulnerability where bearer-style API tokens remain valid after user logout or password change. This allows an attacker with a stolen token to continue accessing protected API endpoints until the token expires or is manually revoked. Version 2.6 includes a patch to address this issue.
When password or public key authentication is used with the Windows port of wolfSSHd, the Windows logon token acquired for one authenticated connection is not released before a token is acquired for a subsequent connection, resulting in user login poisoning between connections. A less privileged user with a valid account on the server can exploit this to force a login as a more privileged user. The vulnerability was introduced with the initial Windows port of wolfSSHd in wolfSSH version 1.4.15 and affects all versions through 1.5.0. Non-Windows builds of wolfSSHd are not affected.
Backstage versions from 1.18.0 up to but excluding 1.49.7, and from 1.50.0-next.0 up to but excluding 1.54.7, contain an improper authentication vulnerability in the @backstage/plugin-auth-node package. This flaw allows an attacker with an admitted identity-provider user account to assume another catalog identity by exploiting inconsistent handling of explicit negative email verification flags during OAuth profile normalization. The issue is fixed in versions 1.49.7 and 1.54.7.
CVE-2026-106457 is an improper authentication vulnerability in the Backstage open framework affecting the @backstage/plugin-auth-backend-module-cloudflare-access-provider package versions from 1.26.0 up to but not including 1.55.0. The flaw involves insufficient audience validation in the Cloudflare Access authentication provider, allowing a valid token issued for another application within the same Cloudflare Zero Trust team to authenticate to Backstage if audience enforcement is not done upstream. This issue is fixed in version 1.55.0.
Improper authentication (CWE-287) in the OAuth token endpoint in Cloud Foundry UAA allows a remote, authenticated attacker holding a valid user access token to obtain a fully-privileged client_credentials token for the OAuth client that issued it, by presenting the user token as an OAuth 2.0 Bearer credential on a client_credentials grant request in place of the client’s configured secret.
UAA’s client_credentials handling does not verify that the Bearer credential supplied for client authentication is actually a client credential (a client secret or a valid configured client authentication method); it accepts any valid access token whose client_id matches the request. A token obtained by a normal end user through a public authorization_code + PKCE flow — scoped only to uaa.user, carrying a user_id, and recording client_auth_method=none — satisfies this check. That user token cannot itself administer OAuth clients (POST /oauth/clients correctly returns 403), but when replayed as Bearer authentication on a client_credentials request for the same client, UAA issues a new client-only token carrying the client’s full authorities, such as clients.write. An attacker can use that token to create arbitrary new OAuth clients, including clients with attacker-chosen authorities, without ever possessing the client’s actual secret.
Exploitation requires a valid user access token (the attacker’s own) for a client that is configured to support both a public, user-facing authorization flow and the client_credentials grant type on the same client_id — a non-default combination. Practical impact scales with the authorities assigned to that client.
The Deema Payment Gateway WordPress plugin through 1.1.2 does not verify the payment with the payment provider when handling the return from the hosted checkout, and does not check the payment status or amount, allowing unauthenticated users to have orders marked as paid without any payment being taken.
The Deema Payment Gateway WordPress plugin through 1.1.2 does not verify the authenticity of incoming payment provider notifications, and ships with that verification disabled by default, allowing unauthenticated attackers to mark an unpaid order as paid, or to cancel or refund an existing order.