Field Notes · Incident Command September 2, 2026 · 9 min read

You patched the appliance. That is not the investigation.

This week brought a run of exploited zero-days in SonicWall SMA1000, PaperCut and JFrog Artifactory. Patching closes the door. It does not tell you who already walked through it, what they took, or what they left behind.

Update. Updated 2026-09-02: reacts to CISA KEV additions and public reporting on SonicWall SMA1000, PaperCut NG/MF and JFrog Artifactory as of 2 September 2026.

Does patching mean you are clean

No. A patch removes the vulnerability from the appliance going forward, and it says nothing about the interval between the exploit going live and the hotfix being applied.

Every product in this week's run was exploited before or while the fix shipped, and in one case the first fix was itself bypassed.

The only way to answer the question the insurer and the board will ask is a post-patch investigation, with evidence pulled off the appliance before anyone reboots it.

Why a patch is not an investigation

Three vendors shipped emergency fixes this week for products that sit at the edge of the estate or deep in its plumbing. SecurityWeek reported on 2 September that SonicWall's SMA1000 remote-access appliances, models 6210, 7210 and 8200v, carry a pre-authentication SSRF, CVE-2026-83548, rated CVSS 10.0, which attackers chained with an authenticated OS command injection, CVE-2026-83549, to reach unauthenticated remote code execution. SonicWall observed exploitation of both and said they appear chained. The fixes are hotfixes 12.4.3-03526 and 12.5.0-02952. CISA added the flaw to its Known Exploited Vulnerabilities catalog the same day. SonicWall published no indicators of compromise.

PaperCut NG and MF print-management servers carry CVE-2026-81578 and CVE-2026-82078, an unauthenticated authentication bypass leading to remote code execution. SecurityWeek reported on 1 September that the first emergency patch was bypassed and a second was issued. watchTowr's Jake Knott described the shift "from purely exploratory probes" to "real-world exploitation accompanied with hands-on-keyboard interaction," with attackers using in-memory payloads and pivoting across the network. More than 1,000 instances are exposed. CISA listed it on 31 August with a federal deadline of 14 September.

JFrog Artifactory, self-managed in its default configuration, carries CVE-2026-82329, an authentication bypass that lets an unauthenticated attacker forge admin tokens. watchTowr observed exploitation. Fixed versions include 7.111.21 and 7.161.20. JFrog Cloud is not affected, per BleepingComputer on 2 September.

The pattern is the same in each. The product was exploited before the fix existed, or while the fix was still wrong. The fix changed the code on the box. It did not change what had already happened on the box.

A patch is a change to the future. An investigation is a reconstruction of the past. IT is measured on the first and rarely resourced for the second, which is why "we patched" reaches the board pack as though it answered the question. Three things make the appliance case worse than an ordinary server:

The appliance holds the only record. A remote-access gateway or a print server is usually not forwarding its logs anywhere. Whatever it knows about the sessions, source addresses and commands that hit it lives on the box and nowhere else.
The fix usually requires a reboot, and a reboot on many appliances clears volatile state and rotates or truncates local logs. The act of remediation can be the act of destroying the evidence.
The attacker's goal on an edge device is rarely the device. It is the credentials, the configuration export and the trusted network position that let them move inward. By the time the patch lands, the interesting activity may already be on a domain controller.

So the question to put to IT is not "is it patched." It is "what did the appliance see between the day the exploit went live and the day you applied the hotfix, and where is that record now."

The evidence to demand

This is what I would want in hand before anyone signs a statement that the environment is clean. Each item is a document, an export or a query result, not a verbal assurance.

Appliance logs exported off-box before the reboot. If the hotfix is already applied and the box restarted, ask what was captured first. If the answer is nothing, that is a finding in its own right and it goes in the report as an evidence gap, not a clean result. Where the appliance is still unpatched, the order is capture, then patch: a full log export, the running configuration, and where the platform allows it a memory or disk image, all taken before the reboot. SonicWall has published no indicators of compromise for the SMA1000 chain, which means nobody can hand IT a list of strings to search for. The raw logs are the only thing that can be searched later, when indicators do appear.

