Patched Ivanti Connect Secure in October? Two more exploited bugs, and the AD cleanup

If you patched Ivanti Connect SecuredefinitionIvanti's SSL VPN appliance, formerly Pulse Connect Secure. Staff sign in to it from the internet, and it checks their login against your directory. for CVE-2026-104935 earlier this month, you're not finished. Ivanti has now fixed the two other bugs in the same attack chain, CISA lists both as exploited, and the builds you need are 25.1.1.3 or 22.8R2.6. Patching is only half of it. Attackers who got in went after the VPN's directory passwords, so the Active Directory side needs checking too.

The VPN sits at the edge of your network, facing the internet, and every remote login passes through it. If someone takes it over, they start inside your network with a working directory account. They can also capture the directory traffic passing through the box and pull passwords out of it. The attacker Volexity tracked tried exactly that, with a renamed packet capture tool.

Ivanti says it knows of a limited number of customers hit when the three bugs were chained. CISA says threat actors are using the chain for credential theft and data exfiltration, and it flagged two of the three for forensic triagedefinitionA flag CISA puts on some KEV entries. Agencies can't just patch: they have to collect evidence first where they can, and check whether they were hit.. That flag tells US agencies they have to look for signs of compromise, so patching alone doesn't close the case. Private companies aren't bound by the directive, but it's a fair standard to borrow.

This product has been here before. Count the Pulse Connect Secure years and CISA's catalog now holds 17 of its flaws, with earlier waves added in January 2024, January 2025 and April 2025. If you still run one of these boxes, budget time for the next emergency patch now. The record says you'll need it.

For engineers: Volexity saw the bypass routed through the X-DSCGI-PATH header to /dana/fb/smb/wu.cgi. That handler writes uploads to /home/runtime/tmp/ under the MD5 of the client's file name. The privilege escalation patched the cgi-server process's in-memory copy of libdsplibs.so so it could change a DSCache entry. It then pointed an existing maintenance task at the Perl interpreter and asked dsinvoked to run it. Every command re-ran the whole chain and came back in the HTTP response. There was no web shell or backdoor, and the library on disk was never changed. That's why Ivanti's Integrity Checker TooldefinitionIvanti's tool that looks for unexpected file changes on a Connect Secure appliance. It checks files on disk, so attacks that live only in memory can slip past it. found nothing.

The table hides a trap for anyone who patched quickly in mid-October. 22.8R2.5 and 25.1.1.2 closed the bypass, and a vulnerability scanner keyed only to CVE-2026-104935 will mark them clean. They're still open to the other two. The no-login chain Volexity described starts with the bypass, which those builds close. Ivanti says CVE-2026-118527 needs an authenticated attacker and CVE-2026-111357 a local authenticated one. Both are still open on those builds, and both are on CISA's exploited list. Don't leave that sitting on your edge.

Ivanti explains the gap in its FAQ. It had the fix for CVE-2026-104935 in QA when the attacks were found and chose not to hold it back for the privilege escalation fix. That was a reasonable call. It also means anyone who treated the October 13 patch as the end of the story needs a second change window.

If you have ten minutes, start with the build number. Check it in the admin console or on the maintenance page, and compare it with the table. Anything below 25.1.1.3 on the 25.1.1 line, or below 22.8R2.6 on 22.8, is still open.

# example output, values made up. Run against logs you've copied off the appliance
grep -c 'welcome.cgi' access.log
48211
# A spike from one address is worth a look. Volexity says the exploit sends many parallel requests
grep -i 'X-DSCGI-PATH' proxy-headers.log   # only if a proxy or sensor keeps headers
X-DSCGI-PATH: /home/runtime/tmp/9f2c...e1
# A header pointing at /home/runtime/tmp/ is the race step. Escalate to forensics
grep '108.165.147.64' access.log firewall.log
# The one IP in Volexity's indicator file. No hit doesn't clear you; other actors use other hosts

You'll only see the header if something in front of the VPN records request headers, such as a reverse proxy or a network sensor. If nothing does, that's a gap to close before the next advisory.

Edge devices keep getting hit, and this product line has a long record on CISA's list. The fix that lasts is to make the VPN worth less to an attacker. Assume the box will be owned again someday, and limit what it can reach and what it can read when that happens.

Start with the directory account. The attacker used it to search for LAPSdefinitionMicrosoft's tool for local admin passwords. Instead of one password on every PC, each machine gets its own, and a copy sits in Active Directory or Entra ID. passwords, BitLocker recovery information and password attributes, so its read rights decide how bad a breach gets. Windows LAPS can encrypt the password it stores in Active Directory, and by default only Domain Admins can decrypt it. Keep the VPN account out of that group, and check what it can read in your BitLocker recovery objects. Our Microsoft Entra and Active Directory page and CyberArk page cover how we lock down and rotate service accounts like this one.

Most of that list comes from CISA's alert and Ivanti's recovery procedures. The identity part goes further than either. Volexity saw the attacker query LAPS passwords and BitLocker recovery keys through the VPN's service account. If that account could read them, every machine whose secrets it could see is in scope, well beyond the VPN box itself.

All three are made up, and none is a real incident or a Cohash client. The versions and behaviour come from Ivanti's, CISA's and Volexity's own pages.

Patching the appliance is usually quick. The slow part is the identity side, because someone has to work out what the VPN's account could read and then rotate it without breaking everyone's logins. Our identity threat detection and response practice does that work, and our Okta, Entra ID and CyberArk engineers handle the service account and rotation side. If you'd like a second pair of eyes on your exposure, start with an assessment.