Critical Vulnerability Roundup: SonicWall, Dropbox, JFrog, and Redis

Two SonicWall SMA1000 0-Days Are Being Exploited Right Now

SonicWall has confirmed active exploitation of two chainable vulnerabilities in its SMA1000 secure remote access appliances, and hundreds of internet-exposed devices are still out there.

What You Need to Know

SonicWall is warning customers that threat actors are actively exploiting two 0-day vulnerabilities, CVE-2026-83548 and CVE-2026-83549, in SMA1000 secure remote access appliances. Chained together, the flaws enable remote code execution on vulnerable devices, putting any organization that relies on SMA1000 for remote administration or VPN access at serious risk. SonicWall has released hotfixes, but more than 400 SMA1000 devices remain externally accessible on the internet right now.

What's Vulnerable

CVE-2026-83548 is a maximum-severity command injection vulnerability in the SMA1000 Appliance WorkPlace interface, rooted in a server-side request forgery weakness that gives attackers a path toward arbitrary command execution. CVE-2026-83549 is a separate command injection flaw in the Appliance Management Console; an attacker who already has administrative access can use it to execute operating-system commands directly on the device. SonicWall has found evidence of active exploitation and released hotfix versions for the affected SMA1000 6210, 7210, and 8200v models. SonicWall SSL-VPN services running on firewalls and the SMA 100 Series appliances are not affected.

This isn't the first time SMA1000 devices have been targeted. Earlier in 2026, attackers exploited CVE-2026-15409 and CVE-2026-15410 to deploy custom malware on vulnerable appliances, and ransomware operators later abused those same flaws.

Why This Matters

Remote access appliances sit at the front door of a network, often providing a direct line to internal systems, privileged accounts, and sensitive enterprise resources. That makes them high-value targets, and the fact that more than 400 SMA1000 devices are still externally reachable means patch status alone can't be verified from outside; each one needs to be checked directly. Given the repeat targeting of this same product line, this looks less like a one-off incident and more like a pattern attackers keep coming back to.

What to Do

Organizations running SMA1000 infrastructure should prioritize identifying exposed appliances and applying the applicable hotfix immediately. Security teams should also review available logs for unexpected administrator activity, unusual management-console access, suspicious command execution, or unexplained configuration changes. If any compromise indicators turn up, SonicWall recommends re-imaging the appliance, resetting user and administrator credentials, and resetting time-based one-time password tokens. More broadly, treat internet-facing remote access systems as priority assets in vulnerability-management and attack-surface-management programs, with strong asset inventory, rapid patch deployment, MFA enforcement, credential monitoring, and centralized logging.

Edge appliances like these are only as safe as the last patch applied to them, and this is the second time this year SMA1000 has proven that.

Dropbox Accounts Compromised Through a Lenovo Identity Flaw

A weakness in Lenovo's email verification process let an attacker walk into roughly 5,000 Dropbox accounts without ever touching a Dropbox password.

What You Need to Know

Dropbox has disclosed that an unauthorized party accessed customer accounts by abusing a flaw in Lenovo's email-verification process, not by stealing Dropbox passwords or running a credential-stuffing attack. Attackers registered fraudulent Lenovo IDs using victims' email addresses, then used those identities to log into the matching Dropbox accounts through a legacy Lenovo identity integration. The activity took place between August 4 and August 21, and reporting indicates roughly 5,000 Dropbox accounts may have been accessed, with files viewed or downloaded from some of them.

What Happened

Dropbox trusted Lenovo's assertion that a user controlled a given email address, then linked that identity to an existing Dropbox account without requiring the user's Dropbox password or any confirmation through the account's established authentication method. That meant anyone who could successfully register a Lenovo ID with a victim's email address could gain access to the associated Dropbox account. Some affected users reported suspicious login notifications and noticed Dropbox presenting a "Continue with SSO" option even though they had never created or used a Lenovo ID. Dropbox has since expired sessions authenticated through Lenovo IDs and now requires users to enter their Dropbox password when signing in that way. Lenovo, for its part, characterized this as an issue with a legacy Lenovo ID and Dropbox integration and said Lenovo customers were not affected.

