# The Ivanti VPN Patch Needs a Forensic Receipt

> Attackers reached root on a fully patched Ivanti Connect Secure appliance and cleaned up much of their trail. The repair needs two receipts: proof that the entry path is closed and evidence that the earlier appliance was not already used.

- **Author:** Kubilay Tunca
- **Published:** 2026-10-14
- **Category:** For Experts
- **Tags:** Incident Response, Network Security, VPN, Vulnerability Management
- **Canonical URL:** https://cyber-security-in-plain-english.com/post/experts/news/ivanti-vpn-patch-needs-forensic-receipt

---

On 5 October 2026, an incident responder traced suspicious activity back to an Ivanti Connect Secure VPN appliance. The box was running version 22.8R2.4, the latest release available at the time. It had done what patch policy asked of it. An attacker had still reached root.

The reason appeared in public on 13 October. Volexity said the attacker had chained three previously unknown flaws: an authentication bypass, a brief file-write race that led to code execution, and a local privilege escalation. Ivanti released fixes for the first two under CVE-2026-104935. The privilege-escalation repair was still due in a later release as of 14 October. [Volexity's incident report describes the chain, the affected appliance, and the pending third fix](https://www.volexity.com/blog/2026/10/13/a-series-of-unauthenticated-events-chained-exploitation-of-ivanti-connect-secure-zero-days/).

Patching comes first. This case also needs a second job. The attacker ran code in memory, restored altered configuration, deleted selected log entries, and reused the exploit path for each command instead of leaving a conventional web shell. Volexity warned that Ivanti's Integrity Checker could miss this activity. A clean check after an upgrade cannot settle the question of what happened before it.

That is the practical lesson. An edge appliance with a fixed version still needs an exposure receipt and, where the evidence warrants it, an incident investigation. The update closes a route. The investigation tells you whether someone already walked through it.

## What happened on the appliance

The first observed activity began on 3 October 2026. Volexity found the compromised appliance two days later while investigating a network-security-monitoring alert. The company assigned the unknown operator the temporary name UTA0576 and said it had seen exploitation on one customer's device. Ivanti described the broader exploitation known to it as limited. Neither statement supports a claim of mass compromise.

The affected system mattered because of where it sat. Ivanti Connect Secure is an enterprise remote-access gateway. It faces the internet so staff can reach internal services, and it commonly holds or uses credentials that let it query a directory. Compromise gives an intruder a position on the seam between an untrusted network and the organisation's trusted one. That seam is valuable even before the intruder touches another server.

The first flaw confused the public route with the internal destination. A request reached a public login script, but a header named a different script for the appliance to execute. The product checked whether the visible URL was allowed while routing the request according to the header. In plain English, the guard inspected the name on the envelope while the delivery instruction inside sent it through another door.

The second flaw created a narrow execution window. An upload handler wrote a supplied file to temporary storage before checking whether it was a valid ZIP archive. The attacker supplied a script with a `.zip` name, then sent parallel requests trying to execute the temporary file before the failed validation deleted it. The interval was brief. Repetition made it useful. Volexity reconstructed this sequence from memory, core dumps, and disk evidence rather than from a tidy server log.

Those two weaknesses are tracked together as CVE-2026-104935. The [National Vulnerability Database entry describes an authentication bypass that permits unauthenticated command execution](https://nvd.nist.gov/vuln/detail/CVE-2026-104935). Ivanti rated it 8.6 on the CVSS scale. A score helps queues sort work; confirmed exploitation and the appliance's position make the operational priority clearer than the decimal does.

The third flaw raised the attacker's authority. A privileged maintenance service trusted configuration held in a shared store. The exploit changed a process's in-memory library code, modified the maintenance task long enough to run a supplied script as root, checked that root access worked, and restored the changed values. Ivanti had not yet shipped that separate privilege-escalation fix when the research became public on 13 October.

That distinction matters during triage. The 13 October releases close the remotely reachable authentication-bypass and code-execution route on the affected branches. They do not retroactively erase a root session that occurred on 3 October, and they do not turn a weak post-compromise investigation into a strong one. The patch answers the forward-looking question. The evidence has to answer the backward-looking question.

## Why an edge box changes the response

A remote-access appliance is supposed to be a controlled doorway. It terminates sessions from outside, authenticates users, consults internal identity systems, and routes approved traffic towards applications. To perform that job, it often sees more than an ordinary public web server would.

Volexity reported that the attacker extracted credentials stored on the appliance, including domain credentials used with LDAP. The operator queried Active Directory, searched for Local Administrator Password Solution values and BitLocker recovery keys, inspected authentication logs for usernames, sprayed passwords, collected configuration, and examined captured network traffic. [The Volexity report ties those actions to the investigated appliance and labels several conclusions by confidence](https://www.volexity.com/blog/2026/10/13/a-series-of-unauthenticated-events-chained-exploitation-of-ivanti-connect-secure-zero-days/). These are incident-specific observations, not a checklist of what every exposed Ivanti device suffered.

Still, they show what the position makes possible. A gateway may know the directory server's address. It may carry a service credential. It may see usernames during ordinary authentication. If older protocols cross it in plaintext, a packet capture can hold secrets that never appear in a configuration file. Root on the gateway puts all of those paths in view.

This is why an edge-device compromise cannot be scoped by asking whether the appliance's web files changed. The device can be a launch point, a listening post, and a credential store at once. The relevant boundary extends into the identity systems and destinations the gateway could reach.

The attacker in this case did not need to install a durable first-stage backdoor. Volexity said UTA0576 reran the exploit chain for each command and returned output through the same HTTPS exchange. That choice reduced the need for a new command channel and left fewer obvious files behind. A responder who searches only for a web shell may find nothing because the operator chose a different working method.

The same logic changes containment. Removing the vulnerable route prevents the same unauthenticated entry, which is urgent. Credentials observed or stolen before the repair can survive it. An LDAP account still works until it is rotated or revoked. A harvested BitLocker recovery key remains useful until the affected recovery material is replaced. A valid user password found during spraying does not care that the gateway now runs a newer build.

The blast radius therefore follows authority. Inventory what the appliance could read, where it could connect, which identities it held, and which authentication traffic traversed it. That map gives the investigation somewhere concrete to go. Without it, “the VPN was patched” becomes the end of the ticket while the useful part of the incident remains open.

## A clean integrity check can be true and incomplete

Integrity checkers answer a specific question: does the current appliance differ from the expected on-disk state in ways the checker knows how to detect? That is useful. It is also narrower than “was this appliance exploited?”

In the investigated case, the privilege-escalation stage patched library code in process memory. It restored the configuration-store entry after gaining root. The attacker also removed selected entries from Ivanti debug logs and the Linux audit log. Volexity concluded that the Integrity Checker did not detect modifications from this chain because the relevant alteration was in memory and the stored configuration was put back.

A green result can be accurate within that scope. The expected files may be present. Their hashes may match. No listed persistence artifact may remain. The result still says little about a command that lived only in memory, returned its output over the exploitation request, and cleaned up before the check ran.

This is an evidence problem rather than a product-checkbox problem. Disk, logs, network records, memory, directory events, and downstream service logs each preserve different parts of the story. An attacker can erase some of them. Collection timing decides whether volatile evidence survives long enough to be useful.

Memory mattered here because it retained process state and artifacts that the operator had tried to remove elsewhere. Volexity recovered exploit components, command activity, packet-capture behavior, and temporary material through forensic analysis. That does not mean every organisation can or should improvise live memory collection from a production gateway. It means suspected compromise has crossed into specialist incident response, where preserving the scene can be more valuable than running one more ordinary health check.

A responder also has to distinguish absence of evidence from evidence of absence. No mismatch in the Integrity Checker means no mismatch was found under that check's method and at that time. No web shell means no web shell was found. Neither statement excludes the command path Volexity described.

The right conclusion is calibrated. If an appliance ran an affected version while exposed and there are matching network or downstream indicators, escalate. If there is no evidence after a well-scoped review, record what was checked, which data sources existed, and where visibility was missing. Certainty should come from the evidence you possess, not from the confidence of the ticket template.

## The version number needs context

Ivanti published updates on 13 October 2026. According to [Rapid7's independent summary of the vendor matrix](https://www.rapid7.com/blog/post/etr-ivanti-connect-secure-zero-day-exploited-in-the-wild-cve-2026-104935/), affected 25.1.1 deployments should move to 25.1.1.2, affected 25.1.2 deployments should move to 25.1.3.0 or 25.1.3.1, and affected 22.8R2.4 or earlier deployments on that branch should move to 22.8R2.5. Ivanti stated that 22.7.x and earlier were not affected by CVE-2026-104935.

Read that matrix against the exact branch and build you operate. Do not shorten it to “anything below 25.1.3 is vulnerable,” because the unaffected 22.7 branch makes that sentence wrong. Do not assume a package downloaded to a management station proves the cluster is repaired either. Every active node needs a running-version receipt.

The timing adds another wrinkle. Rapid7 reported that a portion of the issue had been found through Ivanti's product-security work and fixed in the July 2026 release of 25.1.3.0. Exploitation occurred while the company was backporting the repair to other supported releases. That explains why one branch already had a fixed build while the latest 22.8 build remained vulnerable at the beginning of October.

A patch receipt should name the appliance, code branch, previous build, target build, installation time, restart or failover result, and post-update running state. In a high-availability pair, repeat the proof for both members. Include standby nodes and disaster-recovery appliances. An old edge device that only wakes during failover still faces the internet when the organisation is having its worst day.

The [Ivanti advisory is the source of truth for supported versions and recovery guidance](https://hub.ivanti.com/s/article/Security-Advisory-Ivanti-Connect-Secure-CVE-2026-104935?language=en_US). Recheck it before each maintenance change because vendor advice can move as investigation continues. As of 14 October, the separate privilege-escalation repair remained pending according to Volexity. Record that residual issue rather than allowing the CVE ticket to imply that every part of the chain received a fix.

CISA added CVE-2026-104935 to its Known Exploited Vulnerabilities catalog on 13 October and set 16 October as the due date for covered federal systems. Its entry also calls for forensic triage. [CISA's live catalog records the exploitation status and required action](https://www.cisa.gov/known-exploited-vulnerabilities-catalog). Organisations outside the US federal government do not inherit that legal deadline, but the short interval reflects the combination of confirmed exploitation and a public-facing access product.

Urgency should improve the order of work, not flatten it. Preserve volatile evidence where compromise is suspected, contain the route, update every affected node, then verify the running state. If your evidence plan requires an image before reboot, coordinate that decision with an incident responder rather than racing an automatic patch job against a forensic collection.

## What to preserve and where to look

Start with the time window. Volexity observed repeated exploitation beginning on 3 October 2026. Ivanti disclosed the issue on 13 October. Your own review should reach back far enough to cover the appliance's exposure before the public date, especially if network monitoring shows suspicious requests or internal activity with no clean explanation.

At the perimeter, Volexity recommended watching for large numbers of requests to `/dana-na/auth/url_default/welcome.cgi`. It also described requests where the `X-DSCGI-PATH` header named a target that did not match the URL path. These are useful leads from the investigated campaign. They are not a guarantee that every operator will use the same volume, header value, or infrastructure.

Preserve reverse-proxy, load-balancer, firewall, flow, DNS, and packet metadata that may cover the gateway. Keep original timestamps and time zones. Record retention gaps. If a security device normally sees the public request before it reaches Ivanti, its copy may outlive logs altered on the appliance.

On and around the device, protect the evidence before routine cleanup rotates it away. Volexity specifically called out `/tmp/` and reported attacker material under `/data/.icscap/` in the investigated case. The company also published campaign indicators separately from the narrative report. Use those indicators as pivots, then look for behavior: unexpected packet capture, unusual child processes, outbound directory queries, a burst of commands, and log gaps that line up with other activity.

Directory evidence may show the consequence more clearly than the gateway does. Review the service account used by the appliance. Ask which attributes it could read, which queries were unusual, whether it accessed LAPS or recovery-key material, and whether password spraying followed. Preserve domain-controller, identity-provider, and authentication telemetry before its own retention window closes.

Downstream systems deserve the same attention. Search for connections originating from the gateway to services it does not normally administer. Review successful logins that follow failed sprays. Look for privileged access using identities the appliance stored or observed. An edge compromise becomes an enterprise compromise when stolen authority works somewhere else.

Memory acquisition and appliance forensics carry operational risk. A collection can consume resources, alter state, or require methods your team has never tested on that product. Bring in Ivanti support and a responder familiar with network appliances when the indicators justify it. Document every collection command, timestamp, hash, and transfer so the evidence remains useful later.

There is an honest limit. A device may already have rebooted. Logs may have rotated. Network sensors may not retain headers. Memory from the relevant process may be gone. Write those gaps down. A finding of “no evidence in the data retained” is defensible; an unqualified “not compromised” is not.

## The response needs two receipts

Treat this as two connected workstreams. One proves the vulnerable route has been removed. The other determines whether the old route was used and what authority may have escaped through it. Combining both into a single “patched” status hides unfinished work.

A practical sequence follows. Adjust it with your incident lead when volatile evidence, high availability, or service continuity changes the order.

1. **Open an incident record before maintenance.** Name the affected appliances, public addresses, branches, builds, exposure dates, owners, and evidence sources. Record the UTC time used for the review so logs from different systems can be joined without guesswork.

2. **Preserve perishable evidence where suspicion exists.** Save external network records and central logs first. If the appliance shows campaign indicators, unexplained lateral traffic, or log tampering, coordinate memory and disk collection with qualified responders before a reboot destroys volatile state.

3. **Contain the public route.** Restrict or remove exposure when the service design permits it. If immediate shutdown would cause greater harm, narrow source access, increase monitoring, and move directly to the supported update. Treat temporary controls as a bridge with an expiry time.

4. **Install the exact fixed release on every node.** Follow the current Ivanti advisory for the appliance's branch and upgrade path. Verify the running build after restart or failover. Capture evidence for active, standby, and recovery systems rather than accepting a management-console summary.

5. **Hunt from the gateway outward.** Review perimeter requests, appliance behavior, directory queries, service-account use, password sprays, packet capture, and downstream logins. Scope the hunt to what the gateway could actually reach and read.

6. **Revoke authority that may have been exposed.** Rotate the appliance's directory and integration credentials. Reset or replace other secrets when evidence shows they were readable or queried. Invalidate sessions where appropriate. Changing every password without a scope wastes time; leaving a known appliance credential untouched wastes the investigation.

7. **Rebuild when trust in the appliance is lost.** Follow vendor recovery instructions rather than trying to clean individual files by hand. A root-level compromise plus anti-forensics can make a fresh, known-good state the cheaper path to confidence. Preserve the old evidence before replacement.

8. **Track the remaining privilege-escalation repair.** The 13 October CVE updates address the remote entry and code-execution components described by Ivanti. Keep a separate owner and due date for the later third fix, then rerun the version and exposure checks when it arrives.

9. **Close with both receipts attached.** The repair receipt shows each node on the correct running build. The forensic receipt states the reviewed period, evidence sources, findings, rotations, rebuild decisions, gaps, and residual risk. A clean conclusion should be reproducible by the next person who reads the record.

This order prevents a familiar failure. Teams patch quickly, watch the service come back green, and close the emergency change. A week later, an identity alert reveals that the gateway's service credential had already been taken. The first response was fast. It stopped halfway.

## Change the gateway's authority after the fire

Incident response should leave the next appliance with less to lose. A VPN gateway needs enough authority to authenticate and route users. It rarely needs every secret that accumulated around it over years of convenient integration.

Start with the directory account. Give it only the read permissions required for the chosen authentication flow. Sensitive attributes such as recovery keys and local administrator passwords should sit outside that account's reach unless the product has a documented need for them. Test the restriction. A policy diagram is weaker than a denied query captured in a receipt.

Prefer encrypted directory transport and verify certificate handling. Volexity reported that the attacker inspected packet captures for plaintext LDAP and other credential-bearing protocols. A compromised root process can still observe much of what the appliance itself decrypts, so encryption does not solve appliance compromise. It reduces the casual exposure of credentials travelling across adjacent links and removes easy prizes from generic packet capture.

Separate management access from user-facing access. The public service must face remote users. Administrative interfaces, support routes, and monitoring channels should have tighter source restrictions and stronger authentication. The distinction will not repair a flaw in the public path, but it limits the other doors an intruder can try after landing.

Limit the internal network routes available from the gateway. Users may need access to many applications after policy allows it; the appliance's operating system and service accounts usually need fewer management destinations. Monitor new destination pairs. A gateway that suddenly queries a server or port it has never used deserves attention even when the traffic uses a valid account.

Keep external logs beyond the appliance's reach. Send authentication, network, and administrative records to a system the gateway cannot rewrite. Retention should cover the time between first exploitation and public disclosure, not merely the hours after an alert. The attacker in this incident removed selected local records. An independent copy turns that cleanup into a gap you can compare rather than the only history you possess.

Rehearse collection before the next emergency. Know who can preserve memory, what a reboot destroys, how to collect appliance evidence without filling its storage, and when to call the vendor. The middle of an exploited zero-day is a poor time to discover that nobody owns the packet broker or that the directory keeps only one day of queries.

The Anonymity Playbook makes the same boundary visible from the user's side: a VPN moves trust rather than abolishing it. For an enterprise operator, that trust includes the gateway's software, service identities, logs, and position on the network. Design each one so a single compromised box buys the attacker less.

## A patch closes the route, not the case

Ivanti's 13 October updates deserve emergency treatment on affected Connect Secure branches. Confirmed exploitation began before disclosure, the entry required no valid account, and the target sat at a powerful network boundary. Waiting for the normal maintenance window would give process more authority than evidence.

Speed still needs sequence. Preserve what will disappear. Close the public route. Prove every node runs the fixed build. Follow the appliance's credentials and connections into the network. Rebuild and rotate where the evidence demands it. Track the remaining third fix as a separate obligation.

The strongest ticket closure will contain two short, boring statements backed by artifacts. The first says which fixed build is running on each appliance. The second says what was examined for the earlier window, what was found, what could not be known, and what authority was replaced.

That second receipt is the difference between restoring service and restoring trust.

If you want practical security guidance without a daily flood, join the newsletter. It is one email per month.

## Sources

- [Volexity: A Series of Unauthenticated Events: Chained Exploitation of Ivanti Connect Secure Zero-Days](https://www.volexity.com/blog/2026/10/13/a-series-of-unauthenticated-events-chained-exploitation-of-ivanti-connect-secure-zero-days/), accessed 2026-10-14
- [Ivanti: Security Advisory Ivanti Connect Secure (CVE-2026-104935)](https://hub.ivanti.com/s/article/Security-Advisory-Ivanti-Connect-Secure-CVE-2026-104935?language=en_US), accessed 2026-10-14
- [Rapid7: Ivanti Connect Secure zero-day exploited in the wild (CVE-2026-104935)](https://www.rapid7.com/blog/post/etr-ivanti-connect-secure-zero-day-exploited-in-the-wild-cve-2026-104935/), accessed 2026-10-14
- [CISA: Known Exploited Vulnerabilities Catalog](https://www.cisa.gov/known-exploited-vulnerabilities-catalog), accessed 2026-10-14
- [NIST NVD: CVE-2026-104935](https://nvd.nist.gov/vuln/detail/CVE-2026-104935), accessed 2026-10-14

---

## About the author

Kubilay Tunca — Senior Full Stack Developer and Author. Founded Cyber Security in Plain English to translate complex security concepts into clear, practical advice, and writes the accompanying books on security, privacy, secure development, and AI systems.

## Books by this author

- **The Digital Fortress** — Your Everyday Guide to a Safer Digital Life. A warm, plain-English guide for people with real lives and finite patience. Learn the handful of habits that genuinely protect your money, accounts, and family, and get honest permission to ignore the rest. [Amazon](https://buy.cyber-security-in-plain-english.com/digital-fortress) · [Details](https://cyber-security-in-plain-english.com/books/the-digital-fortress)
- **The Anonymity Playbook** — Digital Survival for Whistleblowers, Journalists, Activists, and Everyone Else. A practitioner’s field manual for journalists protecting sources, whistleblowers, and activists. It explains how the surveillance actually works, what each technique costs you, and exactly where it fails. [Amazon](https://buy.cyber-security-in-plain-english.com/anonymity-playbook) · [Details](https://cyber-security-in-plain-english.com/books/the-anonymity-playbook)
- **Secure Software Development** — Practical patterns for building secure software. A hands-on security guide for developers and IT professionals who ship real software. Build, deploy, and maintain secure systems without slowing down or drowning in theory. [Amazon](https://buy.cyber-security-in-plain-english.com/secure-software-development) · [Details](https://cyber-security-in-plain-english.com/books/secure-software-development)
- **The Secure Harness** — Shipping Production Code with AI Coding Agents. A calm, practical guide to letting agents do useful work inside boundaries you set, enforce, and audit. Ships with 15 copy-pasteable artifacts: hook scripts, permission configs, release gates, and MCP templates. [Amazon](https://buy.cyber-security-in-plain-english.com/secure-harness) · [Details](https://cyber-security-in-plain-english.com/books/the-secure-harness)
- **The AI Native Engineer** — Build, Evaluate, and Ship AI Systems That Work in Production. Sixteen hands-on chapters, one real product. Grow it from a single model call into a retrieved, tool-using, observable, production-grade system, with evaluation treated as a habit from the first feature. [Amazon](https://buy.cyber-security-in-plain-english.com/ai-native-engineer) · [Details](https://cyber-security-in-plain-english.com/books/the-ai-native-engineer)

Full catalogue with contents and intended audience: https://cyber-security-in-plain-english.com/books

_As an Amazon Associate I earn from qualifying purchases. Buying through these links costs you nothing extra and helps pay for the blog._