A fully patched Ivanti VPN gave an attacker root through a three-flaw chain; two flaws are fixed, one is not

A fully patched appliance, three chained flaws, two fixes

Volexity says the Ivanti Connect Secure (ICS) VPN appliance it investigated was "fully patched (at the time, version 22.8R2.4)", and that an attacker it tracks as UTA0576 still gained "unauthenticated root-level code execution" on it by chaining three zero-day flaws. Volexity found exploitation starting on 3 October 2026. Ivanti's advisory, Volexity's post, the CVE record and CISA's Known Exploited Vulnerabilities (KEV) listing all appeared on 13 October.

The arithmetic of the fix is short (all derived from the sources read for this briefing). Three flaws were chained. Two of them, an authentication bypass and a remote code execution bug, are tracked under CVE-2026-104935 on Volexity's account. Ivanti lists four fixed builds for the CVE, 22.8R2.5, 25.1.1.2, 25.1.3.0 and 25.1.3.1, across two release lines. The third, a privilege escalation, has no CVE ID in the record, no fix, and no mention in Ivanti's advisory as read. Ten days passed between the first exploitation Volexity found and the public advisory and KEV listing, and the KEV due date for US federal agencies is three days after the listing.

That is not quite the story the headlines tell. "Fully patched" was true of the appliance only in the sense that it ran the newest build of its line. Ivanti dates 22.8R2.5, the first fixed 22.8 build, to 12 October, nine days after the first exploitation Volexity found (derived), so the first two flaws had no fix on that line either when it was exploited. The third flaw is the one that will still have no fix after an organisation installs a fixed build today. On Ivanti's own account a fix for "a portion" of the vulnerability had already shipped in July, in a release Ivanti says needs a new platform. The label "patched" described a build's place in a release list, not the state of the flaws inside it.

What the record does not establish is most of what an operator wants to know: how many appliances were affected (Ivanti says "a limited number of customers at the time of disclosure"), who UTA0576 is, which builds contain the third flaw and when it will be fixed, whether the fixed builds alone stop this chain, whether working exploit code is public, and what the attacker actually obtained from the directory. The sections below set each out with who said it, then the UK clocks and duties, then an ordered checklist. Defender level only: this briefing reproduces no indicator, request pattern, path or file name from Volexity's post.

How this was read. Ivanti's advisory needs scripts to display, so it was read in a browser at about 19:56 BST on Tuesday 13 October 2026 and its version table and FAQ re-read at about 20:02. Volexity's post, the NVD and CVE.org records, CISA's KEV catalogue file, and the NCSC, ICO, Microsoft and Cyber Essentials pages were read directly, from 19:54 BST. Ivanti's recovery-steps article sits behind a customer sign-in and was not read: no account was created and nothing was submitted. SecurityWeek's report was used as a pointer, and every figure in it was checked against the primaries.

Where the primary sources differ

The four primary records were each read in full. They do not describe the event in the same words, and where they differ this briefing follows the vendor's own page and says so.

Points on which Ivanti's advisory, Volexity's post, the CVE record and the KEV entry differ, read on 13 October 2026, and how this briefing treats each.

Point	What the sources say	How this briefing treats it
How many vulnerabilities	Ivanti: "one high severity vulnerability". Volexity: three zero-day flaws, two of them tracked under CVE-2026-104935. CVE record: one weakness class (CWE-290), an authentication bypass by spoofing that allows arbitrary commands.	Three flaws is Volexity's count and is attributed to it. Ivanti's advisory does not say how many flaws sit under the CVE.
Build dates	Ivanti: 25.1.1.2 released 5 October, 22.8R2.5 released 12 October, 25.1.3.0 released July 2026. Volexity: the vulnerability "was fixed in patches released on October 13, 2026".	Follows Ivanti's page. Neither source explains the difference.
The newest build	Volexity: 22.8R2.4 "at the time of writing is the latest version". Ivanti: 22.8R2.5 (12 October), 25.1.1.2 (5 October) and the 25.1.3 builds (from July) exist.	22.8R2.4 was the newest build of its line when exploited, not the newest Ivanti release.
Affected builds	Ivanti: 25.1.1.1 and prior, 25.1.2.2 and prior, 22.8R2.4 and prior. CVE record: "before version 25.1.3.0", with 25.1.3.0, 25.1.3.1, 22.8R2.5 and 22.7R2.14 listed unaffected and no mention of 25.1.1.2. Volexity: upgrade 25.1.1 and prior, 25.1.2 and 22.8R2.4.	Follows Ivanti's table. A scanner keyed to the CVE record's wording could flag a patched 25.1.1.2 appliance (inference).
The third flaw	Volexity: a privilege escalation, with a fix in "a future release in the coming weeks". Ivanti's advisory, the CVE record, the NVD page and the KEV entry do not mention it. SecurityWeek: "the vendor plans to fix it".	The plan is Volexity's report of Ivanti's work. No Ivanti page read says it.

