Security Advisory
Ivanti Connect Secure Zero-Day Chain: What Would Have Limited the Damage (CVE-2026-104935)
November 3, 2026 · 14 min read
The first Ivanti Connect Secure customer Volexity examined was fully patched. That is the point: when the bug is a zero-day, patching is not the defence, the blast radius is. We read Ivanti’s own datasheet against the chain, then set out what the vendor could have built differently, seven patterns a buyer can build around the appliance, and the second line of defence for anyone with a VPN in front of Active Directory.
What happened, in six lines
- Volexity found a previously unseen actor, UTA0576, chaining three Ivanti Connect Secure flaws for unauthenticated code execution as root. Repeated exploitation began October 3; Volexity published on October 13.
- CVE-2026-104935 (authentication bypass leading to command execution, CVSS 8.6) was patched and added to CISA’s Known Exploited Vulnerabilities (KEV) catalog on October 13. CVE-2026-111357 (privilege escalation) and CVE-2026-118527 (file placement) were patched October 29 and added to KEV October 30.
- The actor left no web shell or backdoor. It re-ran the chain for each command, carried results back inside the HTTPS responses, and removed recent entries from the appliance’s debug and audit logs.
- From the appliance it took stored LDAP credentials, then used a service account to read LAPS passwords and BitLocker recovery keys from Active Directory, and ran Kerberoasting and password spraying.
- Volexity’s assessment: preparation for lateral movement. The operation was disrupted, so the end goal is unknown.
- Fixed builds: see the reference table at the end. Confirm against Ivanti’s advisory for your branch.
Plenty of outlets have covered the timeline. This post is about something they have not: what would have changed the outcome, for the vendor and for you.
What the datasheet promises, and what the chain did
Ivanti’s own Connect Secure datasheet is a good place to start, because it shows what a buyer is told they are getting. Read against the chain, it is a strong story about who gets through the gateway and how the tunnel behaves, and a quiet one about what happens when the gateway itself is the target. The table matches each claim to what it is built to stop and to what the public record says the attacker did. We do not know which exploited appliances had which features enabled, so where that matters we say so; treat the right-hand column as questions to put to the vendor, not verdicts.
| What the datasheet says | What it is built to stop | What the chain did |
|---|---|---|
| Conditional access, adaptive MFA and posture checks before authentication | Which users and devices may log in | The first step bypassed authentication, so these policies were never evaluated. The attack went at the gateway’s own pre-authentication code, which sits outside every access policy |
| Root Privilege Avoidance: processes run with least privilege (listed as a 25.x feature) | Limits what a compromised component can do | The chain ended in root code execution through a privilege-escalation flaw, CVE-2026-111357. CISA’s affected list includes 25.1.x builds. Public reports do not say which exploited appliances had the hardening active |
| SELinux in enforcing mode by default | Confines what processes can touch | Reports describe a library patched in memory and a root service running attacker code. They do not say SELinux stopped any step. Treat it as a mitigation, not a boundary you have verified |
| Secure boot with TPM integrity checks; per-gateway keys and disk encryption | Boot-time tampering and data at rest | The attack ran in memory on a booted, unlocked system, and stored credentials were read from the live appliance. Neither control looks at that |
| Integrity Checker Tool flags anomalies | Changed files | CISA says it may not detect exploitation of CVE-2026-104935 because commands run in memory, and a clean result does not rule out compromise |
| Integrated NGINX-based web application firewall for Layer 7 attacks such as SQL injection and XSS | Known web attack classes | The chain abused request routing and an upload race, which are not on that list. A firewall inside the box also shares fate with it. Whether you can drop a specific header before authentication is something to test, not assume |
| Debug-severity logs, email alerts, central logging through Neurons for Secure Access | Recording and reporting | The attacker removed recent entries from the local logs. A central copy only helps if it is streamed in real time and the appliance cannot rewrite it. The datasheet page does not mention forwarding to your own SIEM; ask |
| Behavioural analytics to identify risky user behaviour | Misbehaving users | The actor was the gateway itself. Nothing described here baselines the appliance as the subject |
| Multiple hostnames and virtual extranet sites on one appliance; up to 25,000 concurrent users on the largest model | Consolidation and scale | One compromised box holds the settings and stored credentials for every site on it. Concentration is a blast-radius decision |
| FIPS 140-2 and 140-3 certification | A validated cryptographic module | Says nothing about a bypassable request path. A certificate describes a component, not your exposure |
| SAML 2.0 as both identity provider and service provider, OIDC, certificate authentication | Lets the appliance avoid holding a directory password | An opportunity, not a gap: used well, it leaves less on the box for an intruder to take |
| Per-app VPN, dynamic role mapping, split tunnelling | Narrow what a session can reach | An opportunity: the more you use them, the less a stolen session or a compromised gateway reaches |
| Virtual appliance on VMware, KVM, Hyper-V, Azure, AWS and GCP | Deployment flexibility | An opportunity: CISA’s recovery steps say to rebuild virtual instances, and a hypervisor can capture memory from outside the box and replace it from an image |
The pattern is consistent. The datasheet is organised around the user’s journey through the gateway. The chain attacked before that journey began, and finished by controlling the box that enforces it. A buyer should therefore evaluate two different things: access control (who gets in) and survivability (what happens when the box is lost). The rest of this post is about the second.
Part 1 — What could have protected Ivanti
Based on Volexity’s technical description, three design patterns in the chain are worth studying. This is our reading of the public record, not an accusation: any team shipping an internet-facing product, including SaaS startups that sell to enterprises, can ask the same questions of their own code.
| What the chain did | Design pattern behind it | What would have broken it |
|---|---|---|
| A request header chose which internal script ran, and an unauthenticated request could set it | Trusting a client-supplied value to make a routing and authorisation decision | Never let external requests carry internal routing headers: strip them at the edge of the process, and authorise on the server side for every route, not only for the login path |
| An uploaded script could be run before the handler deleted it | A check-then-act race: the file is available and executable in the window between write and delete | Write uploads to a non-executable location, never run from the upload path, and make delete-after-use unnecessary by never executing user content at all |
| A maintenance task made a root-privileged service run attacker-supplied code | Privileged service reading its instructions from a place a lower-privileged component can influence | Privilege separation: run request-handling components as unprivileged accounts, and make anything the root service executes read-only and integrity-checked |
| Ivanti says it fixed “a portion” of the bug in July’s 25.1.3.0 release, but attackers used the unfixed remainder first | An incomplete fix: the same bug family survived the first patch | Variant analysis after any fix: ask what else shares the code path and fix the family, not the one report. Ivanti says it was backporting to older branches when exploitation began |
| The attack lived in memory, so the on-disk integrity check saw nothing | Integrity verification that looks at files, not at the running process | Runtime attestation of loaded code, and logs streamed off the device by default so a root attacker cannot edit the record |
The Register notes this is the third consecutive year of Ivanti Connect Secure zero-days, after January 2024 and January 2025. When a product category keeps producing the same class of pre-authentication bug, the lesson for buyers is not “wait for a perfect vendor.” It is to design as if the appliance will be compromised, which is Part 2.
Part 2 — Seven patterns a buyer can build around the appliance
None of these would have stopped the exploit. Each would have changed what the attacker got or how fast you knew. They are choices made long before any incident, which is why they are controls and not response steps. Each one also notes where the datasheet already gives you the knob.
1. Shrink who can reach the pre-authentication code
The first step needs only network reach to the login page. Put an independent layer in front of the appliance, not the firewall inside it: a reverse proxy or edge service that allows only the paths and headers the product legitimately needs, and keep management interfaces off the internet entirely. Where your users sit in known networks, allowlist them. After a disclosure like this one, dropping the specific internal routing header at that layer is a candidate stop-gap to test with your vendor. The limit is honest: roaming users make IP allowlists impractical, and the VPN client’s own protocols may not pass through a proxy, so test before you rely on it.
2. Treat the appliance as a hostile host
Put it in its own network zone and write the firewall rules as if it has already been taken: it may reach the named domain controllers on the directory ports, DNS and the update servers, and nothing else. That does not stop the attacker using the exploit channel itself to carry data out, but it stops the appliance becoming a scanning platform for the rest of your network, and anything outside the rules becomes an alert with no tuning.
3. Delegate authentication; do not store it
The datasheet lists SAML 2.0 as a service provider, OIDC and certificate authentication. Where your design allows, use them, so the appliance never holds a reusable directory password. For anything that still needs LDAP, scope the account to what login requires and test it: from that account, try to read a LAPS password and a BitLocker recovery key. In Volexity’s account the actor read both through a service account, which suggests the account could read far more than authentication needs.
4. Narrow the tunnel
Use the per-app and role-mapping features the datasheet describes, and put a firewall between the VPN address pool and sensitive segments. A flat network turns one stolen session or one compromised gateway into access to everything. Moving to zero-trust network access goes further and is a larger project than the first three patterns; treat it as a quarter’s work, not a week’s.
5. Keep the record somewhere the intruder cannot edit
The attacker removed recent entries from the appliance’s debug and audit logs and left older ones, so the files looked normal. Stream every log type off the device in real time to a collector the appliance cannot write back to, and treat a gap between local and collected logs as an alert. Pair that with watching the appliance’s neighbours, described in Part 3.
6. Rebuild; do not repair
If the box may have been root-owned, you cannot trust it to tell you. Keep the configuration in version control, run a virtual instance if you can, and rehearse the sequence: capture memory from outside the box before you touch it, replace it from a clean image, restore the configuration, rotate every secret it held. Rebooting first can destroy the in-memory evidence. A rotation you have practised turns a week into an afternoon.
7. Keep a second door
CISA gave federal agencies three days after the October 13 listing. For everyone else, the question on the day a KEV entry lands on your edge device is whether you can turn it off and what breaks. If the VPN is the only way staff reach anything, you will run exposed because you have no alternative. A tested fallback, whether a second access path or a documented reduced-operations mode, makes “pull it” a real option.
Questions to put to any gateway vendor before you buy or renew
The datasheet answers “what can it do for my users.” These answer “what happens when it is the target.” They are fair to ask of any vendor, not only this one.
- Which components handle unauthenticated requests, and what privileges do they run with on the build we would deploy?
- Does your integrity check cover the running process and memory, or only files on disk?
- Can we forward every log type to our own collector in real time, and can local logs be made tamper-evident?
- Can we drop or allowlist request headers and paths before authentication, and is that configuration supported?
- After a security fix, do you publish how you searched for variants of the same bug? (Ivanti says it fixed “a portion” of this one in July.)
- What is your fix timeline for a bug on the KEV list, including for branches near end of life? (Connect Secure 22.8 ends January 31, 2027.)
- How do we capture memory and rebuild from an image, and do you support that?
- Can we see an independent penetration-test summary of the product, under NDA?
Part 3 — The second line of defence: where to watch
The first customer’s compromise was found by network security monitoring, not by the appliance: Volexity began investigating at a customer it monitors, and the telltale was authentication failures coming from the appliance’s own internal interface. That is the model. You cannot see inside the box, so watch what it does to the systems around it.
| Stage | What the attacker did | Where you can see it | Effort |
|---|---|---|---|
| Initial access | Many requests to the login welcome page; request path and internal routing header do not match | Reverse proxy or network sensor in front of the appliance. After disclosure, test dropping the internal routing header at a proxy as a stop-gap, with your vendor’s agreement | Medium |
| Credential theft from the box | Reads stored directory credentials | The bind account’s activity in domain controller logs: logins from unexpected times, or queries that go beyond authentication | Low if you already collect domain controller logs |
| Directory reconnaissance | Queries for LAPS passwords, BitLocker recovery keys, and password attributes | Directory audit on the LAPS and recovery-key attributes (directory service access, event 4662). Alert on any read from a service account or from the appliance’s address | Low to medium |
| Kerberoasting | Requests service tickets to crack offline | Event 4769 bursts from one source, especially for RC4 ticket requests. Prevent by moving service accounts to managed accounts with long random passwords | Low |
| Password spraying | Many users, few passwords, from the appliance | Events 4625 and 4771 across many accounts from one address; the VPN appliance should not be that source | Low |
| Traffic capture and exfiltration | Renamed packet-capture tool, results sent back over the exploit channel | Unusual volume or long sessions from the appliance in firewall or flow logs; the appliance should not initiate large outbound transfers | Medium |
| Cover tracks | Recent entries removed from debug and audit logs | Off-box log copy. A gap or truncation in the local log compared with the collector is the alert | Low |
The common thread is a baseline. A VPN appliance has a narrow, boring role. Any of: Kerberos ticket requests, queries for recovery keys, packet captures, or password-spray patterns from its address is wrong by definition, with no tuning needed.
When a KEV entry lands on your edge device: a first-48-hours plan
| When | Do | Why |
|---|---|---|
| First hours | List every appliance of that product and its exact build, including ones a vendor or team manages. Decide: patch now, mitigate, or disable | You cannot decide about devices you have not counted. Disabling is a legitimate option if you rehearsed it |
| Same day | Upgrade to a fixed build. Start forwarding logs and capture a memory image before you reboot or reset, if you suspect exposure | Rebooting an appliance can destroy the in-memory evidence that proves compromise |
| Within 48 hours | Hunt the neighbours: the checks in the table above, back to the earliest exploitation date (October 3 here) | Absence of malware is not absence of compromise. Look for behaviour on domain controllers and the network |
| If exposure is plausible | Rotate what the appliance could read: its LDAP account, LAPS passwords, BitLocker recovery keys, accounts that authenticated through it. Follow Ivanti and CISA’s reset-and-rebuild steps | Assume stolen until proven otherwise. A tested rotation runbook turns a week into an afternoon |
| Following week | Write down what you could not answer fast, and fix that | The goal of the exercise is a faster next time, not a clean report |
Ten questions to ask about your own VPN stack
Answer yes or no. Each “no” is a finding you can put an owner and a date on.
- Do we have a current list of every VPN and edge appliance, with firmware build, owner, and who watches its advisories?
- Can the appliance’s directory account read LAPS passwords or BitLocker recovery keys? (Test it; do not assume.)
- Does the appliance store any credential that works against the directory, and could we rotate it within an hour?
- Are appliance logs streamed off the device in real time, and would we notice a gap?
- Is directory auditing on for LAPS and recovery-key attribute reads, and does an alert fire?
- Would we notice Kerberos ticket bursts or password-spray patterns originating from the VPN address?
- Does a VPN session reach everything, or only the applications that user needs?
- Is there a firewall between the VPN address pool and our sensitive segments?
- If a KEV entry arrived tonight with no patch, could we disable the VPN, and what would break?
- Have we practised a credential rotation and appliance rebuild, not just written it down?
The auditor’s view: controls this chain tests
Every item above is something a SOC 2 or ISO 27001 audit already asks about. The difference is whether you can show it ran, not whether you wrote it down.
| Decision | Framework controls | Evidence an auditor would want |
|---|---|---|
| Least-privilege service accounts | SOC 2 CC6.1, CC6.3 · ISO 27001 A.5.15, A.8.2 | Account permissions list and a dated test showing it cannot read LAPS or recovery keys |
| Credential rotation readiness | SOC 2 CC6.1 · ISO 27001 A.5.17 | Rotation runbook and a record of the last rehearsal |
| Off-box logging and monitoring | SOC 2 CC7.2 · ISO 27001 A.8.15, A.8.16 | Collector configuration, alert rules, and a sample alert for a log gap |
| Segmentation of remote access | SOC 2 CC6.6 · ISO 27001 A.8.20, A.8.22 | Firewall rules between the VPN pool and sensitive networks |
| Patch and exit readiness for edge devices | SOC 2 CC7.1 · ISO 27001 A.8.8, A.5.24–A.5.26 | Device inventory with builds, patch dates against KEV deadlines, and the disable-or-patch decision log |
Where attack-surface monitoring fits, and where it does not
Continuous attack-surface monitoring answers the first question on that list: what do we expose to the internet, including the gateway someone stood up for a project and forgot. It does not tell you whether an appliance is vulnerable or compromised; that comes from the vendor advisory and your own forensics. What CATAAM adds is the other half of the story: the controls above become scheduled, dated evidence rather than a policy that was true once, so the audit trail and the incident review start from facts.
Related reading: four exploited zero-days in one week across Check Point, F5 and Arista and PHP2Shell. The common thread is a trusted, exposed device with a bug that was exploited before it was fixed.
Reference: versions, dates and sources
| Item | Detail |
|---|---|
| CVE-2026-104935 | Authentication bypass leading to remote command execution, CVSS 8.6. Patched October 13: 25.1.1.2, 25.1.3.0, 25.1.3.1, 22.8R2.5. KEV October 13 |
| CVE-2026-111357 | Privilege escalation (missing authentication for a critical function). Patched October 29: 25.1.1.3, 22.8R2.6. KEV October 30 |
| CVE-2026-118527 | File placement via predictable identifier (authenticated). Patched October 29, same builds. KEV October 30 |
| Affected | Per CISA: 25.1.1.2 and prior, 25.1.2.2 and prior, 22.8R2.5 and prior. Build numbers vary by branch; check Ivanti’s advisory |
| End of life | Connect Secure 22.8 reaches end of life on January 31, 2027 |
| Sources | Volexity (October 13 report, updated for the October 29 patch), CISA alert and KEV catalog, The Register, Singapore CSA, Cybersecurity Dive, The Stack |
Start with the first question on the list: what do you expose to the internet?
Run a free attack-surface scan →Frequently asked questions
- Would patching on time have protected me from the Ivanti chain?
- Not for the first ten days. Volexity saw exploitation from October 3, and the first fix for CVE-2026-104935 shipped October 13. The first compromised customer Volexity examined was fully patched. After October 13 patching matters, but the October 29 builds are also needed to cover the privilege-escalation and file-placement flaws.
- Why can a clean Ivanti integrity check still mean I was compromised?
- CISA says the Integrity Checker Tool may not detect exploitation of CVE-2026-104935 because the attacker’s commands run in memory. Volexity also reports selective deletion of recent log entries. Confirming compromise needs network and memory forensics, and checks on the systems around the appliance.
- What is the single most useful change if I run a VPN appliance with Active Directory?
- Reduce what its directory account can read, then test it. In this campaign the attacker used a service account to read LAPS passwords and BitLocker recovery keys. An account scoped to authentication only would have limited what that stage returned.
- How would I detect this without access to the appliance?
- Watch the neighbours: directory audit for reads of LAPS and recovery-key attributes (event 4662), bursts of Kerberos service-ticket requests (4769) and failed logons across many accounts (4625, 4771) coming from the VPN appliance’s address, and a gap between the appliance’s local logs and the copy on your collector.
- Should I replace my VPN with zero-trust network access?
- It reduces the blast radius, because a user or a compromised gateway reaches only specific applications. It does not remove the need to patch or to monitor, and it is a larger project than scoping accounts and forwarding logs. Treat the quick controls as this week’s work and ZTNA as a quarter’s.
- Do the security features in the Ivanti Connect Secure datasheet stop this attack?
- The datasheet’s access controls (conditional access, MFA, posture checks) govern who logs in, and the chain bypassed authentication, so they were never reached. Hardening claims such as root privilege avoidance, SELinux and the integrity checker are mitigations whose effect on this chain public reports do not confirm, and CISA says the integrity checker may miss it. The features that help most are the ones you configure around the box: SAML or OIDC authentication, per-app access and role mapping, and off-box logging.
- Does attack-surface monitoring detect this vulnerability?
- No. It discovers what you expose to the internet, such as a forgotten VPN gateway, so you know which appliances to check. It does not tell you whether a given appliance is vulnerable or compromised.