On 6 October SonicWall published advisory SNWLID-2026-0017, covering four vulnerabilities in its SMA1000 series of remote-access appliances. The one that matters is CVE-2026-102255, a pre-authentication server-side request forgery in the appliance's WorkPlace interface, scored CVSS 10.0. SonicWall's wording is that the flaw exists due to an unintended alternate access path, and that by abusing it a remote unauthenticated attacker could potentially exploit this vulnerability to direct the appliance to issue requests on their behalf and reach internal functionality and perform unauthorized operations. The advisory said there was no evidence of exploitation in the wild. There was no workaround. The fix is a platform hotfix: 12.4.3-03670 or 12.5.0-03082, depending on which branch you run.
Three days later, on 9 October, BleepingComputer reported that Ryan Dewhurst, founder of Previdian, had seen his company's honeypot network receive requests that, in BleepingComputer's words, were consistent with the CVE-2026-102255 flaw. The requests were crafted OPTIONS calls to the WorkPlace Extraweb interface that tried to reach the appliance's internal CouchDB service on 127.0.0.1:5984, traverse into a CouchDB design document, invoke its _rewrite function, and authenticate with an HTTP Basic Authorization header carrying the credentials admin:admin. Previdian has not established whether any real appliance was compromised; its position is that the activity is consistent with active exploitation attempts. Shadowserver counts more than 400 SMA1000 appliances reachable from the internet, with no way of knowing from the outside how many are honeypots and how many have already taken the hotfix.
If that description sounds familiar, it should. It is the third unauthenticated SSRF in the same WorkPlace interface that SonicWall has patched since July, the previous two were exploited as zero-days before the patch existed, and the September one carries exactly the same title as this one. Most of what follows is about why that is, what the chain actually does, and then, at some length, what the people I spend my time trying to protect should do about it. For most of them the answer begins with a sentence that will come as a relief: this is not your firewall.
What an SMA1000 is, and who runs one
SonicWall sells three things that get called the SonicWall VPN, and they are different products with different code and, as this year has shown, different problems.
The first is the SSL-VPN built into SonicOS, the operating system on the TZ and NSa firewalls. That is what nearly every small and medium-sized business with a SonicWall actually has: a TZ 270 or TZ 370 or NSa 2700 doing the routing, the firewalling and the remote access from one box. The second is the SMA 100 series, a small, cheap dedicated remote-access appliance for a few dozen to a few hundred users. The third is the SMA1000 series, the 6210, 7210 and virtual 8200v, a very different beast descended from the Aventail secure-access gateways SonicWall acquired in 2007. The Aventail name is still all over the filesystem: the logs live in /var/log/aventail/, the Java classes under com.aventail. It is an enterprise product, sold to organisations with thousands of remote users, and to managed service providers who use one gateway to reach into many customers. It has a user-facing portal, WorkPlace, and a separate Appliance Management Console, AMC, for administrators.
SonicWall's advisory is explicit on the point, and I will quote it because it is the single most useful sentence in it for a small business: These vulnerabilities do not affect SSL-VPN running on SonicWall firewalls or the SMA 100 Series product line. If you have a TZ or an NSa, CVE-2026-102255 is not a hole in your box. If you have an SMA 100, likewise. The reason the story still matters to you comes later, and it has two parts: the MSP that looks after you may well use an SMA1000 to get into your network, and the firewall you do have has had a year of its own that most of its owners have not fully reckoned with.
How the flaw works
Server-side request forgery is one of the less dramatic names in the vulnerability catalogue, and for most web applications it is a medium-severity annoyance. On a remote-access appliance it is a different thing, because the whole purpose of the device is to be a trusted proxy between the outside world and an inside one, and because the appliance itself is a small Linux server running a collection of internal services that were never meant to be reached from anywhere but localhost.
What SonicWall calls an unintended forward-proxy or unintended alternate access path is, stripped of euphemism, a way of asking the WorkPlace web front end to fetch a URL on your behalf without first logging in, and having it fetch URLs on the appliance's own loopback interface. The July variant, CVE-2026-15409, did this through the /wsproxy endpoint: a request with the User-Agent SMA Connect Agent and a bmID parameter beginning with -3389 would be answered with a WebSocket upgrade, status 101, with no session cookie required, and the attacker then had a tunnel to whatever port they named. The October variant, on the evidence of the honeypot traffic, uses an OPTIONS request against the Extraweb component to reach the same place by a different route. SonicWall has not published the mechanism, and I would not expect it to.
The place both routes lead is CouchDB, the Apache database the appliance runs internally. Volexity's July investigation found that the shipped database came with hardcoded admin:admin credentials, although it was careful to say that the exact operation the July attacker performed against CouchDB remains unknown to it. The October honeypot payload, which carries admin:admin in its Authorization header, is the strongest public evidence that the default credential is part of the chain, and I treat it as such in what follows. If so, it is the detail that turns a request-forgery bug into a full compromise. An SSRF that could only reach a service demanding a strong, per-device secret would be a foothold and nothing more. An SSRF that reaches a database whose administrator password is the same on every appliance ever shipped is an administrator session on the appliance, delivered to anyone who can find the path. The October payload's use of a design document's _rewrite function is the CouchDB-specific part: design documents are where CouchDB stores application logic, and _rewrite lets a request be redirected to other database endpoints according to rules the document defines. With admin rights, you can write the rules. What an attacker does from there depends on what else is unpatched, and in July we got to watch.
Volexity's account of the June and July intrusions, which it attributes to a group it tracks as UTA0533 and has not linked to any known actor or country, is the clearest public description of an SMA1000 being taken apart. The SSRF through /wsproxy gave the attacker loopback access to CouchDB's Erlang distribution port, 1050, the Erlang port mapper on 1051, and the appliance's own control service on 8188, an XML-RPC interface protected by Basic authentication whose password is derived from the hardware UUID, a value that is world-readable on the box and, Volexity notes, a default that ships with various hardware providers. The October traffic, by contrast, aims at 5984, CouchDB's ordinary HTTP API, so the two routes reach the same service through different doors. In July, a script called 1234.sh appeared in /tmp, owned by the couchdb user. Then it called the control service's sysCtrl.execRemoveHotfix method, which runs /usr/local/bin/remove_hotfix with a rollback path built from the caller's input. The input was not confined to the rollback directory, so ../../../../../tmp/1234.sh resolved, and the script ran as root. That was CVE-2026-15410, the second half of the July pair.
With root, UTA0533 installed a setuid helper at /usr/bin/xzfind that calls itself rootrun, a Python loader Volexity named KNUCKLEBALL that used the Java Attach API to inject two agents into the running WorkPlace JVM, and the two agents themselves: a modified build of the open-source Suo5 HTTP proxy, and a Behinder-style web shell Volexity named ORANGETAIL. The nginx Unit configuration at /var/lib/unit/conf.json was edited to add routes for /__api__/login and /__api__/logout, paths that do not exist on a clean appliance, so that the implants could be reached from outside. Persistence went into /etc/init.d/workplace. The attacker also ran tcpdump on the appliance to capture unencrypted LDAP authentication traffic and pull usernames and passwords out of it, and Volexity observed authentication attempts from the appliance to various systems on the internal network. Volexity's assessment is that the threat actor was less successful moving laterally or gaining access to other systems, which is a sentence that should be read as describing one incident rather than a limit on the technique. The activity came from more than 200 IP addresses, several of them ExpressVPN and Mullvad exits. The earliest artefact on the compromised appliances was dated 22 June; SonicWall's advisory came out on 14 July.
That is the model to hold in your head for the October flaw. The SSRF is the front door. CouchDB's default password is the key left in it. Whatever post-authentication bug is still present is the staircase to root. SNWLID-2026-0017 fixes three of those staircases at once: CVE-2026-102256, a post-authentication OS command injection scored 7.8; CVE-2026-102257, a Zip Slip path traversal in the AMC's archive handling that leads to code execution, scored 7.2; and CVE-2026-102258, a stored cross-site scripting bug in the AMC scored 5.5. None of them is interesting on its own. Chained behind an unauthenticated SSRF with a known database password, each of them is.
The timeline
Dates are from the SonicWall advisories, the CVE records, the CISA catalogue feed and Volexity's report. Times, where published, are UTC.
24 January 2025. CISA adds CVE-2025-23006, a pre-authentication deserialisation flaw in the SMA1000's management consoles exploited as a zero-day, to the Known Exploited Vulnerabilities catalogue. The SMA1000's run of trouble begins here.
17 December 2025. CISA adds CVE-2025-40602, an SMA1000 privilege-escalation flaw, following SonicWall's warning that it was being chained with CVE-2025-23006 for root in zero-day attacks.
22 June 2026. Earliest sign of compromise on the appliances Volexity later examines. The xzfind setuid binary is written, and KNUCKLEBALL follows a few minutes later.
28 to 30 June 2026. Logged /wsproxy requests to ports 1050 and 8188. The control-service log records a hotfix removal with a path-traversal name. 1234.sh appears in /tmp, owned by the couchdb user.
Early July 2026. Volexity is engaged for incident response.
14 July 2026. SonicWall publishes SNWLID-2026-0008: CVE-2026-15409, SSRF, CVSS 10.0, and CVE-2026-15410, post-authentication code injection, CVSS 7.2. Discovered internally by Adam Babis of SonicWall PSIRT; Volexity credited for an additional indicator. The advisory states that PSIRT has investigated multiple cases indicating the active exploitation of the vulnerabilities. Fixed in 12.4.3-03453 and 12.5.0-02835. CISA adds both CVEs to the KEV catalogue the same day with a three-day deadline, 17 July. Both are later flagged as known to be used in ransomware campaigns; BleepingComputer reports that Resecurity has tied attacks to an INC Ransomware affiliate.
17 July 2026. Volexity publishes its report on UTA0533, with YARA rules and indicators.
1 September 2026. SonicWall publishes SNWLID-2026-0016: CVE-2026-83548, Pre-authentication SSRF via unintended forward-proxy, CVSS 10.0, and CVE-2026-83549, post-authentication OS command injection, CVSS 7.8. Discovered internally by William Perry and Adam Babis. The advisory says PSIRT has investigated a case indicating the active exploitation of the vulnerabilities. Affected: every build up to and including the July fixes. Fixed in 12.4.3-03526 and 12.5.0-02952.
2 September 2026. CISA adds CVE-2026-83548 and CVE-2026-83549 to the KEV catalogue, deadline 5 September.
28 September 2026. CVE-2026-102255 is reserved.
6 October 2026. SonicWall publishes SNWLID-2026-0017. CVE-2026-102255, again Pre-authentication SSRF via unintended forward-proxy, again CVSS 10.0, is credited to Benoît Sevens of Anthropic, as is CVE-2026-102256. CVE-2026-102257 is credited to Brian Mariani through Trend Micro's Zero Day Initiative and CVE-2026-102258 to Brian Mariani of DigitalCanion SA. Affected: every build up to and including the September fixes. Fixed in 12.4.3-03670 and 12.5.0-03082. The advisory states there is currently no evidence any of the vulnerabilities addressed in this release are being exploited in the wild.
7 October 2026. The CVE record is published at 13:07 UTC. Shadowserver's count of exposed SMA1000 appliances stands above 400.
9 October 2026. Previdian reports honeypot traffic consistent with exploitation of CVE-2026-102255. As of the CISA catalogue release of 8 October, the CVE is not yet listed in KEV.
Three observations about that sequence. First, the gap between patch and probing has collapsed: weeks of silent zero-day use in June, a patched flaw being exploited by the time of the advisory in September, and in October an advisory on Tuesday and honeypot hits by Friday. Second, the affected-version range in each advisory begins exactly where the previous fix ended. Every appliance that did the right thing on 14 July was vulnerable again on 1 September, and every appliance that did the right thing on 1 September was vulnerable again on 6 October. Third, the September and October SSRFs carry an identical title and near-identical descriptions. SonicWall has not said whether the October flaw is a sibling path the September fix did not cover or a separate bug in the same component, and I will not guess. What can be said is that a third way through the same door was reported, and its CVE reserved, within four weeks of the second being closed, and the people probing honeypots found it within three days of being told it existed. Whatever is left in that interface is being looked at very hard by people on both sides.
For the record, CISA's catalogue now holds nineteen SonicWall entries, thirteen of them flagged as used in ransomware campaigns. Six of the nineteen are SMA1000 flaws, five of them added since December 2025.
If you run an SMA1000
Everything in this section applies to the organisation that owns the appliance, which in the small-business world is more often the managed service provider than the client. If you are the client, the section after this one tells you what to ask.
Patch first and investigate second, and do both this week rather than at the next change window. The fixed builds are 12.4.3-03670 and 12.5.0-03082, from mysonicwall.com. There is no workaround, and SonicWall says so in the advisory in a single word. The patch closes the SSRF and the three post-authentication bugs together, which is the point: you want the staircases gone as well as the door.
Then assume the question is not whether anyone tried but whether anyone succeeded, and look. The September advisory's recommended action was to contact SonicWall support for help reviewing the system for indicators of compromise, and that remains sensible, but the July advisory and Volexity's report between them give you enough to start on your own. In /var/log/aventail/extraweb_access.log, look for OPTIONS requests against the WorkPlace interface from addresses you do not recognise, for /wsproxy requests with a bmID beginning -3389 and a 101 response, and for any request at all to /__api__/login or /__api__/logout returning 200. Note the client addresses in access_servers.log WebSocket connection requests and check them against the same list. In ctrl-service.log, look for hotfix-removal entries containing ../. Read /var/lib/unit/conf.json and confirm there are no routes proxying to 127.0.0.1:8085. Check /tmp and /var/tmp for anything you did not put there, 1234.sh and hypdate.b64 in particular; the agent JARs, agent_wp8.jar and agent_wp9.jar, were only staged there briefly during injection, so their absence proves little. Run find / -perm -4000 and compare the result to Volexity's published baseline; /usr/bin/xzfind should not exist. Read /etc/init.d/workplace and make sure nothing has been appended. Volexity's YARA rules are on its GitHub and will catch the July implants if they are present.
If you find anything, the advice from SonicWall is unambiguous and I agree with it: re-image a hardware appliance or redeploy a virtual one from a clean image, do not try to clean it in place, change all user and administrator passwords, and reset every TOTP token. Then treat the appliance's position in the network as the scope of the incident rather than the appliance itself. The July attacker, once it had root, captured LDAP traffic for credentials and attempted authentication from the appliance to other systems on the inside. If your appliance authenticates against a directory, assume the directory passwords that transited it during the exposure window are known, and that any service accounts bound into it are known too.
Two structural changes are worth making whether or not you find anything. The first is to reconsider how much of the WorkPlace interface needs to face the whole internet. An SMA1000 exists to be reached from outside, so it cannot simply be hidden, but geographic restriction, allow-listing where the user population permits it, and placing the AMC on a management network reachable only over a separate path all shrink the surface that the next unintended access path will expose. The second is logging. Every indicator above lives in a log on the appliance, and the appliance is the thing the attacker controls. Ship those logs somewhere else, in near real time, so that the record of what happened survives the compromise of the device that recorded it. That is a ten-minute syslog configuration and it is the difference between an investigation and a guess.
Finally, CISA's required action for the July and September CVEs under Binding Operational Directive 26-04 came with forensic triage requirements for federal agencies alongside the instruction to remediate. Nobody in the UK private sector is bound by that, but the instinct behind it is right. Where a flaw is known to have been exploited, patching without looking means you have closed the door behind someone who may already be inside.
If you run a TZ or an NSa, which is most of you
This flaw is not in your firewall. Say that to yourself, say it to the board, and then do not stop reading, because the SonicWall appliance that most small businesses do own has had a year that deserves a review of its own, and the review has three parts.
The first is the question of who reaches into your network and with what. If an MSP manages your estate, there is a reasonable chance it does so through a remote-access gateway of its own, and a reasonable chance that gateway is an SMA1000, because that is what the product is for. You are entitled to ask, in writing, which product they use, which build it is on today, and when it was patched for SNWLID-2026-0017, 0016 and 0008. You are entitled to ask whether they checked it for the indicators above after each of the three advisories and what they found. If the answer to the first question is an SMA1000 and the answer to the last is a blank look, that is information. I wrote last month about a company that had a supplier's written assurance of deletion and was wrong to believe it; a supplier's verbal assurance of patching is worth rather less than that. Ask for the build number.
The second part is your firewall's own recent history, which is a separate story from the SMA1000 but shares a theme. On 17 September 2025 SonicWall disclosed that firewall configuration backup files stored in MySonicWall cloud accounts had been accessed by an unauthorised party. On 8 October 2025 it widened that to every customer who had used the cloud backup feature, and on 5 November, after an investigation by Mandiant, it attributed the access to a state-sponsored actor who had pulled the files from a specific cloud environment through an API call. A firewall configuration backup contains the device's local user credentials, its LDAP or RADIUS bind passwords, its IPsec pre-shared keys and its WAN interface credentials. SonicWall's position is that those secrets are individually encrypted within the file; its reset guidance is nonetheless the right reading of what a capable actor can do with a copy. SonicWall's guidance was to reset all of them: MySonicWall account credentials and temporary access codes, LDAP, RADIUS and TACACS+ server passwords, L2TP, PPPoE and PPTP WAN passwords, and the shared secrets in every IPsec site-to-site and GroupVPN policy. A year on, I still meet firewalls whose owners used cloud backup and did none of that, usually because the email went to an address nobody reads. If you have a MySonicWall account and ever turned cloud backup on, that reset list is still your to-do list.
Separately, and SonicWall is clear that the two are unrelated, Akira ransomware affiliates spent the second half of 2025 walking in through SonicWall SSL-VPN logins. SonicWall's analysis was that this was not a new vulnerability but the long tail of CVE-2024-40766, the SonicOS access-control flaw it fixed in August 2024, combined with a migration habit: organisations moving from Gen 6 to Gen 7 firewalls had carried their local user accounts across, passwords and all, and never reset them. Rapid7 added that attackers were using the Virtual Office portal, the self-service web page the SSL-VPN exposes, to enrol their own TOTP tokens against stolen credentials, and SonicWall and Rapid7 both warned that the default SSLVPN user group could grant access to directory users it was never meant to include. The practical consequences for a small business are short and unglamorous. Be on current SonicOS firmware. Reset every local user account that predates your current hardware. Turn on multi-factor authentication for every SSL-VPN user, and do it through the directory rather than letting users self-enrol through a portal the internet can see. Restrict the Virtual Office portal if you do not use it. Review the SSLVPN default group and make sure it contains the people who need remote access and nobody else. Enable botnet filtering and, if your users are all in one country, geographic restriction on the SSL-VPN service. Each of those is an afternoon's work for whoever looks after the box, and together they close the route Akira actually used.
The third part is the one that outlasts any particular CVE. Know what you have. I mean that literally: the model, the generation, the firmware build, whether SSL-VPN is enabled, which users can use it, whether cloud backup was ever switched on, who holds the MySonicWall login, and where the logs go. A remarkable number of the firewalls I see were installed by a contractor who has since moved on, running firmware from the year they were racked, with an SSL-VPN enabled for a remote worker who left in 2023. The box is doing its job. Nobody is doing theirs. Write the answers down on one page, date it, and look at it again when the next SonicWall advisory arrives, because the only certain thing about this year is that there will be a next one.
For boards
Three questions, none of which requires a technical answer.
Who can reach into our network from outside, through what, and when was it last patched? The honest answer for many small businesses is a managed service provider, through an appliance the business has never heard of. That is a legitimate arrangement. It is not a legitimate arrangement to be unable to answer the question.
Did we ever use SonicWall's cloud backup, and if so, has every credential in that backup been changed? The breach was a year ago and the reset list is public. If nobody can say yes, the answer is no.
If our firewall vendor publishes a critical advisory on a Tuesday, who in our organisation or our supplier's reads it, and by when is the fix applied? In July the attackers had been inside SMA1000 appliances for three weeks before the advisory. In October they were probing for the new flaw three days after it. The window between advisory and exploitation is now shorter than most small-business change processes, and the process has to be shortened to match.
The closing observation
There is a temptation, after a run like this, to conclude that SonicWall is uniquely bad and to recommend that everyone buy something else. I do not think the evidence supports the first and I am certain the second is not useful advice to a business with a three-year-old TZ and no budget line for replacing it. Every vendor of edge appliances has had a year like this one; Ivanti, Fortinet, Citrix and Cisco have all had their own, and the pattern is the same each time: a product built on an older codebase, a service on the loopback interface with a default credential, and a front end that can be persuaded to talk to it. The SMA1000's admin:admin CouchDB is not a SonicWall problem so much as an industry habit, and it is the reason a request-forgery bug keeps scoring ten out of ten.
What the SMA1000's four months do demonstrate is that patching once is no longer the end of anything. Each fix was correct and each was overtaken within weeks. The organisations that came through it well were not the ones with the best firewall; they were the ones who knew what they had, read the advisory the day it was published, applied the hotfix inside the week, looked at the logs afterwards, and had those logs somewhere the attacker could not reach. None of that is a product. All of it is a habit, and a habit is something a small business can afford.