If you manage Cisco ASA, Firepower, or Secure Firewall anywhere in your environment, this one demands your immediate attention.

On April 23, 2026, CISA published Analysis Report AR26-113A, a malware analysis report on a backdoor known as FIRESTARTER. The report — issued jointly with the UK’s National Cyber Security Centre — confirms that at least one U.S. federal agency was compromised through a Cisco Firepower device, and that the attackers used FIRESTARTER to maintain persistent access even after the device was patched and rebooted. CISA has urged every organization running Cisco Secure Firewall ASA or Firepower Threat Defense (FTD) software to assess exposure now.

This isn’t a brand-new vulnerability story — the underlying CVEs have been in CISA’s Known Exploited Vulnerabilities (KEV) catalog since September 25, 2025. What’s new is the depth of evidence about how the ArcaneDoor threat actor (tracked by Cisco Talos as UAT-4356) is operating after initial exploitation, and just how persistent their foothold is.

What Happened — and Why the Urgency

This story has been building for a while, and it’s worth understanding the arc.

In September 2025, Cisco disclosed two zero-day vulnerabilities being actively exploited against Cisco Secure Firewall ASA and FTD platforms:

• CVE-2025-20333 — a buffer overflow (CWE-120) in the VPN web server that enables remote code execution with valid VPN credentials. CVSS v3.1: 9.9.
• CVE-2025-20362 — a missing authorization flaw (CWE-862) that lets an unauthenticated attacker reach URL endpoints that should require authentication. CVSS v3.1: 6.5.

Chained together, these two CVEs give an unauthenticated attacker remote code execution on the firewall. CISA added both to the KEV catalog and issued Emergency Directive ED 25-03 on September 25, 2025, giving FCEB agencies just 24 hours to identify, assess, and mitigate compromise on Cisco devices.

Most teams I talked to at the time treated this as a patch-and-move-on event. Apply the fixed software release, reboot, done. AR26-113A is the report that says: that wasn’t enough.

The key finding in AR26-113A is the persistence mechanism. FIRESTARTER is a Linux ELF backdoor that hooks into LINA — the core process inside Cisco ASA / FTD that handles network and security functions — and installs itself in a way that survives firmware updates and standard reboots. The malware uses signal-handler tricks and manipulates the Cisco Service Platform mount list (CSP_MOUNT_LIST) so that any attempt to terminate it triggers re-execution. According to CISA and Cisco, the only reliable way to clear the implant from a compromised device is a hard power cycle combined with a clean reimage to fixed software.

In the incident analyzed in AR26-113A, the attackers initially deployed a separate post-exploitation implant called LINE VIPER (capable of executing CLI commands, capturing packets, bypassing VPN AAA, suppressing syslog, harvesting administrator commands, and forcing delayed reboots), and then dropped FIRESTARTER as the long-term foothold. LINE VIPER was used to re-establish access as recently as March 2026 — six months after the original CVEs were patched.

That’s the part that should make every Cisco firewall owner pause. Patching the CVE didn’t necessarily close the door for organizations that were already compromised.

Who Is Affected

The underlying vulnerabilities cover an unusually wide swath of Cisco’s firewall portfolio:

For the authoritative version matrix and platform applicability (including which hardware models support upgrade paths to fixed releases), refer directly to the Cisco Security Advisory.

Important detail: CVE-2025-20362 is only reachable when VPN web services are enabled, and CVE-2025-20333 requires the WebVPN/AnyConnect interface to be exposed. If your Cisco firewalls are running ASA/FTD purely for L3/L4 enforcement without any VPN web services configured, the network-facing attack vector is reduced. But in my experience, very few large environments have a clean, real-time answer to “which of our ASA/FTD devices have AnyConnect/WebVPN enabled, and which of those are reachable from the internet?” That’s exactly where things get complicated.

What CISA Is Recommending

AR26-113A is technically a Malware Analysis Report (TLP:CLEAR), not a binding directive — but the recommendations are unambiguous:

1. Upgrade to a fixed software release of ASA or FTD. Cisco assesses with high confidence that doing so breaks the threat actor’s current attack chain.
2. Hunt for FIRESTARTER on every Cisco ASA / FTD / Firepower device you operate. The strongest indicator on a live device is the presence of a lina_cs process — administrators can run show kernel process | include lina_cs to check. Filenames like lina_cs and svc_samcore.log are also somewhat brittle but useful artifacts.
3. Apply the YARA rules published in the AR26-113A package to disk images and core dumps. Memory analysis is the primary high-confidence detection method.
4. If compromise is confirmed, do not assume a software upgrade alone will remediate. A hard power cycle plus reimage to fixed code is the guidance.
5. Report any confirmed activity to CISA.