The chain at the level a defender needs

Volexity describes three flaws. This briefing says what each gave the attacker and does not reproduce how.

The three chained flaws as Volexity describes them in its post of 13 October 2026, with their status as read on the same day.

Flaw, in Volexity's order	What it gave the attacker	Status as read on 13 October
1. Authentication bypass	Requests could reach scripts that normally need a sign-in, because the part of a request that is checked for permission is not the part that decides which script runs.	Under CVE-2026-104935. Fixed in the four builds.
2. File write leading to remote code execution	A flaw in an upload handler that Volexity says becomes code execution through a timing window, running as the web-facing service user.	Under CVE-2026-104935 (Volexity's count). Fixed in the four builds.
3. Privilege escalation	A privileged maintenance service trusts a shared configuration store that the web-facing process could alter in memory, giving root.	No CVE ID in the record. No fix. Not in Ivanti's advisory. Volexity: a future release in the coming weeks.

After the chain, Volexity says the attacker acted like an operator reading results, not a script running (high confidence). It extracted credentials stored on the appliance, including domain credentials used for directory lookups. It exported limited Active Directory metadata. It used a custom tool to test credentials against Kerberos and a custom tool to query the directory, through the appliance's own directory service account, for LAPS local administrator passwords, BitLocker recovery information and password-bearing attributes. It ran local DNS and host reconnaissance, collected the appliance's configuration including its authentication methods, and ran password spraying against directory accounts. It captured traffic on the appliance and inspected the directory-lookup part of it for credentials, and read the appliance's authentication logs to find valid usernames. It also removed entries from two of the appliance's logs.

Two properties matter for hunting. First, there was no implant. Volexity says commands and results travelled inside the exploit chain's own web requests, the whole chain ran again for every command, and there was "no backdoor or web shell". Anything that looks for a planted file will find none. Second, the chain left little to find on disk. Volexity says the privilege escalation altered library code in memory only and put the configuration store back as it was, and the attacker trimmed the appliance's logs. Volexity reconstructed the chain from memory images and crash dumps of the appliance, collected with Ivanti's help. It also says the extent to which each cleanup step worked on the victim "has not been fully established".

One distinction the summaries blur: a search is not a result. Volexity says the directory tool searched for LAPS passwords, BitLocker recovery information and password-bearing attributes through the appliance's service account, and that the results were written out and taken through the exploit channel. It does not say what the results contained. Whether any LAPS password or recovery key came back depends on what that account was permitted to read, and the post does not state it. The safe reading for planning is that anything the account could read is exposed. The factual reading is that the record shows the search, not the haul.

What "fully patched" meant, build by build

Ivanti's advisory has a version table that maps three groups of affected builds to fixed builds, read here by row, and solution text that adds dates and platform notes. The table below combines them. "Not stated" means the advisory gives no date.

Builds named in Ivanti's advisory for CVE-2026-104935, read on 13 October 2026. Status and dates are Ivanti's wording; the version table was checked against a rendered view of the page.

Build or range	Ivanti's status	Date and notes as Ivanti states them
22.7R2.14 and prior	Not affected	The advisory says "22.7.14 and lower" in one place and 22.7R2.14 in another. 22.7 reaches end of life on 31 January 2027.
22.8R2.4 and prior	Affected	22.8R2.4 is the build in Volexity's case (build 19097). 22.8 is called a temporary bridge and reaches end of life on 31 January 2027.
22.8R2.5	Fixed	Released 12 October 2026. For customers who cannot move at once to 25.1.1.2.
25.1.1.1 and prior	Affected	Listed for ISA6000 or ISA8000 appliances.
25.1.1.2	Fixed	Released 5 October 2026. Ivanti's recommended target for 22.8 customers.
25.1.2.2 and prior	Affected	No 25.1.2 build is listed as fixed. The table row points to 25.1.3.0 or 25.1.3.1.
25.1.3.0	Fixed ("do not contain this vulnerability")	Released July 2026, day not stated. Needs the new platform: ISA4500, ISA6500 or ISA8500 hardware, or a new virtual or cloud build from the 25.1.3.0 template.
25.1.3.1	Fixed	Not stated. No release date on the advisory.

Counted from that table (derived): four fixed builds, across two release lines (22.8 and 25.1) and three trains (22.8R2, 25.1.1 and 25.1.3). Three of the four are dated before the 13 October advisory: July, 5 October and 12 October. The fourth, 25.1.3.1, has no date on the page. Ivanti's FAQ explains why fixes arrived out of order: it "initially discovered a portion of this vulnerability" itself, "patched it in the July release 25.1.3.0", and "had been working to backport the fix to the remaining supported versions when exploitation occurred". Which portion it found, and when it learned of the exploitation, are not stated. The July release is between 74 and 104 days before the advisory, and 64 to 94 days before the first exploitation Volexity found (derived; the day of the month is not stated).

Do the fixed builds break the chain, or is the third flaw required? On Volexity's account the first two flaws gave code execution as the web-facing service user and the third turned that into root, so root needed all three. Ivanti says updating to a resolved version resolves the CVE. Read together, that suggests (inference) that a fixed build closes the unauthenticated way in that Volexity saw, so this chain no longer reaches root from the network by that route. It does not remove the third flaw. The record does not say whether the 25.1.3 builds contain the third flaw, whether another route to code execution on the appliance exists, or whether variants of the first flaw's technique exist; Volexity itself says threat actors are likely to find additional paths for the first exploit. And an upgrade does not undo what an attacker took before it. Volexity says the chain left no implant and the operation was disrupted, so for a given appliance an upgrade neither shows nor reverses what was taken (inference).

"High" beside "root": what the 8.6 rates

Severity records for CVE-2026-104935 read on 13 October 2026 from the CVE record, the NVD record and the advisory. CISA's entry in the CVE record is attributed to CISA as Authorized Data Publisher.

Who	Rating	What it rests on
Ivanti, as CVE Numbering Authority (advisory and CVE record)	8.6, High. CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:L	The CVE as written: an authentication bypass that allows arbitrary commands. Confidentiality High, integrity Low, availability Low. The advisory prints version 3.0 of the standard, the CVE record 3.1.
NVD	No score of its own. Status "Undergoing Analysis" when read at 18:54 UTC	Shows Ivanti's score as a secondary source. The record may change.
CISA, in the CVE record	Exploitation active. Automatable yes. Technical impact total	A decision-tree record, not a CVSS score. The KEV entry gives known ransomware use as "Unknown".
This briefing (derived)	9.8 if integrity and availability were rated High on the same vector	Standard CVSS 3.1 arithmetic, run for comparison. Nobody has published it for this flaw.

The 8.6 is Ivanti's rating of the CVE as written: an authentication bypass that lets a remote unauthenticated attacker run arbitrary commands. Volexity says the root step belonged to the third flaw. So the "high" label sits beside "root on the VPN" without covering it (inference from Volexity's description and the vector): the root step has no CVE ID and no score as read. CISA's own record says technical impact is total. The distinction does not change the UK patching clock, because under Cyber Essentials either a vendor's "high risk" description or a CVSS base score of 7 or above triggers it. It does change what "we patched the high one" means.

