Five incidents disclosed between 13 and 21 October 2026 had one thing in common: the way in was something people trusted to be safe. Here is what happened, what to check if you run it, and where it comes from.
Cisco Secure Email Gateway: through the malware scanner
Cisco says attackers have been exploiting a flaw in the Advanced Malware Protection feature of its email gateway, the part that inspects incoming attachments (CVE-2026-76519). Where the File Reputation service is enabled and assigned to a mail policy, and Content Scanner Tools is older than 25.3.0.5525, one crafted attachment lets an unauthenticated attacker write files anywhere on the system and run commands as root. Cisco became aware of active exploitation in October 2026. It is the second flaw in that gateway added to CISA's catalog of exploited flaws since mid-September (14 September, 14 October).
If you run it: Cisco lists the fix in AsyncOS 15.5.5-014 and 16.5.0-780, and also distributes it through Content Scanner Tools 25.3.0.5525 or later to all licensed and supported releases; that update needs no restart and arrives on its own where automatic updates are on. AsyncOS 16.0 has no fixed AsyncOS build; Cisco recommends releases before 16.5 migrate to 16.5.0-780. Customers of Cisco Secure Email Cloud Gateway need no action to patch; Cisco contacted cloud customers whose devices showed signs of compromise. There is no workaround.
Never open the attachment. Nobody told the scanner.
Source: Cisco advisory
Ivanti Connect Secure: a fully patched VPN
Volexity reports that from 3 October an actor it tracks as UTA0576 broke into a fully patched Ivanti Connect Secure VPN appliance (CVE-2026-104935). It left no backdoor or web shell: for every command, it ran the whole exploit chain again. One step changed library code in memory only, so Ivanti's Integrity Checker Tool does not detect it. Volexity assesses, with medium confidence, that the actor uses AI models for exploit development.
If you run it: Ivanti's advisory gives the fixed versions as 25.1.1.2, 25.1.3.0, 25.1.3.1 and 22.8R2.5; Volexity said on 13 October that one step of the chain, the privilege escalation, would be fixed only in a future release; that flaw is now tracked as CVE-2026-111357. Ivanti's advisory does not yet cover it; watch Ivanti's advisories for a fix. A clean result from the Integrity Checker is not evidence that this chain was not used: Volexity says a forensic investigation is required.
Never kept a key. They commuted.
Sources: Volexity, Ivanti advisory
BeyondTrust Remote Support: no questions asked
BeyondTrust's Remote Support had an authentication bypass (CVE-2026-102764): it did not properly check where internal messages came from. Rapid7 reports two known compromises, which BeyondTrust dates to 29 August, one of them on an instance BeyondTrust hosted itself; BeyondTrust found and contained that one on 28 September. Mandiant attributes the activity to a suspected Chinese espionage group. BeyondTrust patched all its hosted customers by 9 October and disclosed the flaw on 15 October, nearly seven weeks after the first compromise. BleepingComputer reports that Shadowserver counts over 1,400 Remote Support instances exposed online.
If you run it: Remote Support 26.2.3 and earlier is affected, and versions older than 24.3.1 have to be upgraded before the patch applies. Self-hosted installations not subscribed to automatic updates have to apply the patch by hand. BeyondTrust also recommends patching self-hosted Privileged Remote Access, which shares the affected code. Mandiant's advice: treat an appliance that was reachable from the internet on a vulnerable version during the exploitation window as possibly compromised until it has been reviewed.
The call said it was coming from inside the house. The house found that reassuring.
Sources: Rapid7, BleepingComputer
OVHcloud's command-line tool: caught by one customer's build
On 19 October, the release files of five versions of OVHcloud's command-line tool, v0.11.0 to v0.15.0, were replaced with builds carrying a credential stealer, for up to 94 minutes; the advisory counts about 250 downloads. OVHcloud says its source code and build chain were not affected, and traces the compromise to a malicious extension, color-picker-universal 2.8.91, installed on a developer's personal MacBook a year earlier. A customer caught it: their build had pinned the exact fingerprint of the download and started failing when it changed.
If you run it: OVHcloud's advice is that if you downloaded the tool between 14:47 and 16:21 (UTC+2) on 19 October and ran it, every secret stored on that computer should be considered compromised.
Most builds fail for no reason. This one had one.
Sources: OVHcloud advisory, the customer's report
LiteLLM: its own release pipeline, pointed at a hyphen
LiteLLM, a widely used open-source library for calling AI models, was compromised on 21 October, its second compromise this year. After the first, in March, it had hardened its release pipeline. This time someone holding three sets of stolen developer credentials switched off branch protection and changed the release workflow to build from a lookalike copy of the project: Berri-AI/litellm instead of BerriAI/litellm.
If you run it: the bad release was litellm 1.107.0. It could be installed from the package index from 11:39 to 13:23 UTC on 21 October, and the v1.107.0, latest, main-latest and main-stable Docker images pulled from 11:46 to 14:20 UTC that day were bad. The v1.107.0 image was removed, and LiteLLM says it pointed the others at clean images. If you installed or pulled in those windows, follow LiteLLM's incident page.
Healing isn't linear.
Source: LiteLLM incident page
Top comments (2)
The Ivanti entry has the line I would move to the top of the post. "A clean result from the Integrity Checker is not evidence that this chain was not used."
That is a worse category than an unpatched box. The appliance was fully patched, the actor left no artefact, and the vendor's own tool reports healthy. Three of the usual answers to "are we exposed" come back green, and the green is accurate about the wrong question. The checker was built to find a file that is not there, and the step that mattered changed library code in memory.
The habit that falls out of it costs nothing: for every tool you rely on to tell you that you are clean, write down the sentence it actually settles. The Integrity Checker settles "the files on disk match what we shipped." It does not settle "nobody has run code here." On a dashboard at 3am those read the same, and the gap between them is where the rest of your five live. Cisco's scanner settled "this attachment matched no known signature" and was itself the way in.
The BeyondTrust timeline is the one I would be loudest about. First compromise 29 August, contained on a vendor-hosted instance 28 September, disclosed 15 October. If you are self-hosted and not on automatic updates, the vendor fixed itself roughly seven weeks before it told you, and the only reason you can size your own exposure window now is that Mandiant wrote the dates down. Worth checking whether your vendors commit to a disclosure interval in writing, because very few do, and "patched all hosted customers first" is a defensible engineering call that still leaves self-hosted customers last in a queue they never saw.
On the AI attribution, keep Volexity's hedge where you have it. Medium confidence on exploit development is a long way from the headline that will get written off it.
Thanks for making the case so well that someone has to stick up for the vendors. Fine. Me.
In fairness to Cisco's scanner, it did open the attachment.
In fairness to Ivanti's Integrity Checker, every file was innocent.
In fairness to BeyondTrust, it didn't sit on it for seven weeks. That was the attackers' head start. It only knew for 17 days, and every customer it hosts was patched at least six days before the self-hosted ones heard.
In fairness to Remote Support, it supported someone remote.
In fairness to the headline, it hasn't been written yet.
hmm... I'll stop helping.