CVE WatchAug 4, 2026

CVE-2024-53704

SonicWall SonicOS SSLVPN Improper Authentication Vulnerability

CVSS

9.8

Critical

EPSS

95.1%

p100

KEV

YES

Feb 18, 2025

Exploit Today

0-100

Published: Jan 9, 2025 · Last modified: Aug 4, 2026 · CWE-287

EPSS · 30d

95.1%EPSS · 30 days95.1%

2026-09-162026-10-14

KEV catalog record

Product

SonicWall / SonicOS

Vulnerability

SonicWall SonicOS SSLVPN Improper Authentication Vulnerability

Added to KEV

Feb 18, 2025

Remediate by

Mar 11, 2025

Known ransomware use

Yes

Summary description

SonicWall SonicOS contains an improper authentication vulnerability in the SSLVPN authentication mechanism that allows a remote attacker to bypass authentication.

Required action

Apply mitigations per vendor instructions or discontinue use of the product if mitigations are unavailable.

Notes

https://psirt.global.sonicwall.com/vuln-detail/SNWLID-2025-0003 ; https://nvd.nist.gov/vuln/detail/CVE-2024-53704

Technical description

An Improper Authentication vulnerability in the SSLVPN authentication mechanism allows a remote attacker to bypass authentication.

Official references

Related CVEs

CVECVSSEPSSKEVRExploitTitleMod.

CVE-2026-571836.1 MED

—

———Scoold is a Q&A and a knowledge sharing platform for teams. Prior to 1.69.1, checkApiAuth() in src/main/java/com/erudika/scoold/utils/ScooldUtils.java accepts a JWT signed with app_secret_key or para_secret_key for /api/config and /api/stats without requiring a registered API-key jti, and maps the request to the hardcoded administrative API_USER. The special endpoint checks run even when scoold.api_enabled is false. An attacker who obtains either signing secret can forge a token that reads sensitive configuration and server logs and reaches privileged configuration functionality, while an ordinary login-session token is not sufficient. This issue is fixed in version 1.69.1.4h CVE-2026-102631—

—

———In authd before 0.7.1, the user identity matching in UpdateUser (internal/users/manager.go) resolves an incoming login by the broker-scoped provider ID, but falls back to matching the username when the provider ID does not belong to any known user, and does not reject a conflicting non-empty provider ID. If an identity provider reassigns an email address, which authd uses as the username, to a new account, the new account inherits the previous user's local UID and home directory on its next login. This allows the new user to access and modify files belonging to the previous user, including credentials such as SSH keys and cloud API tokens, and silently rebinds the local account record to the new identity. As a mitigation, administrators should lock or delete the previous user's local authd account when the corresponding IdP account is removed.6h CVE-2026-454518.3 HIG

—

———: Improper Authentication vulnerability in Unitronics Unitronics UniStream Pro/UniLogic. This issue affects Unitronics UniStream Pro/UniLogic: Unitronics UniStream Pro versions only (B10 / C10) – UniLogic versions prior to 1.41.329.4h CVE-2026-1108647.4 HIG

—

——0Better Auth from 1.5.0-beta.12 before 1.7.7 contains an authentication bypass vulnerability in the OAuth Proxy plugin that allows unauthenticated attackers to sign in as other users by forging encrypted profiles. When the proxy shares the global secret and cookie-stored state is used, attackers can obtain encrypted state for a fake profile with a victim's verified email to take over the account via implicit linking.7h CVE-2026-1108638.1 HIG

—

——0Better Auth @better-auth/sso from 1.7.0-rc.2 before 1.7.3 contains an authentication bypass vulnerability that allows authenticated users to sign in as other users by registering a personal SSO provider. Attackers can copy a legitimate provider's OIDC issuer or SAML entity ID and assert a victim's subject or NameID, because account lookup ignores providerId, creating sessions for victim accounts.1d CVE-2026-1108629.1 CRI

—

——0Better Auth from 1.4.0-beta.18 before 1.7.7 contains an authentication bypass vulnerability that allows unauthenticated attackers to sign in as other users by reusing OAuth state values as Magic Link tokens. Attackers can start an OAuth sign-in with a victim's email and submit the returned state to Magic Link verification, gaining sessions or creating falsely email-verified accounts.9h