The clocks, with the arithmetic

Every interval below is derived from dates the sources state, and the arithmetic is in the build record. Where a source gives a month without a day, the interval is a range.

Intervals derived from the dates in Ivanti's advisory, Volexity's post, CISA's catalogue file and Cyber Essentials v3.3, read on 13 October 2026.

Interval	Result (derived)	Read from
First exploitation Volexity found (3 October) to the advisory, CVE publication and KEV listing (13 October)	10 days	Volexity, Ivanti, CVE.org, CISA
KEV listing to the KEV due date (16 October)	3 days	CISA catalogue
First exploitation to Volexity opening its investigation (5 October)	2 days	Volexity
First exploitation to Volexity indicators reaching its own customers (10 October), then to the public posts	7 days, then 3 more	Volexity
Release of 25.1.1.2 (5 October) and of 22.8R2.5 (12 October) to the advisory	8 days and 1 day	Ivanti
Release of 25.1.3.0 (July, day not stated) to the advisory	74 to 104 days	Ivanti
Cyber Essentials 14 days from release: 25.1.1.2, then 22.8R2.5, then counted from the advisory	19 October, 26 October, 27 October	Cyber Essentials v3.3, Ivanti
13 October to the end of life of 22.7 and 22.8 (31 January 2027)	110 days	Ivanti
Length of the intrusion Volexity describes	Not stated	Volexity gives a start and says it was disrupted, with no date

