Cisco is now telling you the patch doesn't clean the box

Cisco’s April 23 advisory says the September 2025 patch you installed on your Firepower or Secure Firewall does not remove the malware it was supposed to lock out. The vendor’s own word for the implant’s relationship to its own fixed releases is “preserved.” That is the story.

The advisory is cisco-sa-asaftd-persist-CISAED25-03, and its title names the situation: “Continued Evolution of Persistence Mechanism Against Cisco Secure Firewall ASA and Secure Firewall Threat Defense.” The implant is called FIRESTARTER, attributed to UAT-4356, the same actor behind the April 2024 ArcaneDoor disclosure. At least one U.S. federal civilian agency had a Firepower device compromised before September 25, 2025, and CISA confirmed the implant was still actively connected to its operators as recently as March 2026, six months after that agency applied the patch.

This is not a researcher reverse-engineering a Cisco update and finding gaps. This is Cisco telling its own customers that their patched boxes may still be owned.

What the advisory actually says

FIRESTARTER does not live in the firmware image. It lives in the config partition, in a boot-time file called CSP_MOUNT_LIST that FXOS reads on every startup. A normal Cisco software upgrade replaces the firmware image partition and leaves the config partition alone. That is the entire trick. The implant writes shell commands into a file that the next boot is going to execute no matter what release you just installed.

Once running, FIRESTARTER hooks into LINA, the core data-plane process, and replaces XML handler functions with malicious routines. The command channel is hidden inside WebVPN authentication requests carrying a magic packet. Standard network monitoring does not see it because it is the VPN authentication flow.

The malware also defends itself against a graceful reboot. When it receives a normal shutdown signal, it re-stages a copy of itself and rewrites CSP_MOUNT_LIST before power-down. That is why Cisco’s remediation is not “reboot” but “physically disconnect every power supply for at least one minute.” A clean software shutdown gives the implant a chance to re-stage. Only a cold restart prevents the re-staging routine from running.

Cisco’s wording is plain: the implant “is preserved across upgrading to the fixed releases that were published in September 2025.” The fixed releases were the patches for CVE-2025-20333 and CVE-2025-20362, the VPN web server vulnerabilities CISA had ordered federal agencies to apply under Emergency Directive 25-03. Those patches do exactly what patches are supposed to do. They close the initial access vector. They do not touch the file the implant uses to reload itself.

Which boxes

The affected hardware is the FXOS-based product family. From the Cisco advisory:

• Firepower 1000 Series
• Firepower 2100 Series
• Firepower 4100 Series
• Firepower 9300 Series
• Secure Firewall 1200 Series
• Secure Firewall 3100 Series
• Secure Firewall 4200 Series

Not affected: ASA 5500-X, Secure Firewall 200, Secure Firewall 6100, ASA Virtual, FTD Virtual, ISA3000. The ASA 5500-X line has its own separate ROMMON-based persistence technique attributed to the same actor, documented earlier, but FIRESTARTER specifically targets the FXOS config partition and is a different mechanism on different hardware.

The scope-of-exposure language in the advisory is narrow: a device is in scope if it was running vulnerable ASA or FTD software before September 25, 2025, had SSL VPN or clientless SSL VPN enabled, and was internet-accessible. Cisco does not explicitly extend the reimaging recommendation to internally-accessible-only devices, and CISA does not address that case cleanly either. If you have an in-scope device that was internet-exposed at any point before the September patch, the advisory’s recommendation is reimage, not patch.

What “patched” no longer means

There is a quieter, harder claim sitting underneath this advisory. Patch a device. Run the documented detection command. See nothing. The advisory does not call that clean.

The detection command, show kernel process | include lina_cs, surfaces the malicious process only if it is currently running. Cisco and CISA both acknowledge the file names FIRESTARTER drops can be renamed by the operator, so the absence of /usr/bin/lina_cs and /opt/cisco/platform/logs/var/log/svc_samcore.log is not a clean bill of health either. CISA’s directive required federal agencies to submit core dumps to its Malware Next Generation platform for deeper analysis, which is the operational tell: a passing show kernel process was treated as necessary but not sufficient.

Where in firmware the implant might be staged outside of the config-partition mechanism is not fully described in public materials. Cisco’s advisory documents the CSP_MOUNT_LIST technique. Talos and Eclypsium describe the LINA hook and the in-memory shellcode. Whether the actor has parallel persistence techniques on FXOS hardware that the published advisory does not enumerate is not addressed.

Read that the way it reads. Cisco has told you about one persistence mechanism on FXOS hardware that survives upgrades. They have not told you it is the only one.

Why this keeps landing on the same vendors

Perimeter appliance code is old, written in memory-unsafe C, exposed to the internet by design, and built on layered legacy firmware where vendors do not actually control every persistence surface on the device. The ArcaneDoor campaign has now produced two distinct persistence techniques on two different Cisco hardware generations, both attributed to the same actor. Ivanti, Fortinet, Palo Alto, and F5 each have their own multi-year KEV histories on the same VPN/edge surface.

The structural problem is that “patch and continue” is the operational contract every enterprise has internalized for the rest of its stack, and it does not transfer to perimeter appliances. The vendor ships an update; you apply it; the box is presumed clean. The April 23 Cisco advisory is the explicit statement that this contract does not hold for at least one product family at one threat-actor tier. That is a category change, not an isolated finding.

What you should actually expect

If you run any of the affected FXOS hardware and any of those devices were internet-exposed with SSL VPN enabled before September 25, 2025, the operational answer is the one Cisco has been clear about. Collect forensic evidence first. Then pull power, including redundant power, for at least one minute. Then reimage. Then upgrade to ASA 9.24.1.155 or later, FTD 7.7.11 with Hotfix AE-7.7.11.1-4, or FXOS 2.18.0.535, depending on your branch. Then rotate every credential, certificate, and key the device touched.

Budget reimaging as a planned outage with the network team, not a security task you slot into a Tuesday. Cisco’s own advisory notes the hard power cycle can corrupt configuration or database state, which means a configuration backup is a prerequisite, not an afterthought. The window will eat operator hours. That is the actual cost of the implant, paid by the customer rather than the vendor who shipped the platform.

The temporary mitigation, if you cannot reimage immediately, is to disable VPN web services: no webvpn on ASA, uncheck Enable SSL on FTD. That removes the C2 trigger. It does not remove the implant. Treat it as a stopgap measured in days, not a remediation.

What the perimeter contract is now

A perimeter appliance is a vendor-managed black box that sits on the internet and decides who reaches your enterprise. The implicit deal has always been that the vendor owns the integrity of that box and patching is the customer’s lever for getting the vendor’s fix delivered. The Cisco advisory says, on the vendor’s own letterhead, that for one product family the lever does not work. You can do the patch correctly, on time, with no operational error, and still be hosting a state-sponsored implant six months later.

The right adjustment is not “patch faster.” It is to treat any perimeter appliance that was internet-exposed before a known exploited zero-day window as untrusted until forensically cleared or reimaged. The vendor has now told you that. The work is figuring out how to make that the default posture for a class of device that an enterprise has dozens of, instead of the special case you handle once per advisory.