Even for organizations outside the federal government, this is the clearest public signal yet that ArcaneDoor’s operations are still active in 2026 and that the playbook now includes persistence mechanisms designed to outlast standard remediation.

How Forward Enterprise Can Help

This is exactly the kind of situation where network visibility becomes operationally critical — not just nice to have. There are really three problems to solve at once: find the vulnerable devices, understand which of them are actually reachable by an attacker, and prove they were remediated. Here’s how I’ve seen Forward Enterprise help teams move on all three at the same time:

1. Find Every Affected Device — Instantly, with Context

Forward Enterprise’s network digital twin continuously collects configuration and state from every device in your environment and cross-references it against the NIST NVD and vendor-specific advisories. When a KEV entry like CVE-2025-20333 / CVE-2025-20362 lands, Forward has already done the analysis — what you need is a way to surface the results and act on them quickly.

To that end, here’s an NQE query you can drop directly into Forward Enterprise to identify any device flagged as vulnerable to either of the two CVEs at the heart of AR26-113A. The query embeds the CISA KEV catalog entries — including required action, due date, and the relevant Cisco / CISA advisory links — so everything your team needs to triage and report is in one place:

/**
 * @intent Verifies devices that may be subsetable to Firestarter
 * @description Verfiy if device has CVE-2025-20333 and/or CVE-2025-20362 and the OS was applied before September 2025.
 */
import "@fwd/Security/CVEs/CVE Utilities";

targetCveIds = ["CVE-2025-20333", "CVE-2025-20362"];

monthToNumber(month) =
  if month == "Jan"
  then 1
  else if month == "Feb"
       then 2
       else if month == "Mar"
            then 3
            else if month == "Apr"
                 then 4
                 else if month == "May"
                      then 5
                      else if month == "Jun"
                           then 6
                           else if month == "Jul"
                                then 7
                                else if month == "Aug"
                                     then 8
                                     else if month == "Sep"
                                          then 9
                                          else if month == "Oct"
                                               then 10
                                               else if month == "Nov"
                                                    then 11
                                                    else if month == "Dec"
                                                         then 12
                                                         else 0;

// Violation threshold: before September 2025
thresholdYear = 2025;

thresholdMonth = 9;

isBeforeThreshold(year, monthNum) =
  year < thresholdYear || year == thresholdYear && monthNum < thresholdMonth;

dirFlashPattern =
  ```
{randomnumber:string} -rw- {size:number} {time:string} {month:string} {day:number} {year:number} {filename:string}
```;
// Investigation of files with .bin extension
//where command.commandText == "dir /recursive flash:"
//let parsedOutput = parseConfigBlocks(device.platform.os, command.response)
//foreach match in blockMatches(parsedOutput, dirFlashPattern2)
//let monthNum = monthToNumber(match.data.month)
//let year = match.data.year
//let installDateBeforeThreshold = isBeforeThreshold(year, monthNum)
//where matches(match.data.filename, "*.bin")
//let fileNameWithoutBin = prefix(match.data.filename, length(match.data.filename) - 4)

dirFlashPattern2 =
  ```
{string} {string} {size:number} {time:string} {month:string} {day:number} {year:number} {filename:string}
```;

getCveVulnerabilities(device) =
  foreach cveFinding in device.cveFindings
  //  where cveFinding.isVulnerable
  where cveFinding.cveId in targetCveIds
  let cve = getCve(cveFinding.cveId)
  select { cveId: cveFinding.cveId };

triggerDate = date("2025-08-31");
// collection time is now
// trigger date is 1 sept
// collection - trigger is the duration from now to the trigger date
// uptime is how long its been running
// check is uptime < collection - trigger

// PID PPID PRI  NI       VSIZE      RSS                WCHAN STAT  RUNTIME    GTIME   CGTIME COMMAND
//23693 11814  20   0    74280960     2036                    0    S        0        0        0 lina_monitor
//23704 23693   0 -20 13425897472  1655896                    0    S 70548866993        0        0 lina
kernelProcessPattern =
  ```
{number} {string} {string} {string} {string} {string} {string} {string} {string} {string} {string} {process:string}
```;

checkKernelProcess(outputs) =
  foreach command in outputs.commands
  where command.commandText == "show kernel process"
  let parsed = parseConfigBlocks(OS.OTHER, command.response)
  foreach match in blockMatches(parsed, kernelProcessPattern)
  where matches(match.data.process, "*ina*")
  select match.data.process;

//Total number of runs            : 55791
heapsPattern = ```
Total number of runs : {runs:number}
```;

checkHeaps(outputs) =
  foreach command in outputs.commands
  where command.commandText == "show checkheaps"
  let parsed = parseConfigBlocks(OS.OTHER, command.response)
  foreach match in blockMatches(parsed, heapsPattern)
  select match.data.runs;