Context from the catalogue. CISA's catalogue file (version 2026.10.13, released 16:36 UTC) holds 14 entries with "Connect Secure" in the product name (derived): six under the Ivanti-era name and eight under "Pulse Connect Secure", the earlier name, all added on 3 November 2021. This is the first Connect Secure listing in 557 days, since 4 April 2025 (derived).

CISA KEV entries with Connect Secure in the product name, from the catalogue file of 13 October 2026. The window is the days from listing to the due date.

Listed	CVE ID	Days to due date (derived)
13 October 2026	CVE-2026-104935	3
4 April 2025	CVE-2025-22457	7
8 January 2025	CVE-2025-0282	7
31 January 2024	CVE-2024-21893	2
10 January 2024	CVE-2023-46805 and CVE-2024-21887	12
3 November 2021	Eight Pulse Connect Secure entries	181

The KEV entry for CVE-2026-104935 as read in CISA's catalogue file, field by field. The required action is paraphrased.

Field	As read
Name	Ivanti Connect Secure Authentication Bypass by Spoofing Vulnerability
Short description	"Ivanti Connect Secure contains an authentication bypass by spoofing vulnerability that allows a remote unauthenticated attacker to execute arbitrary commands."
Required action	Apply mitigations as the vendor instructs, in line with CISA's BOD 26-04 and its forensic triage requirements. Follow the directive's guidance for cloud services, or discontinue use of the product if mitigations are unavailable.
Due date; ransomware use; forensic triage	16 October 2026; "Unknown"; "Yes"
Notes	Two links: Ivanti's advisory (printed with a broken protocol prefix) and the NVD record. The required action says to see the Notes for the directive and the triage requirements, and the Notes hold neither.

The entry is flagged for forensic triage, as are 80 of the catalogue's 1,740 entries (derived). BOD 26-04 says that for those entries the agency must complete remediation or mitigation within three days and carry out a forensic triage to assess whether the system is compromised. The directive binds US federal civilian agencies. For a UK reader the due date is a signal of urgency, not a duty. The triage sequence in its implementation guidance is still a published order of work: scope, preserve volatile evidence, then patch, contain, analyse, and decide on escalation.

Six labels that sound like safety

A label is not a control. Six appear in this story, each from a source with a reason to use it.

Labels in the story, where each appears and what the record shows.

The label	Where it appears	What the record shows
"Fully patched"	Volexity ("fully patched (at the time, version 22.8R2.4)") and SecurityWeek's headline.	The newest build of its line when exploited. No fixed 22.8 build existed until 22.8R2.5 on 12 October, though a fixed release, 25.1.3.0, had shipped in July on a line that needs a new platform. After upgrading, the third flaw still has no fix.
"High severity" (8.6)	Ivanti's advisory and SecurityWeek.	A rating of the CVE as written, with integrity and availability Low. The root step is the third flaw, with no CVE ID. CISA's record says technical impact total. The same vector rated 9.8 if integrity and availability were High (derived).
"A limited number of customers"	Ivanti's advisory, "at the time of disclosure".	No count is given, and customers are not appliances. The case was found through one Volexity customer's monitoring. The tool and logs that would show other cases are the ones this chain evaded, so it is likely a count of cases found, not of appliances exposed (inference).
"Integrity check passed"	Ivanti's FAQ tells customers to run the Integrity Checker Tool regularly.	Volexity says the tool "does not detect any modifications" from this chain, and that it "may not be able to identify device compromise". A pass establishes nothing about this chain.
"No backdoor or web shell"	Volexity.	That is how the chain works, not a sign of a clean device: each command re-runs the chain in ordinary web requests. Hunting for implants returns nothing by design.
"Zero-day"	Volexity and SecurityWeek.	True for the build exploited. Ivanti says it found "a portion" of the vulnerability itself and fixed it in July, so the vendor may have known of part of it before the exploitation. Which part is not stated.

What the record does not establish

