The Deadline That Ends the Wrong Task
A CISA Known Exploited Vulnerabilities entry sets a remediation deadline, and for most organizations the operational reflex is to read that deadline as "patch by this date." Patch by the date and the ticket closes. The problem is that for a specific and growing class of vulnerabilities, patching by the date closes the entry point an attacker used while leaving in place everything the attacker installed after they walked through it. The version number goes up. The web shell stays.
September 2026 produced two clean demonstrations of this gap, both now in the catalog, and both documented with the kind of forensic detail that makes the point impossible to wave away. The lesson is not new, but the frequency is rising, and the software affected is exactly the infrastructure that organizations are least able to simply rebuild on a whim.
JFrog Artifactory: Backdoors That Outlive the Fix
The clearest case is the JFrog Artifactory campaign behind CVE-2026-42018 and CVE-2026-42016. The two flaws chain: an unauthenticated request to an AWS token endpoint returns an internal anonymous token when a trailing slash slips the request past an authentication filter, and that token is then exchanged for a full administrator token because Artifactory validated the token's signature and issuer but not its scope. An anonymous HTTP request becomes an administrator in two steps.
What matters for remediation is what the attackers did with that administrator access. Wiz Research, which first documented the in-the-wild campaign, reported that operators moved from initial exploitation to creating an admin account in under five minutes, then deployed a custom Rust backdoor with command-and-control capabilities and malicious Groovy plugins for code execution and persistence, staged in world-writable paths such as /dev/shm. The command-and-control endpoint was 64.207.232.6:8443, one payload carried the SHA-1 513a907b69edffc3cb77a494da395178d21ef9bd, and the attacker-created accounts matched the patterns Nxploited_ and labadmin_.
None of that is removed by upgrading Artifactory. The Groovy plugin runs because Artifactory loads plugins from its own plugin directory, not because the vulnerable code path is still reachable. The admin account persists in the database. The Rust process keeps running until someone kills it. Wiz's follow-up numbers make the trap concrete: roughly two-thirds of organizations running Artifactory were vulnerable at initial disclosure, and around 59 to 62 percent were still vulnerable six weeks later, which means many of the shops that eventually patched did so long after the exploitation window had opened, and a patch applied after compromise is a patch applied to an already-owned system.
Adobe Commerce: Implants Before a Fix Existed
The Adobe Commerce and Magento vulnerability CVE-2026-75650, which Sansec named StyleSmuggler, tells the same story from the other end of the timeline. It was exploited as a zero-day starting 2026-09-04, three full days before Adobe shipped its hotfix. By the time a patch existed, multiple actors had already been on vulnerable stores for days.
Sansec documented at least two independent operators. One dropped Rust binaries disguised as ordinary Linux processes (fc-cache, chronyd, and a fake kernel worker), with command-and-control traffic disguised as NTP to 99.84.67.186 and ntp.timesync.to. A second wrote a PHP web shell into the store's own media cache directory, at a path of the form pub/media/catalog/product/cache/ss_<hex>/sync_<hex>.php, gated behind a custom HTTP header. Later tooling in the same campaign included a remote access trojan tracked as WraithC2.
Sansec's remediation guidance is explicit that patching is not enough: apply the hotfix, then rotate the Magento encryption key, because active exploitation may have exposed the credentials and secrets that key protects, and hunt for the planted binaries and web shells by hash and by path. A store that only applied VULN-39341 and moved on is a store still serving an attacker's PHP from its own cache folder.
Why Implants Survive Updates
The mechanism is the same across both campaigns, and understanding it is what turns "patch faster" into a more useful instruction. A software update fixes the vulnerability. It does not, and structurally cannot, know about the artifacts an intruder created while the vulnerability was live, because those artifacts are indistinguishable at the file-system level from legitimate content the application is designed to hold.
Three properties make persistence durable:
The implant lives outside the patched code. A Groovy plugin, a PHP file in a media cache, a Rust binary in /dev/shm, or a new administrator row in a database are all data the application legitimately stores or executes. The update replaces application binaries, not application data.
The attacker often plants valid credentials. When the post-exploitation step is "create an admin account" or "mint a long-lived token," the attacker no longer needs the original vulnerability. They log in the front door with credentials the system considers real. This is why credential rotation, not just patching, is a required remediation step for these CVEs.
Detection is deliberately obscured. The JFrog campaign's admin-scope tokens retained the username "anonymous" in audit logs. The Adobe implants impersonated chronyd and NTP traffic. The design goal of the post-exploitation tooling is to look like normal operation, so a defender scanning for "obviously malicious" files finds nothing.
This Is Not a New Problem, and the Precedent Is Instructive
The starkest historical version of this lesson is Barracuda's Email Security Gateway in 2023. CVE-2023-2868 had been exploited as a zero-day since at least October 2022, and the intruders had established persistence deep enough that in June 2023 Barracuda took the extraordinary step of telling customers to replace the physical appliances outright, regardless of patch level, rather than patch them. As Brian Krebs reported at the time, the company urged replacing, not patching, its own product. CISA and the FBI followed with indicators of compromise and guidance to isolate and replace affected devices immediately. The vendor had effectively concluded it could not guarantee removal of the intruder from a patched box.
That is the extreme end of the spectrum, but it is the same spectrum. When exploitation precedes the fix and the attacker's goal is durable access, the fix addresses the wrong half of the problem. The September 2026 appliance and infrastructure CVEs sit closer to the Barracuda end than to the "apply update, done" end that most patch programs are built for.
The Vendors Are Already Saying This
Notably, the advisories themselves increasingly carry this warning, and defenders should read the remediation section, not just the affected-versions table. Cisco's advisory for the Secure Firewall Management Center authentication bypass, CVE-2026-20079, describes three distinct clusters of post-compromise activity deploying web shells and additional malware, and its guidance is to hunt for specific log artifacts and planted scripts, not merely to upgrade. The Fortinet heap overflow CVE-2025-25249 was used to deploy PivotC2, a Node.js remote access trojan that provides an interactive shell and tunneling and persists independently of the vulnerable daemon. In each case the vendor's own text treats the update as necessary but not sufficient.
The CISA KEV required-action language has moved in the same direction. Recent entries reference a forensic triage expectation alongside the patch deadline, a recognition at the directive level that for exploited vulnerabilities the correct response is compromise assessment plus remediation, not remediation alone.
What "Remediated" Should Actually Mean
For any KEV entry where exploitation is confirmed and the affected system was internet-facing and unpatched during the exploitation window, the honest operating assumption is that the system may already be compromised, and the closeout criteria should reflect that:
- Apply the update. This remains step one and is not optional. It closes the entry point so the attacker cannot simply walk back in the same way.
- Hunt for the known implants. Use the indicators the vendor and researchers published: the JFrog C2 IP and payload hash and account-name patterns, the Adobe web shell paths and fake-process names, the Cisco log artifacts. These are in the individual CVE pages on this site.
- Rotate the secrets the attacker could have taken. Encryption keys, API and access tokens, admin passwords, and any downstream credentials the compromised system stored. If the post-exploitation step was credential creation, rotation is the only thing that revokes it.
- Look for attacker-created accounts and plugins. New administrators, new tokens, new plugins or extensions, new scheduled tasks. These are the persistence that survives the upgrade.
- Only then close the ticket. The patch deadline is a floor for the first step, not a definition of done.
The uncomfortable summary is that "we patched within the KEV deadline" and "we are not compromised" are two different claims, and for a growing share of the catalog the first does not imply the second. The organizations that internalize this treat a KEV entry for exploited infrastructure as the opening of an incident-response question, not the closing of a patch ticket. The ones that do not are, for these vulnerabilities, marking a system clean on the strength of a version number the intruder never cared about.