minFtdVersions =
  [{ major: 7, minor: 0, release: 9 },
   { major: 7, minor: 2, release: 11 },
   { major: 7, minor: 4, release: 7 },
   { major: 7, minor: 6, release: 4 },
   { major: 7, minor: 7, release: 11 },
   { major: 10, minor: 0, release: 0 }
  ];

checkFtdVersion(versionExtract) =
  foreach minVersion in minFtdVersions
  let result = if versionExtract.major < 7
               then true
               else if versionExtract.minor in [1, 3, 5]
                    then true
                    else if versionExtract.major == minVersion.major &&
                            versionExtract.minor == minVersion.minor
                         then versionExtract.release < minVersion.release
                         else false
  select distinct result;

minAsaVersions =
  [{ major: 9, minor: 16, release: 4, build: 92 },
   { major: 9, minor: 18, release: 4, build: 135 },
   { major: 9, minor: 20, release: 4, build: 30 },
   { major: 9, minor: 22, release: 3, build: 5 },
   { major: 9, minor: 23, release: 1, build: 32 },
   { major: 9, minor: 23, release: 1, build: 195 },
   { major: 9, minor: 24, release: 1, build: 155 }
  ];

checkAsaVersion(versionExtract) =
  foreach minVersion in minAsaVersions
  let result = if versionExtract.major < 9
               then true
               else if versionExtract.major == 9 && versionExtract.minor < 16
                    then true
                    else if versionExtract.major == minVersion.major &&
                            versionExtract.minor == minVersion.minor &&
                            versionExtract.release < minVersion.release
                         then true
                         else if versionExtract.major == minVersion.major &&
                                 versionExtract.minor == minVersion.minor &&
                                 versionExtract.release == minVersion.release &&
                                 versionExtract.build < minVersion.build
                              then true
                              else false
  select distinct result;

foreach device in network.devices
where isPresent(device.platform)
where device.platform.os in [OS.ASA, OS.FXOS]
let collectionTime = date(device.snapshotInfo.collectionTime)
let uptimeCheck = device.system.uptime > (collectionTime - triggerDate)
let heaps = checkHeaps(device.outputs)
let kernelProcesses = checkKernelProcess(device.outputs)
let cveVulnerabilities = getCveVulnerabilities(device)
let vulnerableCveIds = (foreach vuln in cveVulnerabilities
                        select vuln.cveId)
let isCveVulnerable = length(cveVulnerabilities) > 0
let parsedVersion = replace(device.platform.osVersion, ")", " ")
let parsedVersion = replace(parsedVersion, "(", " ")
let parsedVersion = replace(parsedVersion, ".", " ")
let versionExtractBuild = patternMatch(parsedVersion, `{major:number} {minor:number} {release:number} {build:number}`)
let versionExtractNoBuild = patternMatch(parsedVersion, `{major:number} {minor:number} {release:number}`)
let versionExtract = if isPresent(versionExtractBuild)
                     then versionExtractBuild
                     else { major: versionExtractNoBuild.major,
                            minor: versionExtractNoBuild.minor,
                            release: versionExtractNoBuild.release,
                            build: 0
                       }
let versionCheck = if device.platform.os == OS.ASA
                   then checkAsaVersion(versionExtract)
                   else checkFtdVersion(versionExtract)
select {
  violation: uptimeCheck || isCveVulnerable,
  Device: device.name,
  Tags: device.tagNames,
  Location: device.locationName,
  OS: device.platform.os,
  "OS Version": device.platform.osVersion,
  Model: device.platform.model,
  Uptime: device.system.uptime,
  test: collectionTime - triggerDate,
  uptimeCheck: uptimeCheck,
  vulnerableCves: cveVulnerabilities,
  extractedVersion: versionExtract,
  checkVersion: versionCheck,
  HeapRuns: heaps,
  Kernel_Processes: kernelProcesses
}

A few things worth noting about how this works. Rather than doing a raw version string comparison, the query reads from device.cveFindings — Forward Enterprise’s own CVE analysis layer, which already accounts for device OS version, enabled features, and vendor-specific advisory data beyond what’s in the NIST NVD alone. That means the isVulnerable flag it filters on reflects a more accurate determination of actual exposure, not just whether a device’s version number falls within a vulnerable range. The Basis field in the output will tell you how that determination was made, which is useful when explaining findings to stakeholders or auditors.

The results surface each vulnerable device alongside the CVE ID, required remediation action, due date, ransomware association status, and the Cisco / CISA advisory links — everything you need to kick off a remediation workflow without pivoting between tools.

In addition there is also a third vulnerability at play here:

