A fix closes the hole but says nothing about the days before
When a flaw is attacked before a fix exists, installing the fix tells you the hole is closed. It does not tell you whether someone already came through it.
Conceptual illustration of the 47 days between the first attack and disclosure in the BeyondTrust case. A patch closes the flaw but does not show whether the device is clean.
An edge device is a system that sits on the border of your network and faces the internet. VPN gateways, remote support tools, email gateways, firewalls and load balancers are all edge devices. They are reachable from outside, they hold powerful access, and many teams cannot see much of what happens inside them.
A zero-day is a flaw that attackers use before the vendor has released a fix. This article uses two recent cases to show what a patch does and does not settle. It ends with a method you can follow for any exploited edge device, and a rule for deciding when to rebuild instead of trusting.
Why edge devices are worth attacking
An edge device is a good target for three plain reasons. It is exposed to the internet by design. It often holds stored credentials or a trusted position inside your network. And it usually runs a locked-down operating system, so you cannot easily install your own monitoring on it.
That last point matters more than it looks. If you cannot inspect the device from the inside, the vendor’s checks and your logs become your only evidence. Both can fail, as the next two cases show. Our earlier piece on what a 72-minute breach window means explains why the time before you notice matters so much.
Case 1: Ivanti Connect Secure, where part of the chain is still open
Ivanti Connect Secure is a VPN gateway. On 13 October, Ivanti published an advisory for CVE-2026-104935, a flaw that lets an attacker bypass authentication and run commands on the device. CISA added it to its Known Exploited Vulnerabilities catalog the same day. The catalog is a list of flaws that CISA has confirmed are being used in real attacks, and federal agencies must fix them by a set date, which was 16 October for this one.
Security firm Volexity reported that the attacker began using the flaw on 3 October against one customer’s appliance. Volexity described that appliance as fully patched, and it ran 22.8R2.4, the newest build available before the fix. That is a single incident, so it shows the flaw was used before disclosure. It does not tell us how widely it was used, and Ivanti says only that a limited number of customers were affected. Fixed versions include 22.8R2.5, 25.1.1.2, 25.1.3.0 and 25.1.3.1, according to Rapid7’s summary of the advisory.
Two details make this case a good lesson. First, the attack chain has more than one step. Volexity reported a separate privilege escalation step, which raises access to root, that the fix did not cover at the time of disclosure. Coverage of the report says it has no public CVE ID. Volexity said a fix would come in a future release “in the coming weeks.” So for now, “patched” is only partly true.
Second, the attack left little behind. Volexity found no backdoor and no web shell. The exploit code and the root step ran mostly in memory, and the altered configuration data was restored afterward, so Ivanti’s Integrity Checker Tool did not detect the changes. Ivanti still advises customers to run the tool regularly. Volexity also found that the attacker selectively removed entries from the appliance’s debug and audit logs, and it says how far that cleanup worked is not fully established. Ivanti says limited indicators of compromise were available at disclosure, and Volexity published some from the one incident it investigated.
The lesson is plain. A fixed version number tells you what the device runs now. It cannot tell you what happened before, and a clean result from the vendor’s checking tool or from the device’s own logs is not enough on its own.
Accessible text alternative for this figure
Both flaws were exploited before they were disclosed. The timeline runs from 29 August to 15 October 2026 on one shared scale, with ticks at 29 August, 29 September and 15 October.
BeyondTrust Remote Support: exploitation began on 29 August, a patch was released on 8 October and the flaw was disclosed on 15 October. That is 47 days of exploitation before disclosure.
Ivanti Connect Secure: exploitation began on 3 October and the flaw was disclosed on 13 October, 10 days later. The root privilege escalation step was still unpatched at disclosure.
Case 2: BeyondTrust Remote Support, where the hunt starts in August
BeyondTrust Remote Support lets support staff control other people’s computers. It stores credentials in a vault so that staff can log in to systems on a user’s behalf, which makes it valuable to an attacker. CVE-2026-102764 is an unauthenticated file upload flaw, meaning an outsider can place a file on the device without logging in. It affects versions up to 26.2.3.
BeyondTrust says the first attack was on 29 August. It released the patch on 8 October, with its SaaS customers patched automatically, and disclosed the flaw on 15 October. By our count, that is 47 days between the first attack and disclosure. BeyondTrust says it knows of two affected customers, so this too is a small number of known cases.
Google assigns the activity to a group it calls ARMORY CASTLE, which it says was formerly tracked as UNC5221, and describes it as a suspected espionage actor linked to China. That is Google’s assessment of the evidence, not a finding we can confirm ourselves.
What the attackers did after getting in is the useful part. According to Google, they installed a web shell about eleven minutes after the first exploit request. They created a root backdoor, tried to harvest credentials from the vault, added a persistence script that survives a reboot, and deleted appliance, web server and application logs. Google states that persistence of this kind also survives a configuration reset.
Google’s advice follows from that. Preserve evidence before you change anything. If compromise is confirmed or you cannot rule it out, redeploy from a clean, fully patched image, because customers cannot audit the appliance’s own file system. Rotate credentials only after the patch or rebuild, since new credentials entered on a device the attacker still controls are exposed too.
Collect logs from systems around the device, such as the firewall and reverse proxy, because the on-device logs may have been deleted. BeyondTrust gives the same warning: copies kept off the appliance are often the only record left.
The lesson: your investigation window starts at the first date of exploitation, not at the date the patch was released. The device’s own logs are weak evidence if the attacker had control.
Smaller cases add smaller lessons
A first patch is not always a complete one. AhsayCBS, a backup server product, had two flaws that attackers chained together: an authentication bypass and a command injection that runs as SYSTEM. Help Net Security reported that earlier fixes were incomplete and that fixed builds are v10.3.4.45 and v9.15.2.70. If you applied an earlier build and moved on, check that you are on the fixed one. Attackers were reported to have planted web shells and cryptominers on exposed servers, and Huntress documented the attacks on 8 October.
Other recent edge flaws show why exact build numbers and speed still matter, even when there is no sign of earlier compromise. Citrix is a repeat case, and our piece on the September NetScaler zero-days covers the earlier flaws.
| Product | What happened | What to take from it |
|---|---|---|
| Citrix NetScaler (CVE-2026-107406) | A critical memory overflow flaw in SAML configurations, rated CVSS v4 9.5 and published on 8 October. Fixed in 14.1-73.46 and 13.1-64.29 or later. The bulletin lists 14.1-73.37 to 14.1-73.41 and 13.1-64.23 to 13.1-64.28 as affected and does not say whether the flaw is being exploited. | A recent build can still be affected. Check your exact build against the newest bulletin. |
| Cisco Secure Email Gateway (CVE-2026-76519) | CVSS 9.8, no workaround, exploited. Fixed in AsyncOS 16.5.0-780 on the 16.5 branch. Listed by CISA on 14 October. Cisco’s advisory says an attacker with root can hide evidence on the device, so check firewall and network logs outside it, and preserve forensic data before upgrading. For a compromised virtual appliance it says to deploy a new VM on a fixed release without importing the old configuration. | The vendor itself recommends evidence first, then a rebuild, then new credentials. |
| Palo Alto PAN-OS (CVE-2026-0322) | CVSS 8.6, “very limited exploitation” observed, no known workaround. It affects the management interface, and Palo Alto advises limiting access to trusted internal addresses or a jump box. | Keep management interfaces off the internet. |
A method you can follow
When an edge device you run is named in an exploited-flaw advisory, work through these steps in order.
- Patch or isolate. Apply the fixed version. If no fix exists yet, restrict access to the device and follow the vendor’s mitigation.
- Preserve evidence before you change anything. Take a snapshot or disk and memory copy if you can. Collect logs from the firewall, proxy and any log server.
- Find the first exploitation date. Read the vendor and researcher reports. Your search window runs from that date to now.
- Hunt back through that window. Look in logs held outside the device. Look for the indicators the researchers published. Treat gaps in log forwarding as a warning.
- Decide: trust or rebuild. See the rule below.
- Rotate credentials after the device is clean. Start with the device’s own administrator accounts. Then rotate anything it stored or brokered, including API secrets, service accounts and any password typed into it.
When to rebuild and when to trust
Rebuilding every device after every advisory is not realistic. Here is a rule we suggest. It is our judgement, built on Google’s BeyondTrust guidance, and not a published standard.
Rebuild from a clean image if the device is confirmed compromised. Rebuild too if exploitation began before your patch date and you cannot show that your device was not reached. The second condition matters most for appliances you cannot inspect from the inside.
You can reasonably trust the device after patching if three things are true. It was not exposed to the internet during the window, or you have independent logs showing no matching activity. Neither the vendor nor the researchers report access that survives patching. And you rotate the credentials the device held.
What we know, and what we do not
| Label | Statement |
|---|---|
| Fact | CISA lists the Ivanti flaw (13 October) and the BeyondTrust flaw (16 October) as exploited. BeyondTrust confirmed exploitation from 29 August and released a patch on 8 October. |
| Researcher report | Volexity says the Ivanti attack ran mostly in memory, evaded the integrity checker and removed log entries. Google says the BeyondTrust attackers deleted logs and installed persistence. |
| Our inference | Any appliance exposed during an exploitation window should be treated as possibly reached until shown otherwise. |
| Unknown | Whether Ivanti has now fixed the privilege escalation step. How many organisations were affected beyond the cases the vendors describe. |
How deeply to learn this
Know: Most developers and managers need only the idea. A patch closes a flaw and does not undo an intrusion. Ask your security team whether exploited flaws are checked back to the first attack date.
Use: If you run VPNs, gateways, remote support tools or backup servers, you need the method above. You should be able to read an advisory, find the first exploitation date, preserve evidence, check logs held off the device, and decide on a rebuild.
Master: If you own incident response or architecture, you also need to design for this. Forward logs off every edge device in near real time. Keep management interfaces off the internet. Keep clean images and tested restore paths so that a rebuild takes hours, not weeks.
What you can ignore for now
You do not need to memorise malware names, group names or file paths from these reports. They change with every incident, and the published indicators are useful to a hunt team but not to a general reader. What lasts is the shape of the response.
A practical next step
Pick one edge device you run and answer three questions. Where do its logs go, and are they stored somewhere an attacker on the device could not reach? How fast could you rebuild it from a clean image? Which credentials does it hold? If you cannot answer all three today, that gap is more important than the next patch.
Go deeper
- Volexity on the Ivanti Connect Secure zero-day chain for the attacker’s steps, the log tampering and the indicators.
- Ivanti’s October 2026 security update post for the vendor’s statement and the link to its advisory.
- Rapid7 on Ivanti Connect Secure CVE-2026-104935 for fixed versions and the CISA listing.
- BeyondTrust security advisory BT26-05 and its blog post for versions, dates and the patch.
- Google Threat Intelligence: ARMORY CASTLE exploits BeyondTrust for the intrusion steps and the rebuild and rotation guidance.
- Cisco advisory for CVE-2026-76519 for the compromise check and recovery steps.
- Palo Alto Networks advisory for CVE-2026-0322 for fixed versions and partial mitigations.
- Citrix bulletin CTX697191 for the exact affected and fixed NetScaler builds.
- Help Net Security on the CISA additions for the Ahsay details and the KEV dates.
- CISA Known Exploited Vulnerabilities catalog for the current status and deadlines of each flaw.
Facts in this article were checked on 18 and 19 October 2026. Vendors may release further fixes and details, so check the sources above before you act.