Volexity Details a SonicWall Zero-Day Chain That Handed Attackers Root Access
A threat actor chained two SonicWall SMA zero-days for weeks before a patch existed, using custom malware to reach root on VPN appliances and capture credentials.
A threat actor had root-level access to SonicWall VPN appliances for more than three weeks before a patch existed. Incident response firm Volexity says the group, which it tracks as UTA0533, chained two zero-day vulnerabilities in SonicWall Secure Mobile Access (SMA) 1000 series appliances to bypass authentication, plant custom malware, and quietly capture network credentials, starting June 22, 2026.
Table Of Content
SonicWall published its advisory and hotfix for the flaws, tracked as CVE-2026-15409 and CVE-2026-15410, on July 14. Volexity, which assisted the investigation, published its full technical writeup three days later. The Cybersecurity and Infrastructure Security Agency has since added both CVEs to its Known Exploited Vulnerabilities catalog, giving federal civilian agencies until July 17, just three days, to remediate under Binding Operational Directive 26-04.
How an anonymous connection became a root shell
Volexity’s investigation began in early July, when it was called in to examine two compromised SonicWall SMA appliances. The affected line is the SMA 1000 series, which SonicWall’s own advisory lists as covering the 6210, 7210, and 8200v models plus the CMS management console, across all supported hypervisors. Analysts started with exported logs, then obtained SSH access to the devices and collected system memory and disk images for deeper forensic analysis.
The entry point was CVE-2026-15409, a server-side request forgery flaw that SonicWall itself rates CVSS 10.0, the maximum possible severity score. By sending a request with a specific User-Agent string and a crafted bmID parameter to the appliance’s wsproxy endpoint, as The Hacker News detailed in its technical breakdown, an unauthenticated attacker could open a WebSocket tunnel to services that are only supposed to be reachable from inside the appliance, including a local CouchDB instance and the device’s control service. Volexity found evidence the attacker used that CouchDB access, running as the low-privileged couchdb account, to read the file that stores the appliance’s hardware UUID, a value the control service also uses to derive its own administrative login password.
With that password derivable, the attacker could authenticate to the control service and reach its execRemoveHotfix function, which is meant to remove hotfix packages. CVE-2026-15410, a path traversal flaw in that same function (CVSS 7.2), let the attacker point it at an arbitrary file instead and execute it with root privileges. Chained together, the two bugs turned an anonymous network connection into full root access, with no valid credentials or prior foothold required.
ROOTRUN, KNUCKLEBALL, and a webshell hiding inside a legitimate process
Volexity’s timeline shows the attacker moving fast. On June 22, the first day of observed compromise, they wrote a setuid binary disguised as /usr/bin/xzfind, a tool Volexity calls ROOTRUN, that let any unprivileged user run commands as root from then on. Minutes later, a Python script landed at /usr/lib/python3.11/site-packages/deploy_new.py. Volexity calls this one KNUCKLEBALL: it carries two embedded Java archives that get injected directly into a legitimate SonicWall process rather than running as their own standalone program, which makes them harder to spot in a routine process listing.
The two injected tools were Suo5, an open-source HTTP proxy-forwarding tool, and a custom, Behinder-style webshell Volexity named ORANGETAIL. Once loaded, both were reachable over the internet through two URL paths on the appliance, /workplace/error.jsp and /workplace/dialogs/errorDialog.jsp, gated behind a specific User-Agent string so casual scanning would not stumble onto them. The attacker made the access durable by editing the legitimate /etc/init.d/workplace startup script to relaunch KNUCKLEBALL on every boot, and by rewriting the appliance’s NGINX Unit configuration so that requests to two ordinary-looking paths, /__api__/login and /__api__/logout, were silently redirected to those hidden tools instead of the appliance’s real login and logout handlers.
On July 2, the second compromised appliance was rebooted, which Volexity believes cleared its memory-resident backdoors: a reminder that a routine reboot can also destroy the evidence needed to confirm how deep an intrusion went. Files created that same day on the same device included a script that launched tcpdump to capture unencrypted LDAP traffic, the kind of traffic that carries directory usernames and passwords in the clear.
An unidentified actor with a narrow, disciplined foothold
Volexity has not linked UTA0533 to any previously known group, and the victim organization has not been named. SecurityWeek, citing Volexity’s account of the intrusion, characterized the tradecraft, custom-built appliance malware, careful cleanup, and no obvious profit motive, as more consistent with state-sponsored espionage than a profit-driven cybercrime operation. With root access, Volexity said, the attacker “could access stored or cached credentials, capture network traffic, and potentially intercept credentials processed by the appliances.” Despite that level of access, the firm found no evidence UTA0533 successfully pivoted from the SonicWall appliances into the rest of the victim’s network, noting the actor was “less successful moving laterally or gaining access to other systems.”
What SonicWall SMA administrators should do now
SonicWall’s hotfix ships in firmware versions 12.4.3-03453 and 12.5.0-02835; administrators running SMA 1000 series appliances or the CMS console on an earlier build are still exposed and should apply the update through SonicWall’s management console right away. Because the flaws allowed root-level compromise, patching alone does not undo an existing infection. Volexity’s report includes file paths, log signatures, and network indicators, including the distinctive bmID=-3389 pattern in wsproxy requests, that administrators can check against their own appliance logs before assuming a device is clean.
Given that UTA0533 was caught sniffing LDAP traffic on at least one appliance, organizations that find any of Volexity’s indicators on their own devices should treat directory credentials that transited the appliance as compromised and rotate them, not just apply the patch and move on.








No Comment! Be the first one.