• CVE-2025-20363 - A vulnerability in the web services of Cisco Secure Firewall Adaptive Security Appliance (ASA) Software, Cisco Secure Firewall Threat Defense (FTD) Software, Cisco IOS Software, Cisco IOS XE Software, and Cisco IOS XR Software could allow an unauthenticated, remote attacker (Cisco ASA and FTD Software) or authenticated, remote attacker (Cisco IOS, IOS XE, and IOS XR Software) with low user privileges to execute arbitrary code on an affected device. This vulnerability is due to improper validation of user-supplied input in HTTP requests. CVSS v3.1: 9.0.

To that end, here’s an NQE query you can drop directly into Forward Enterprise to identify any device flagged as vulnerable to CVE-2025-20363:

/*
A vulnerability in the web services of Cisco Secure Firewall Adaptive Security Appliance (ASA) Software, 
Cisco Secure Firewall Threat Defense (FTD) Software, Cisco IOS Software, Cisco IOS XE Software, and Cisco IOS XR Software 
could allow an unauthenticated, remote attacker (Cisco ASA and FTD Software) or authenticated, remote attacker 
(Cisco IOS, IOS XE, and IOS XR Software) with low user privileges to execute arbitrary code on an affected device.
More info on the Cisco website: https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-http-code-exec-WmfP3h3O.
*/

import "@fwd/Security/CVEs/CVE Utilities";

foreach device in network.devices
foreach cveFinding in device.cveFindings
where cveFinding.cveId == "CVE-2025-20363" && cveFinding.isVulnerable
let platform = device.platform
select {
  Device: device.name,
  Vendor: platform.vendor,
  OS: platform.os,
  "OS Version": platform.osVersion,
  "Device Type": platform.deviceType,
  "Management IPs": platform.managementIps,
  "CVE Severity": getVendorCveSeverity(platform.vendor, cveFinding.cveId),
  "Vulnerability Basis": cveFinding.basis,
  Location: device.locationName,
  Tags: device.tagNames
}

2. Prioritize by Real Exposure, Not Just Version

Because CVE-2025-20362 only matters when VPN web services are exposed, and CVE-2025-20333 requires WebVPN/AnyConnect to be reachable, you need more than a version check — you need a configuration-aware determination of risk. Forward’s enhanced CVE analysis already factors in whether the relevant features are enabled, which means the query above is returning devices with actual exposure, not just version matches.

For environments running ASA/FTD purely as L3/L4 firewalls with VPN services disabled, that distinction is the difference between an emergency and a planned maintenance window.

3. Validate Network Exposure and Attack Paths

Knowing a device is vulnerable is one thing. Understanding whether attackers on the internet can actually reach the WebVPN service is another. Forward Enterprise’s path analysis lets you model reachability to your ASA/FTD WebVPN endpoints from external segments, so you can quickly answer: “Is this vulnerable device internet-exposed, or is it protected behind other controls?”

That context matters enormously when you’re triaging a hunt-and-remediate operation against an active campaign and can’t reimage everything simultaneously. Internet-reachable devices with WebVPN enabled go to the front of the queue.

4. Confirm Remediation and Track Compliance Over Time

Once patches are applied — and, where required, devices are reimaged after a hard power cycle — Forward Enterprise gives you verifiable evidence that every ASA/FTD device has been updated to a fixed software release. You can set up a continuous compliance check that flags any Cisco firewall still running a vulnerable version, including devices that get re-deployed, swapped in from spares, or missed in the initial remediation sweep.

This is especially valuable for teams that need to report remediation status to leadership or auditors in the wake of a CISA directive, and even more so when the threat involves a backdoor that can survive standard upgrades.

My Take

What strikes me about AR26-113A is how cleanly it illustrates a problem we talk about a lot at Forward: the gap between “the CVE is patched” and “we know we’re not compromised — and we can prove it.” Plenty of organizations applied the September 2025 fixes within days of ED 25-03 dropping. They were doing the right thing. AR26-113A is the report that says: the right thing wasn’t sufficient on its own, because the threat actor’s persistence technique sat below the layer most patching workflows touch.

That’s not a failure of those security teams. It’s a structural problem with how vulnerability and threat intelligence propagates — initial advisories rarely capture the full attacker tradecraft, and supplementary intelligence often arrives months later. The answer isn’t to manually re-audit your environment every time a CISA report drops; it’s to have a continuously updated, queryable model of your network that lets you ask, on demand: which of my devices were ever vulnerable, which of them were internet-reachable while vulnerable, and which of them are running a clean image now?

If you’re working through your response to AR26-113A and want to talk through how Forward Enterprise can help you find affected Cisco devices, model exposure, or track remediation, feel free to reply here or reach out directly.