The table sets what is stated against what is not. "Not stated" means not found in the Ivanti advisory, Volexity's post, the CVE and NVD records or the KEV entry. It does not mean the information does not exist.

Questions an operator would ask, what the primary sources state, and what they do not, read on 13 October 2026.

The question	Stated, and by whom	Not stated
How many appliances?	Ivanti: exploitation affecting "a limited number of customers at the time of disclosure".	A count of customers or appliances, or how many have been checked.
Who is UTA0576?	Volexity: an unknown threat actor. Low confidence in a criminal rather than espionage motive, "based on the target of this activity". KEV: ransomware use "Unknown".	Any named group, state link, country or ransomware link, or what the target was.
The third flaw	Volexity: a privilege escalation, no fix yet, a future release "in the coming weeks".	A CVE ID, a score, the affected builds (including whether the 25.1.3 builds contain it), a mitigation, or a date. Ivanti's advisory does not mention it.
Do the fixed builds alone stop this chain?	Ivanti: updating resolves the CVE. Volexity: apply the patches.	Whether other routes to the third flaw exist, or whether variants of the first two exist. Volexity expects the attacker to look for more paths.
Is the exploit public?	Volexity describes the mechanics in detail and publishes related indicators. Ivanti: "limited indicators of compromise available".	Whether working exploit code is public or on sale. This briefing does not reproduce Volexity's detail.
What does "no web shell" mean for hunting?	Commands travelled in the exploit's own web requests. Entries were removed from two logs.	How many requests, over what period, how many other appliances saw them, or whether the log edits fully worked ("has not been fully established").
Did the attacker obtain LAPS passwords or BitLocker keys?	A custom tool searched for them through the appliance's directory service account, and the results were taken out.	What the results contained, or what that account could read.
How long was the access?	Earliest evidence 3 October. Volexity opened its investigation on 5 October. The operation was "detected and disrupted".	The date of disruption, the total dwell or the attacker's goals.
When did Ivanti learn of the exploitation?	Ivanti found "a portion" itself and fixed it in July. 25.1.1.2 shipped 5 October and 22.8R2.5 on 12 October. Volexity worked with Ivanti once it suspected a chain.	The date Ivanti learned of exploitation. The CVE.org record shows the ID was reserved on 2 October, but a reservation is not a discovery date.
Did the attacker use large language models?	Volexity: medium confidence, from three observations about the attacker's tooling and chain.	Which model, how it was used, or how a skilled human operator was ruled out.

Who says what, what each sells, and the language-model claim

Ivanti sells the appliance and wrote the advisory, so its statements that exploitation affected "a limited number of customers" and that the fixed versions resolve the vulnerability are the vendor's own. Volexity sells memory forensics products, incident response and threat intelligence, and its post reconstructs the chain using its own memory-analysis product, in an investigation at one of its monitoring customers. The post also thanks OpenAI for access under its Trusted Access for Cyber programme and says OpenAI's cyber models have cut Volexity's analysis time. OpenAI sells AI models, and the post does not say any model took part in the assessment of the attacker below. CISA and the NCSC are public bodies with no product to sell.

Volexity "assesses with medium confidence" that UTA0576 uses large language models for exploit development and post-exploitation, "as with many other threat actor operations" it has investigated in 2026. Its stated basis is three observations: commands were passed through the exploit channel rather than a simpler web shell, specific scripts were deployed repeatedly with hardcoded credentials rather than generic utilities, and the exploit chain was complex. That is an inference from artefacts by a vendor, not a sighting of a model, and it should not be repeated as a fact about the attacker. The post does not say which model, which deployment, or how a skilled human operator was ruled out. Volexity separately says with high confidence that the attacker was interacting with the results of its commands rather than running a script. For a defender the assessment changes no control on the checklist below. The motive assessment is weaker still: low confidence that the motive is criminal, with the nature of the target not stated.

The UK: the NCSC, the 14 days, the 72 hours and the supplier question

No NCSC alert on this CVE appeared in the NCSC's news feed when it was read at about 19:59 BST on 13 October. Its nearest published advice is for other vendors' gateways, and it reads across. Its 28 September alert on Citrix NetScaler Gateway says to "isolate the affected system(s) and replace with a new, fully up-to-date system". Its 18 June alert on Fortinet VPN gateways says to factory reset because "changing credentials alone may not be sufficient", after taking logs and configurations first. Its 27 August alert tells organisations outside operational technology to keep an inventory of internet-facing systems and edge devices, apply vendor updates promptly, retire end-of-life equipment and watch for unexpected configuration changes or outbound connections. Its 29 July blog says forensic observability for network devices includes collecting forensic data from both memory and data at rest, which is what Volexity says it relied on here. The NCSC's free Early Warning service is open to UK organisations.