Why This Matters

This is a clean example of a risk that's easy to overlook in federated identity and single sign-on setups: an application can inherit the security failures of an external identity provider it trusts. Dropbox didn't have to be breached directly for its customers to be exposed, it just had to trust an identity assertion that turned out to be forgeable. Any organization relying on third-party identity providers or legacy SSO integrations has the same exposure sitting somewhere in its stack.

What to Do

Identity teams should review trust relationships across identity providers, SaaS applications, and legacy authentication integrations, and make sure account linking requires strong, user-controlled verification such as password reauthentication, MFA, or confirmation through an already trusted session. It's also worth inventorying unused SSO connections, monitoring for new or unexpected identity-provider associations, and alerting on logins from previously unseen authentication methods. Affected Dropbox users should review account activity, revoke unfamiliar sessions, reset passwords, and confirm MFA enrollment.

Microsoft Defender Is Flagging Google Search Links as Malicious

A misclassification bug in Defender for Office 365 Safe Links is triggering false "unsafe website" warnings on ordinary Google search links, and Microsoft is still working on a fix.

What You Need to Know

Microsoft is investigating an issue where Defender for Office 365 Safe Links is incorrectly flagging legitimate Google search URLs as malicious. Affected users see an "Opening this website might not be safe" warning when clicking Google search links, and security teams may see matching alerts and incidents pile up in the Microsoft Defender portal and Microsoft Sentinel. Microsoft is tracking the issue as incident MO1465962 and attributes it to an inaccurate security classification, not a real threat.

What Happened

Safe Links works by rewriting URLs in email and Microsoft 365 apps, then re-evaluating them at the moment a user clicks, a time-of-click check meant to catch links that turn malicious after a message is delivered. That same design means a bad classification decision can block access to legitimate resources at scale, which is what's happening here. Users can't work around the warning by copying the affected Google URL and pasting it directly into a browser, which is likely to drive up help-desk tickets and push some users toward less secure workarounds. Microsoft has categorized the incident as an advisory, generally indicating limited scope or impact, and is working to correct the classification causing the false positives.

Why This Matters

The core challenge this exposes isn't the bug itself, it's that prevention controls like Safe Links need continuous tuning and clear exception handling, because a sudden spike in detections on a well-known domain like Google can just as easily be a vendor-side false positive as a real campaign. Treating every alert as genuine, or conversely dismissing this whole category of warning as noise, both lead to bad outcomes.

What to Do

Until Microsoft ships a fix, administrators should distinguish this issue from genuine malicious-link activity before taking broad response actions. Correlate alerts with the affected URL pattern, confirm whether blocked destinations are standard Google search URLs, and document confirmed false positives rather than escalating them as incidents. Avoid overcorrecting by broadly disabling Safe Links or creating overly permissive URL allow rules, since either move weakens protection against real phishing. Make sure Defender alerts feed into triage workflows that account for vendor-reported service incidents, and communicate clearly with employees that the warnings are under investigation so they aren't ignored wholesale. Once Microsoft deploys a fix, review generated alerts, close out confirmed false positives, and roll back any temporary rules or user guidance put in place in the meantime.

Redis Patches a TLS Use-After-Free Bug It Initially Rated as Critical RCE

Redis has shipped fixes for a use-after-free vulnerability in TLS pending-data processing, and while the severity turned out lower than first reported, the fix still shouldn't wait.

What You Need to Know

Redis has released security updates for CVE-2026-81934, a use-after-free vulnerability affecting TLS pending-data processing in Redis deployments configured with TLS support. Early reporting called it a critical, unauthenticated remote code execution flaw with a public proof-of-concept available. Redis has since revised that assessment, rating the vulnerability High with a CVSS v4.0 score of 7.5 after determining that exploitation actually requires authenticated access, broad permissions, coordinated TLS sessions, precise runtime conditions, and target-specific adaptation. Redis says it is not aware of any active exploitation in customer environments as of August 27.

The Details

