An authentication enforcement vulnerability in SonicOS SSLVPN service may allow a user with valid credentials for an alternate authentication method to bypass SAML authentication controls. Successful exploitation may also bypass SAML-enforced multi-factor authentication (MFA).
CVE-2026-90862 is an improper authentication vulnerability in the Web Transfer Module of Progress Software WS_FTP Server on Windows. It affects versions prior to 2024.0.7 and 2025.0.4. An attacker who has a user's password could access certain files associated with that account without completing multi-factor authentication. The vulnerability has a medium severity with a CVSS score of 4.3.
FileRise versions prior to 3.16.0 have a vulnerability in their WebDAV Basic authentication implementation where the second factor of authentication (TOTP) is not enforced. This allows an attacker with valid primary credentials to bypass two-factor authentication and access WebDAV file permissions. The browser login path correctly enforces TOTP, but the WebDAV authentication callback does not. This issue is fixed in version 3.16.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`
Termix is a web-based server management platform with SSH terminal, tunneling, and file editing capabilities. From 2.4.0 until 2.5.1, the POST /users/totp/disable and POST /users/totp/backup-codes endpoints accept the account password as the sole reauthentication factor after a 2.4.0 refactor regressed the two-factor check introduced for CVE-2026-45749. In src/backend/database/routes/user-totp-routes.ts, verifyTotpReauth returns success when bcrypt.compare validates the password, while each endpoint chooses password or totp_code as an interchangeable credential. An attacker who has a victim's authenticated session and knows the password can disable TOTP or regenerate and invalidate backup codes without an authenticator or valid second factor, weakening the account to single-factor authentication. This issue is fixed in version 2.5.1.
CVE-2026-58240 is a critical vulnerability in SAP NetWeaver Message Server versions 9.18, 9.19, and 9.20. The issue arises from insufficient validation of internal application server components during registration, allowing an unauthenticated attacker with network access to register unauthorized components. This can lead to unauthorized actions within the application environment, severely impacting confidentiality, integrity, and availability.
CVE-2024-27928 affects vantage6 versions prior to 5.0.0 and involves the reduction of two-factor authentication (2FA) to single-factor authentication (1FA) via email account compromise. An attacker who gains access to a user's email can reset both the password and the 2FA token through email, bypassing the intended 2FA protection. This issue is fixed in vantage6 version 5.0.0. No workarounds are available. The risk is somewhat mitigated by the fact that most email providers require 2FA for email access, reducing the likelihood of exploitation.
Termix is a web-based server management platform with SSH terminal, tunneling, and file editing capabilities. The `POST /users/totp/disable` and `POST /users/totp/backup-codes` endpoints in Termix prior to version 2.3.2 accept the account password as a sole authentication factor for MFA-critical operations. An attacker who obtains a user's password (phishing, credential stuffing, the passwordHash leak in GHSA-xxxx) can disable TOTP entirely or regenerate backup codes, without ever possessing the TOTP device or knowing a valid TOTP code. This renders two-factor authentication ineffective. Version 2.3.2 patches the issue.
CVE-2026-33550 is a low-severity vulnerability in Alinto's SOGo email and collaboration platform versions before 5.12.5. The issue involves improper handling of one-time passwords (OTPs) used for multi-factor authentication (MFA). Specifically, when a user disables and then re-enables OTP-based MFA, the system fails to renew the OTP secret, and the OTP length is only 12 digits instead of the recommended 20 digits. This weakness effectively reduces the strength of the second authentication factor, increasing the risk of unauthorized access through OTP guessing or replay attacks. Exploitation requires high privileges and user interaction, and no known exploits exist in the wild. Organizations using vulnerable SOGo versions should upgrade to 5.12.5 or later and enforce stronger OTP configurations to mitigate this risk.
An unauthenticated attacker may exploit a scenario where a Hashed Message Authentication Code (HMAC) credential, extracted from a system missing specific security patches, is reused in a replay attack against a different system. Even if the target system is fully patched, successful exploitation could result in complete system compromise, affecting confidentiality, integrity, and availability.