UK instruments as read on 13 October 2026, and where each stops.

Instrument	What it says	Where it stops
Cyber Essentials Requirements for IT Infrastructure v3.3, April 2026, security update management	Software in scope must be updated "within 14 days" of release where the vendor calls the fix critical or high risk, or the CVSS v3 base score is 7 or above. "Software" includes network software and firewall and router firmware. It must be supported, and removed or put in a sub-set with no internet traffic when it is not.	Does not name VPN appliances. Ivanti says high and scores 8.6, so the 14 days apply either way. The text counts from release of the update, so 25.1.1.2 reaches day 14 on 19 October and 22.8R2.5 on 26 October (derived). It does not say whether the clock starts when a vendor first describes the fix as high risk. A VPN gateway cannot sit in a sub-set with no internet traffic (inference), so end of life on 31 January 2027 means replacement.
ICO guide to personal data breaches	A notifiable breach is reported "within 72 hours of becoming aware of the breach, where feasible". Information can follow in phases. A decision not to report must be justified and documented.	The clock starts on awareness of a breach, not on the advisory. Whether stolen directory credentials and metadata make a notifiable breach is the organisation's own risk assessment. A processor must tell the controller "without undue delay".

The sources for the table are the Cyber Essentials requirements v3.3 and the ICO's guide, both read in full on 13 October.

What stolen credentials mean in practice. Volexity says the attacker took credentials stored on the appliance, including domain credentials used for directory lookups, and went looking for LAPS passwords and BitLocker recovery information. Windows LAPS stores each machine's local administrator password in the directory, and Microsoft says access control lists and optional encryption govern who can read them. Microsoft also says that having a BitLocker recovery password "allows the holder to unlock a BitLocker-protected volume and access all of its data", and that old recovery passwords are not removed from the directory automatically. So the order to rotate is the appliance's directory service account first, then any secret held in the appliance's own configuration, then LAPS passwords and BitLocker recovery passwords for the machines that account could read, with the old recovery passwords removed. A recovery password matters most for disks an intruder can physically obtain, such as laptops (inference). Directory accounts that were sprayed, or whose usernames were read from the appliance's logs, warrant a check for new sign-ins. Staff credentials and account metadata are personal data, which is why the ICO question belongs on the same day as the technical ones.

What to do, in the order worth doing

Every item names its source. The order is the order this briefing would work in, and item 3 is a judgement the reader should make, not a rule.

Two earlier briefings on this site cover the same pattern on other gateways. One covers a NetScaler flaw exploited at least 22 days before its patch with a three-day federal clock, and the other a SonicWall SMA1000 advisory that lists the September fix builds as affected. In both, as here, a patch or a newest build did not settle whether an appliance was safe.

What could not be verified

• Ivanti's recovery steps. The article the advisory links for suspected exploitation requires a customer sign-in. It was not read, no account was created and nothing was submitted.
• Volexity's indicators. Its post points to a GitHub page of related indicators. It was not read and nothing from it is reproduced.
• Customers and appliances affected. Not stated by any source.
• The third flaw. Its existence, its description and the "coming weeks" come only from Volexity. No Ivanti page read mentions it. No CVE ID, score, affected-build list or mitigation was found.
• Independent confirmation. No replication of Volexity's findings and no second vendor's report was found in a limited search.
• Other agencies. No NCSC alert on this CVE was found in the NCSC's news feed at about 19:59 BST. No CISA alert or advisory page on it was found in CISA's advisory feed at about 20:05 BST. The CISA record read is the KEV entry. Table 1 of BOD 26-04 is an image and was not read as text, and its three-day rule is read from the directive's text.
• Time zone. Ivanti's advisory prints creation and modification times without a zone, so they are not used.
• Time-stamped. Sources were read between 19:54 and 20:15 BST on 13 October 2026. NVD's analysis, Ivanti's advisory, a fix or mitigation for the third flaw, or an NCSC alert could appear within hours.

The question that exposes the gap

If an attacker had root on your VPN appliance from 3 October, what evidence you hold today, other than the appliance's own integrity tool and its own logs, would show it?

Key facts