An account, session and token audit with proof of revocation. Exploitation of a remote-access appliance yields sessions and credentials. Exploitation of Artifactory yields forged admin tokens. Black Duck's Collin Hogue-Spears put the Artifactory point plainly: "upgrading the Artifactory binary does not by itself invalidate an already-issued token." A token forged before the upgrade keeps working after it. Revocation is a separate step with its own evidence, and the evidence is the list of tokens that existed, the list that was revoked, and the timestamp on each. The same logic applies to VPN sessions and local administrator accounts on the SonicWall and to admin sessions on PaperCut. Ask for the before and after lists, not a note that "credentials were rotated."

A post-exploitation hunt that starts from the appliance. The patch tells you nothing about what happened next. The hunt should cover, at minimum:

New or modified administrative users on the appliance and in the directory it authenticates against, created inside the exposure window.
Configuration exports or backups pulled from the device, which on a remote-access appliance can contain the credentials and certificates needed to impersonate it.
Lateral movement from the appliance's internal IP address. Authentication logs, firewall logs and endpoint telemetry filtered on that source address for the whole window.
In-memory payloads. watchTowr's reporting on PaperCut describes attackers running in memory and pivoting across the network. Disk-based antivirus will not see that. The evidence is process memory and the network connections those processes made, and it is gone the moment the host restarts.

Confirmation of the second patch where the first was bypassed. PaperCut's first emergency fix was defeated and a second was issued. A change ticket that says "PaperCut patched" without the version string and the date is not evidence that the effective fix is in place. Ask for the version currently running, not the version somebody intended to install. Then ask whether the exposure window was recalculated to run through the second fix rather than the first.

The window, the insurer and the board

The number that matters is the exposure window: the interval between the earliest credible date of in-the-wild exploitation and the timestamp of the effective patch on your device. For SMA1000 the vendor confirmed exploitation of both flaws. For PaperCut, the window opened before the first patch and stayed open through the bypass. For Artifactory, exploitation was observed against the default self-managed configuration. In each case the device sat on the internet for the whole of that window.

Ransomware follow-on from edge-appliance zero-days does not arrive on patch day. It tends to surface weeks later, after the access has been handed off, the environment mapped and the backups located. Insurer data from At-Bay has placed SonicWall VPNs in a large share of the Akira ransomware cases it has handled. That is the history behind the SMA1000 advisory, and it is why the patch date is the beginning of the watch period, not the end of it.

Which brings me to the two audiences who will eventually ask. The insurer wants to know whether you can demonstrate that the vulnerability was not exploited on your device before the fix, because if it was, the loss event may predate the claim you are about to file. The board wants to know whether anyone got in, and if you do not know, whether you are still looking. "We patched" answers neither.

What you should be able to show:

The exposure window for each affected device, with the exploitation start date taken from public reporting and the patch time taken from the device itself.
The logs and images captured before remediation, with hashes and a chain of custody.
The account, session and token audit, with revocation evidence.
The scope and result of the post-exploitation hunt, including what could not be checked because the evidence no longer exists.
A monitoring plan that runs through the period in which follow-on ransomware typically surfaces.

The last item is the one that gets dropped, because the incident feels finished the moment the hotfix is applied. This week's reporting says the opposite. The hotfix is when the investigation should start.

Questions people ask

We applied the hotfix and rebooted. Is it too late to investigate?

No, but the reboot may have cost you the appliance's own record. Directory, firewall and endpoint logs from the exposure window still exist elsewhere and can show lateral movement from the device. Document what the reboot destroyed as an evidence gap and hunt from the surrounding systems inward.

Why does upgrading Artifactory not fix the forged tokens?

Because the upgrade changes the code that issues tokens, not the tokens already in circulation. Black Duck's Collin Hogue-Spears noted that upgrading the binary does not by itself invalidate an already-issued token. Revoking existing tokens is a separate step, and you should ask for the list of what was revoked and when.

How long should we keep watching after the patch?

Longer than feels necessary. Public reporting on edge-appliance zero-days consistently shows ransomware follow-on surfacing weeks after initial access, once the intruder has mapped the environment. Set the watch period from the patch date, not the discovery date, and keep it in the board's risk register until it closes.

If IT has patched and you need to be able to tell the insurer, the auditor, and the board whether anyone got in first, a compromise assessment answers the question the patch does not.