Ivanti Patches Two More Connect Secure Zero-Days Used in Attacks

Short answer: Ivanti has fixed two more flaws in Connect Secure, its remote access VPN gateway, that attackers were chaining together from early October 2026. They are CVE-2026-111357 and CVE-2026-118527, patched on October 29. They sit alongside CVE-2026-104935, which Ivanti fixed on October 13. If you run Connect Secure, upgrade to the newest release today, then assume the box may have been touched and go looking.

The key facts

Item	Detail
Product	Ivanti Connect Secure (ICS), the SSL VPN appliance
New CVEs	CVE-2026-111357 (privilege escalation), CVE-2026-118527 (file upload by a logged-in attacker)
Earlier CVE in the chain	CVE-2026-104935 (authentication bypass), fixed October 13
New patch date	October 29, 2026
Exploited since	At least October 1 per Defused, October 3 per Volexity
Found by	Volexity, during an incident at a customer
Attacker	A group Volexity calls UTA0576, assessed with low confidence as criminal
CISA deadlines	CVE-2026-111357 by November 2, CVE-2026-118527 by November 13

Why there are "two more"

When Ivanti learned of the attacks, it already had a fix for CVE-2026-104935 in testing. According to the advisory quoted by BleepingComputer, its "focus was initially centered on the disclosure of CVE-2026-104935" so customers got protection fast. That patch removed the main entry point.

The rest of the chain took another two weeks. Volexity's write-up describes three steps: get past the login, write a file and run code, then climb to root (full administrator control of the appliance). Once all three were combined, an attacker with no account could run commands as root, even on a device that was fully patched at the time, version 22.8R2.4.

What the attackers did once inside

This is the part that should worry you most. Volexity says the group used the VPN box as a starting point into the company's network. They:

• pulled the LDAP account the gateway uses to talk to Active Directory, the Windows user directory
• exported Active Directory data and went after local admin passwords and BitLocker recovery keys
• tried password spraying (guessing common passwords across many accounts)
• ran a hidden packet sniffer to catch logins sent over the network
• edited log files to hide their tracks

Volexity also notes that "UTA0576 deployed no malware or web shell." They simply exploited the device again every time they wanted to send a command. That leaves very little on disk.

Step 1: find out what version you run

Log in to the ICS admin console and check the version on the system status page. Volexity lists 25.1.1 and earlier, 25.1.2 and 22.8R2.4 as releases to move off. If you are on any of those, or not sure, treat the device as unpatched.

Step 2: install the newest release

Download the current release from the Ivanti customer portal and follow the Ivanti advisory. Take a configuration backup first. If you have a clustered pair, update one node, confirm users can connect, then do the other.

Step 3: do not trust the Integrity Checker alone

Ivanti's Integrity Checker Tool is usually the first thing admins run. For this attack, Volexity says plainly that "the tool does not detect any modifications." A clean result does not mean a clean device.

Look at your logs and network data instead. Volexity's signs to search for include:

• lots of requests to /dana-na/auth/url_default/welcome.cgi
• an X-DSCGI-PATH header that points at wu.cgi or a file under /home/runtime/tmp/
• connections from the VPN appliance to your domain controllers that it would not normally make

Step 4: assume credentials are exposed

Since the attackers took the gateway's LDAP account and went after admin passwords and recovery keys, the safe move is to rotate them. Change the service account the ICS uses for directory lookups. Rotate local admin passwords and review BitLocker keys on machines that could be reached. Volexity does not list this as a formal step, but it is the obvious follow-on to what it saw stolen.

Step 5: investigate if you see signs

If any machine shows login attempts coming from the VPN appliance, Volexity recommends a proper forensic look. Bring in your incident response provider rather than wiping the device first, because a reset destroys evidence you may need.

Common mistakes

• Installing the October 13 fix and stopping there. Two more holes stayed open until October 29.
• Reading a clean Integrity Checker result as an all-clear.
• Patching the appliance but leaving the stolen directory account with the same password.
• Only checking for web shells. This group left none.
• Leaving the admin interface reachable from the internet. Shadowserver counts more than 5,000 exposed Connect Secure devices, and a public admin page makes every new flaw worse.