On 29 October Ivanti released a fix that closes the full chain of three flaws in the Connect Secure VPN gateway. Attackers have been exploiting the chain since early October and use it to reach root level access on the device without logging in. Organisations that applied only the first patch in mid October still have a vulnerable appliance.
Ivanti and CISA track the chain under three identifiers, the card shows the highest scoring flaw. The full list is in the text.
What happened
Connect Secure is an Ivanti VPN gateway that staff use to reach the corporate network. It sits at the network edge and is reachable from the internet.
On 13 October Volexity described an attack on a gateway that was fully patched at the time, running version 22.8R2.4. An unknown attacker, tracked as UTA0576, combined three flaws into a single chain. First the attacker bypassed authentication, because the gateway decided on access from the public login URL but took the target script from a request header. Next the attacker wrote a script to disk and managed to run it in the brief window between the write and the file type check. Finally the attacker abused a service that runs maintenance tasks as root on the gateway and gained the highest privileges.
Ivanti updated its advisory on 29 October. The chain is now tracked under three identifiers: CVE-2026-104935 (authentication bypass and remote code execution, rated CVSS 8.6 by the vendor), CVE-2026-118527 (file write with attacker controlled content, CVSS 4.3) and CVE-2026-111357 (privilege escalation to root, CVSS 8.8). The vendor confirmed exploitation affecting a limited number of customers and a fix is now available for all three. On 30 October the US agency CISA added CVE-2026-118527 and CVE-2026-111357 to its catalogue of exploited vulnerabilities, with remediation deadlines for US federal agencies of 2 and 13 November.
What the attacker did next matters more than the flaw itself. According to Volexity, the attacker collected credentials stored on the appliance, used the gateway service account to query Active Directory and looked for local administrator passwords from LAPS and BitLocker recovery keys. The attacker also sprayed passwords against domain accounts and parsed an existing network traffic capture to pull further credentials out of LDAP traffic. One vulnerable VPN gateway therefore led straight to the domain.
Does this affect you?
According to Ivanti, CVE-2026-111357 and CVE-2026-118527 affect versions 25.1.1.2 and earlier and versions 22.8R2.5 and earlier. The fix is in 25.1.1.3 and 22.8R2.6.
One point deserves attention: the patch released on 13 October covered only CVE-2026-104935. If you applied it and then moved on, the other two flaws are still on the appliance and the chain is not closed.
You will find the version in the gateway administration interface. If you are not sure whether Connect Secure runs in your organisation at all, check remote access managed for you by a supplier as well. The product used to be called Pulse Connect Secure and older documentation still uses that name.
What to do now
- Upgrade to 25.1.1.3. If migration is not possible straight away, deploy 22.8R2.6.
- Rotate every secret the gateway can reach: the service account password for LDAP and Active Directory, local passwords on the appliance, certificates and interface keys. Credentials were the first thing the attacker collected.
- Reduce the permissions of the service account in Active Directory to what the gateway actually needs. An account that can read LAPS passwords is far too powerful.
- Limit access to the gateway administration interface from the internet and allow it only from management networks.
- If the gateway was reachable from the internet and unpatched at any point since 3 October, plan for a forensic review, not just an upgrade.
Neither Volexity nor CISA list a workaround that would close the chain without upgrading, so the upgrade is the only way to remove the flaws.
How to tell whether you have been compromised
Expect a routine check to find nothing. According to Volexity the attacker cleaned up: in memory changes were restored to their original state and matching entries were deleted from the gateway debug log and from the system audit log. No web shell or backdoor was left on the device, and commands travelled inside the HTTPS requests that re-exploited the chain again and again. The Ivanti Integrity Checker Tool compares files on disk, so it does not detect a compromise that only touched memory. Only forensic analysis of appliance memory and disk gives certainty.
What is worth reviewing around the gateway: attempts to move into the network from the VPN gateway address, logins by its service account at times and places where it has no business, Active Directory queries for attributes holding LAPS passwords and BitLocker recovery keys, and long runs of failed logins against many accounts on domain controllers.
If you suspect compromise, capture a memory and disk image first and rebuild the appliance only afterwards. A rebuild destroys the evidence and you will never learn what the attacker managed to do.
No time to track all this?
Watching vendor advisories and deciding which of them is genuinely urgent for your organisation takes time that a small team rarely has. We do this for our clients as part of their team, from a security assessment to ongoing security leadership. If you only want to talk through where you stand, get in touch, the initial consultation is free of charge. If you are dealing with an incident right now, use our under attack page.
Sources: Volexity, analysis of the chain and attacker activity · Ivanti, advisory and fixed versions · CISA, catalogue of exploited vulnerabilities · NVD, CVE-2026-111357 · NVD, CVE-2026-118527 · The Hacker News, summary of the catalogue additions