Today's picture
CISA and the UK NCSC published a joint malware analysis report this week on a backdoor called FIRESTARTER found on a federal agency's Cisco firewall. The implant was planted in September 2025, survived every patch and every reboot for seven months, and was only discovered through continuous monitoring in April. The only way to remove it is to physically pull the power cord. Separately, a vulnerability in LMDeploy, a widely used toolkit for deploying large language models, was exploited within 13 hours of public disclosure, with the attacker using it to map cloud credentials and internal infrastructure behind the model server.
Threat snapshot
3 new · 2 monitoring
New
APT · China-Nexus
FIRESTARTER backdoor survived seven months on a federal Cisco firewall. Only a power pull removes it.
UAT-4356, linked to ArcaneDoor. Deployed September 2025. Survived all patches and reboots. Triggered by specially crafted WebVPN requests. Federal deadline April 30 for hard reset.
New
AI Infrastructure
13hr Exploit
LMDeploy SSRF exploited in under 13 hours. Attacker mapped cloud credentials and internal network in one session.
CVE-2026-33626 CVSS 7.5. Used to reach AWS metadata, Redis, MySQL, and internal services. All LMDeploy versions with vision support affected. Patch to 0.12.1 immediately.
New
KEV Listed
PaperCut and JetBrains TeamCity both confirmed exploited and added to CISA KEV.
PaperCut CVE-2023-27351 linked to Lace Tempest ransomware. TeamCity CVE-2024-27199 path traversal. Both widely deployed. Federal deadline May 4.
Detailed intelligence
Full analysis
01 New APT · China-Nexus
FIRESTARTER backdoor survived seven months on a federal Cisco firewall. Only pulling the power removes it.
FIRESTARTER · UAT-4356
What happened
CISA and the UK NCSC published a joint malware analysis report on April 24 detailing FIRESTARTER, a custom backdoor discovered on a Cisco Firepower device running ASA software at an unnamed US federal civilian agency. The malware was deployed by threat actor UAT-4356, which Cisco Talos assesses as a China-nexus APT group previously connected to the ArcaneDoor campaign that targeted Cisco ASA devices via zero-days in 2024.
The initial access occurred in September 2025 through exploitation of two Cisco ASA vulnerabilities, CVE-2025-20333 and CVE-2025-20362, which were patched by Cisco that same month. However, devices compromised before the patches were applied retained the implant. FIRESTARTER was not removed by the firmware updates. Cisco's standard shutdown, reboot, and reload CLI commands also do not clear the implant. Only a hard power cycle, physically unplugging the device, removes it from memory.
FIRESTARTER achieves persistence by modifying the CSP_MOUNT_LIST boot configuration file, ensuring it relaunches on every startup. It stores a copy of itself in the device's log directory and restores it automatically if terminated. The implant embeds into LINA, the core Cisco ASA network processing engine, by installing a hook that intercepts XML handler functions. When it receives a specially crafted WebVPN authentication request containing a hidden trigger sequence, it executes attacker-supplied shellcode directly in memory. In the federal incident, attackers first deployed a separate implant called Line Viper to harvest device credentials and VPN configuration data, then installed FIRESTARTER as the persistence layer. After the agency patched its systems in September, FIRESTARTER kept the door open. The attackers used it to redeploy Line Viper in March 2026, nearly six months after initial compromise. CISA discovered the activity through continuous monitoring and initiated forensic engagement. CISA has published two YARA rules for detecting FIRESTARTER on disk images or core dumps, and has issued updated guidance requiring federal agencies to assume potential compromise and perform hard power cycles on affected device models by April 30.
CyberSip Take
The FIRESTARTER disclosure challenges one of the most fundamental assumptions in vulnerability management: that patching closes the door. In this case, applying the September 2025 patches was the correct action and did prevent re-exploitation of the original vulnerabilities. But the attacker was already inside before the patches were applied, and FIRESTARTER ensured they stayed inside regardless of what happened afterward. The agency followed standard remediation procedure and remained compromised for seven additional months.
This has two practical implications worth naming directly. First, patching is necessary but not sufficient when dealing with a sophisticated adversary who may have pre-positioned before the patch window closed. Post-patch forensic validation on internet-facing edge devices is not a luxury. It is the only way to confirm actual remediation rather than assumed remediation. Second, the specific device types called out in CISA's guidance matter: Firepower 1000, 2100, 4100, 9300 series and Secure Firewall 200, 1200, 3100, 4200, and 6100 series. Organizations running these models should be treating this week's disclosure as a direct operational prompt, not background reading. The April 30 hard power cycle deadline for federal agencies reflects the urgency CISA is assigning to this. Private sector organizations running the same hardware have the same exposure.
Recommended actions
- Identify all Cisco Firepower and Secure Firewall devices in your environment running ASA or FTD software, specifically the models listed in CISA's updated Emergency Directive 25-03.
- Apply CISA's YARA rules to disk images or core dumps from these devices before performing any remediation actions. Rebooting or patching before collection may destroy forensic artifacts.
- If FIRESTARTER indicators are found, do not use CLI reboot commands. A hard power cycle, physically pulling the power cord, is the only method confirmed to clear the persistence mechanism from memory.
- Check for the presence of the malicious process lina_cs and the files /usr/bin/lina_cs and /opt/cisco/platform/logs/var/log/svc_samcore.log as indicators of compromise.
- Review CISA Emergency Directive 25-03 updated guidance and Cisco's security advisory for full remediation and reimaging procedures.
Derived from CISA and NCSC-UK joint malware analysis report AR26-113A, CISA Emergency Directive 25-03 updated guidance, and Cisco Talos analysis
02 New AI Infrastructure
LMDeploy SSRF exploited in under 13 hours. Attacker used it to map cloud credentials and internal services in a single eight-minute session.
CVE-2026-33626
What happened
Sysdig published research this week documenting active exploitation of CVE-2026-33626, a server-side request forgery vulnerability in LMDeploy, an open-source toolkit from Alibaba's ModelScope team widely used to compress, deploy, and serve large language models at scale. The vulnerability exists in the vision-language module's load_image() function, which fetches arbitrary URLs without validating whether the destination is an internal or private IP address. An attacker can supply a malicious URL as an image input and the server will make the request on their behalf, giving them access to anything reachable from the model server's network position.
Sysdig's honeypot detected the first exploitation attempt 12 hours and 31 minutes after the vulnerability was published on GitHub on April 22. The attacker did not simply confirm the bug. Over a single eight-minute session, they used the SSRF as a generic network scanning primitive to probe the AWS Instance Metadata Service to attempt credential theft, enumerate Redis and MySQL database ports, reach a secondary HTTP administrative interface, and exfiltrate data to an out-of-band DNS endpoint. The attacker rotated between different vision language models during the session to avoid detection patterns. All versions of LMDeploy with vision language support at 0.12.0 and prior are affected. A patch is available in version 0.12.1.
CyberSip Take
Thirteen hours is not a new record for disclosure-to-exploitation, but the behavior documented in this incident is worth understanding carefully. The attacker was not simply validating that the vulnerability worked. They were conducting reconnaissance. AWS Instance Metadata Service access means they were trying to steal the IAM credentials attached to the EC2 instance running the model server. Those credentials would give them access to every AWS service that instance is authorized to touch. The Redis and MySQL probes show they were mapping the data infrastructure behind the model server. In eight minutes, a single SSRF vulnerability in an AI deployment toolkit became a credential theft attempt and an internal network map.
This connects to the pattern we named in Issues 11, 12, and 13: AI infrastructure tools are being deployed with production access to sensitive resources, and the security review of those tools has not kept pace. LMDeploy sits in a class of software that runs on cloud infrastructure, often with broad IAM permissions attached, and processes inputs that come from external users. An SSRF in that position is not just a web application vulnerability. It is a key to the surrounding cloud environment. The question for any team running LLM deployment infrastructure is not just whether the model service itself is patched, but what network and cloud resources that service can reach and whether those are appropriately restricted.
Recommended actions
- Update LMDeploy to version 0.12.1 or later immediately. All prior versions with vision language support are affected.
- Apply network egress controls on model serving infrastructure to restrict outbound connections to known, necessary endpoints. SSRF attacks depend on the server being able to reach internal and cloud metadata services freely.
- Restrict AWS Instance Metadata Service access on EC2 instances running LLM deployment workloads. IMDSv2 with hop limit set to 1 prevents containers and nested requests from reaching instance metadata.
- Audit the IAM permissions attached to instances running model serving infrastructure and apply least privilege. The potential blast radius of an SSRF is bounded by what the instance is authorized to do.
Derived from Sysdig threat research and CVE-2026-33626 advisory from LMDeploy project maintainers
03 New KEV Listed
PaperCut and JetBrains TeamCity both confirmed exploited and added to CISA KEV. Federal deadline May 4.
CVE-2023-27351 / CVE-2024-27199
What happened
CISA added two widely deployed enterprise tools to the KEV catalog this week, each with confirmed active exploitation. CVE-2023-27351 is an improper authentication vulnerability in PaperCut NG and MF, the print management software used across education, healthcare, and enterprise environments. The flaw allows an attacker to bypass authentication on affected installations through the SecurityRequestFilter class. Exploitation of this vulnerability was linked to the Lace Tempest threat group in April 2023, which used it to deliver Cl0p and LockBit ransomware. CVE-2024-27199 is a relative path traversal vulnerability in JetBrains TeamCity that allows an attacker with no administrative credentials to perform limited administrative actions through a crafted request. TeamCity is a CI/CD platform widely used by development teams to automate build, test, and deployment pipelines. A separate TeamCity flaw, CVE-2024-27198, was added to KEV in March 2024. It is not yet confirmed whether the two flaws are being exploited together by the same actor. Federal remediation deadline for both is May 4, 2026.
CyberSip Take
Both of these CVEs are old by the calendar but new to confirmed exploitation tracking. The PaperCut vulnerability dates to 2023 and was linked to ransomware delivery that year. Its appearance in KEV now means CISA has confirmed fresh active exploitation, not historical activity. The TeamCity flaw is from 2024. The pattern of older vulnerabilities being actively exploited years after their initial disclosure has been a recurring theme in this brief since Issue 1. Attackers maintain libraries of working exploits for unpatched systems and continue using them as long as unpatched instances remain reachable. PaperCut is present in the vast majority of university and large enterprise print environments. TeamCity sits inside CI/CD pipelines with access to source code, build artifacts, and deployment credentials. Neither is a fringe product. Organizations that deferred patching on the assumption that old CVEs stop being exploited should treat today's KEV entries as the counterargument.
Recommended actions
- Apply the PaperCut NG/MF patch addressing CVE-2023-27351 if not already done. Check PaperCut's KB article PO-1216 and PO-1219 for specific version guidance.
- Apply the JetBrains TeamCity patch for CVE-2024-27199. Also verify CVE-2024-27198 is patched as the two flaws may be used in combination.
- Restrict TeamCity server access to internal networks only. A CI/CD platform with administrative access to build pipelines should not be reachable from the public internet.
- Review PaperCut server access logs for unusual authentication activity and unauthorized attempts to access the administrative interface from unexpected sources.
Derived from CISA known-exploited vulnerability catalog and vendor security advisories
Still watching
Aging items · days 2–6
Items here remain operationally relevant but have no significant new developments. They drop off after 7 days.
PhantomRPC unpatched Windows RPC design flaw (Issue 14). No CVE, no patch, research tools public. No confirmed exploitation yet. Monitor for unusual RPC server registrations and watch Microsoft MSRC for a patch announcement.
Day 2
GlassWorm wave 3 Open VSX extensions (Issue 14). 73 sleeper packages, 6 activated. Audit installed extensions against Socket's tracking page. AI coding tool extensions specifically targeted this wave.
Day 2
Bitwarden CLI supply chain attack (Issue 13). Rotate credentials if @bitwarden/cli@2026.4.0 was installed April 22 between 5:57 and 7:30 PM ET. Check for unexpected public GitHub repos under your account.
Day 3
Cross-source standouts
What connects this week
01
Patching confirmed compromise is not the same as closing it
FIRESTARTER is the clearest example this month of a problem that deserves a standing place in incident response planning. When an attacker pre-positions before a patch is applied, the patch prevents future exploitation of that specific vulnerability but does nothing about the implant already running. The federal agency in this incident did what it was supposed to do. It applied the patches. It remained compromised for seven more months. The defensive discipline this demands is post-patch forensic validation on any internet-facing edge device that was potentially exposed during a vulnerability window. Most organizations do not do this systematically because it requires effort and the assumption is that patching is sufficient. FIRESTARTER is the argument that this assumption needs to change for high-value network infrastructure.
02
AI infrastructure is being scanned and exploited as fast as traditional enterprise software
LMDeploy exploited in 13 hours. Marimo in KEV last week. Azure SRE Agent cross-tenant data exposure the week before. The AI infrastructure attack surface is no longer a future concern being discussed at conferences. It is producing active KEV entries and documented exploitation incidents at the same rate as traditional enterprise software vulnerabilities. The teams deploying LLM serving infrastructure, model gateways, and AI agent frameworks need to apply the same patch urgency and network hygiene that production application teams apply to their web servers and databases. That alignment has not happened at most organizations yet.
Past issues · 7-day archive