The vulnerability lives in the tlsProcessPendingData() function, which handles the TLS pending-data list. Under specific conditions, an authenticated attacker can trigger the use-after-free condition and execute code in the context of the Redis server process, potentially enabling unauthorized command execution, data access or manipulation, service disruption, and a foothold for further activity in the hosting environment.

Redis Open Source users should upgrade to 8.10.1, 8.8.2, 8.6.6, 8.4.6, 8.2.9, 7.4.11, 7.2.16, or 6.2.24. Fixed Redis Software builds include 8.2.0-46, 8.0.20-96, 7.22.2-179, and 7.8.6-303. Redis Cloud Essentials subscriptions are already patched; remediation for Redis Cloud Pro subscriptions is underway.

Why This Matters

The gap between the initial "critical unauthenticated RCE" headline and Redis's revised "High, authentication-required" assessment matters for prioritization, but it shouldn't matter for urgency. Any Redis instance accessible to untrusted clients, or any environment where an attacker has already obtained credentials with excessive permissions, is still looking at a real path to code execution on the server. Compromised credentials are common enough that "requires authentication" is a much smaller bar than it sounds.

What to Do

Identify TLS-enabled Redis instances, confirm the deployed version, and prioritize patching anything internet-exposed or reachable from lower-trust network segments. Redis should not be exposed directly to the internet in the first place. Until updates are applied, restrict access to trusted clients, enforce strong authentication, review Redis ACLs for least privilege, and pull back unnecessary permissions for higher-risk functionality like CLIENT KILL, Lua scripting, Pub/Sub, and related keys or channels. Watch for unexpected TLS connection behavior, unusual Redis commands, abnormal process restarts, and unexplained changes to ACLs or configuration files.

Critical JFrog Artifactory Auth Bypass Is Already Being Exploited

A 9.8-severity authentication bypass in self-hosted JFrog Artifactory is letting attackers generate administrative tokens without ever logging in, and exploitation is already underway.

What You Need to Know

JFrog has disclosed CVE-2026-82329, a critical improper-authentication vulnerability in self-hosted Artifactory deployments, carrying a CVSS v3.1 score of 9.8. Under default configurations, an unauthenticated attacker with network access can obtain administrative privileges, no prior access, user interaction, or elevated permissions required. JFrog released fixes on August 28, 2026, and exposure-management firm watchTowr reports that attackers have already exploited vulnerable instances to generate administrative tokens.

What's Vulnerable

Artifactory commonly serves as the central repository for software packages, container images, build dependencies, and release artifacts, which is what makes administrative compromise so serious. An attacker with admin access could create or modify users and tokens, change repository settings, access proprietary packages, manipulate build inputs, or insert malicious artifacts directly into the software delivery pipeline. JFrog has clarified that the flaw is an authentication weakness rather than remote code execution, and that it affects self-hosted deployments only, not the JFrog SaaS platform. Cloud customers do not need to take action, since JFrog has already applied protections to affected vendor-managed environments. JFrog had not independently confirmed watchTowr's exploitation reports at the time of disclosure, but the combination of a public PoC and reports of administrative-token creation makes opportunistic exploitation against internet-facing targets increasingly likely.

Why This Matters

This goes beyond an infrastructure-management problem. A compromised Artifactory instance touches the confidentiality of source-adjacent materials, the integrity of CI/CD workflows, and the security of every downstream application that pulls artifacts from the repository. Any self-hosted instance that was internet-accessible while vulnerable should be treated as potentially compromised, especially where it supports production build or release workflows.

What to Do

Identify all self-hosted Artifactory deployments, restrict network access to trusted administrative and build systems, and upgrade to the fixed release for your branch: 7.111.21, 7.117.28, 7.125.20, 7.133.29, 7.146.38, or 7.161.20. After patching, review audit logs for unexpected administrative authentication events, newly generated access tokens, unfamiliar users, configuration changes, repository permission updates, and abnormal artifact uploads or downloads. Where exposure or suspicious activity turns up, rotate credentials, access tokens, API keys, and secrets used by connected CI/CD systems.