On October 13, 2026, CISA added a newly exploited Ivanti Connect Secure flaw — CVE-2026-104935 — to its Known Exploited Vulnerabilities (KEV) catalog and urged organizations to patch. The agency described it as a zero-day authentication-bypass vulnerability that lets a remote, unauthenticated attacker run arbitrary commands, and said it is already being used to steal credentials and exfiltrate data.
If you run Ivanti Connect Secure (the VPN/remote-access gateway formerly known as Pulse Connect Secure), the first thing to do is simple: patch to the fixed build and check whether you were already touched. This post covers that. But the more durable lesson sits one level up, and it is the one that separates teams who weather these events from teams who end up in a breach report: an internet-facing gateway that fails open is only the first move. What determines whether this becomes a headline is what the attacker reaches next — and that is something you can control before the next CVE lands.
Let us walk through what happened, how the attack chain actually plays out, and the concrete steps — both immediate and structural — that keep an edge-device zero-day from cascading into a full cloud compromise.
What Happened
Ivanti Connect Secure is a remote-access gateway that sits at the edge of corporate networks. It terminates VPN sessions, authenticates remote employees, and brokers access into internal systems. That position — internet-facing, trusted, and holding the keys to the internal network — is exactly why edge devices like this are among the most attacked assets in the enterprise. A flaw here is not a flaw on some isolated box; it is a flaw on the front door.
Here is what CISA’s advisory tells us about CVE-2026-104935:
- It is an authentication bypass that leads to remote, unauthenticated command execution. An attacker does not need valid credentials, does not need to be on the network, and does not need to chain through a foothold. They send crafted requests to an exposed gateway and get command execution.
- It is being used in the wild for credential theft and data exfiltration — meaning threat actors are harvesting the credentials that flow through or are stored on the device, and pulling data out.
- It was added to the KEV catalog on October 13, 2026, which is CISA’s formal signal that exploitation is confirmed, not theoretical. KEV inclusion also starts a remediation clock for US federal agencies, and it is a strong prioritization signal for everyone else.
The pattern should feel familiar, because Ivanti’s edge products have been a repeat target. Over the last two years, VPN and gateway appliances across the industry — Ivanti, and others in the same category — have been the entry point for some of the most damaging intrusions, precisely because they are reachable, trusted, and often slow to patch. An unauthenticated RCE on one of them is close to a worst case.
How the Attack Chain Actually Plays Out
It helps to separate the vulnerability from the breach, because they are not the same thing and they call for different defenses.
Stage one — the bypass and code execution. The attacker finds an internet-facing Connect Secure instance (trivial; these are discoverable with internet-wide scanning and service fingerprints) and sends requests that exploit the authentication-bypass logic. Because the flaw allows unauthenticated command execution, the attacker now runs commands on the appliance itself. This is the part the patch fixes.
Stage two — credential harvesting. A remote-access gateway is, by design, a place credentials pass through. Attackers who land on the device go after exactly that: cached session material, service-account credentials the gateway uses to talk to internal directories and back-end systems, API tokens, and configuration secrets. CISA’s own language — credential theft and data exfiltration — tells you this is the goal, not code execution for its own sake.
Stage three — pivot and expansion. With harvested credentials, the attacker stops looking like an exploit and starts looking like a legitimate user. They authenticate to internal systems, cloud consoles, and SaaS platforms using the very credentials the gateway was trusted to hold. This is where an edge-device CVE turns into a cloud incident: the gateway’s service account can often reach identity providers, internal apps, and — in cloud-connected environments — roles and secrets that lead into AWS, Azure, or GCP.
The uncomfortable truth is that stage one is the part you cannot fully prevent. Zero-days exist; the next one is already being written. Stages two and three are where the breach is actually won or lost, and they are governed by decisions you make long before any CVE is published: how long credentials live, how broadly they are scoped, and whether you can see the path from the exposed device to the data that matters.
The Immediate Checklist
Do these now, in order. None of them require a project plan.
1. Patch to the fixed build
Apply Ivanti’s fixed release for CVE-2026-104935 across every Connect Secure instance. Treat this as emergency change management, not routine patching. KEV inclusion means exploitation is confirmed and ongoing — the window between disclosure and mass scanning for these appliances is measured in hours, not weeks.
2. Assume compromise and hunt before you call it clean
Patching stops future exploitation; it does not evict an attacker who already got in. For a KEV-listed edge-device RCE, you should actively hunt for signs of prior compromise:
- Run Ivanti’s Integrity Checker Tool and compare against known-good baselines.
- Review gateway logs for anomalous requests to the vulnerable endpoint around and before the disclosure date.
- Look for unexpected processes, new or modified files, and outbound connections from the appliance.
- Check authentication logs on systems the gateway’s service accounts can reach for logins at unusual times or from unusual sources.
3. Rotate every credential the device could touch
This is the step teams skip and regret. If the appliance was reachable and the flaw was being exploited, treat all credentials associated with it as potentially stolen: the gateway service accounts, any directory-bind credentials, API tokens, and secrets in its configuration. Rotate them. A patched device with un-rotated, already-stolen credentials is still wide open — through the front door you just locked.
4. Restrict who can even reach the management surface
Where possible, put the administrative and management interfaces behind network controls so they are not reachable from the open internet. The data-plane VPN endpoint has to be reachable; the management plane usually does not. Reducing what is exposed reduces how many of these you have to fire-drill in the first place.
The Structural Gap: You Cannot Prioritize What You Cannot See
Here is the question that actually decides your outcome when a KEV entry like this lands: “Which of my internet-facing assets is affected, and which of those can reach something that matters?” If answering that takes a day of manual spreadsheet work and Slack messages, you are already behind the scanners sweeping the internet for the same thing.
Most teams do not have a patching-discipline problem. They have a visibility-and-prioritization problem, and it shows up in three ways:
-
Incomplete inventory of what is exposed. A forgotten gateway, a test instance someone stood up outside the standard process, a second appliance from an acquisition — these are exactly the ones that stay unpatched, because they are not on anyone’s list. You cannot patch what you do not know you run.
-
Flat severity. In a typical queue, CVE-2026-104935 on an isolated lab box and the same CVE on your primary internet-facing gateway look identical — both “Critical.” When everything is critical, the genuinely urgent item drowns.
-
No link between the vulnerability and its blast radius. A CVSS score tells you how bad the flaw is in theory. It does not tell you that this gateway’s service account can assume a powerful cloud role, or that it sits one hop from a database of customer records. Without that context, you either try to patch everything at once (impossible) or guess (dangerous).
The Ivanti flaw is a clean illustration. The servers that fall in cases like this are the internet-facing ones whose compromise leads somewhere valuable. A team that can instantly answer “which of my Connect Secure instances are exposed, and what identity and data sit behind them?” has a short, ranked, actionable list. A team that cannot has a wall of undifferentiated red and a slow, manual scramble.
How to Build a Posture That Survives the Next Edge-Device Zero-Day
The checklist handles this CVE. The structural work handles the next one — and there is always a next one. Three capabilities do the heavy lifting.
Continuous external attack-surface visibility
You need an outside-in, continuously updated view of everything you expose to the internet — hosts, ports, services, and the software versions running on them — the same vantage point an attacker uses. When a CVE like this hits the news, “do we run this, and is it exposed?” should be a query that returns an answer in minutes, not a fire drill. Attack surface management is what turns the first and most time-sensitive question of an incident into a lookup. This is also why teams move off point tools and onto continuous CSPM when native and open-source scanners hit their ceiling.
Contextual severity instead of flat scores
The “everything is Critical” problem is fixable. Instead of a fixed severity from a rulebook, severity should be recomputed against real context: whether the asset is internet-facing, whether it is on CISA KEV, how exploitable it is (EPSS), what identity can reach it, and what data is nearby. A theoretical high-CVSS finding on an isolated box drops down the list; a genuinely exposed, actively-exploited one rises to the top with the reasoning attached.
The output is a ranked, explained worklist rather than a flat wall of criticals — the exposed, actively-exploited findings surface first, so the asset that would otherwise be in next month’s breach report gets fixed this week.
This is the heart of contextual severity, and it is why per-rule flat severity is broken for prioritizing real risk. For a deeper treatment of the method, see how to prioritize vulnerabilities based on business risk.
Shrinking the blast radius with short-lived access
Now return to stages two and three — the part the patch does not touch. The attacker’s prize is credentials, and specifically credentials that keep working. If the gateway’s service accounts and the identities it can reach hold standing, long-lived access, a single harvested credential is a durable skeleton key: valid until someone manually rotates it, usable 24/7, scoped far more broadly than the task at hand.
Flip that model and the calculus changes. With just-in-time (JIT) cloud access, privileged access to cloud consoles and roles is not standing — it is requested when needed, scoped to the task, approved through policy, and auto-revoked when the window closes. A credential an attacker exfiltrates after harvesting it from a compromised gateway is either already expired or scoped to almost nothing. The front-door exploit still happens; it just no longer opens the vault. The same short-lived, approval-gated model extends to database access and the service accounts and non-human identities that edge devices so often depend on.
Because this runs alongside posture and identity in one CNAPP+ platform, the connection is explicit: an identity that CSPM and CIEM flag as over-privileged feeds directly into tightening its access policy. “This gateway account can reach too much” leads straight to “so it should not hold that reach when it is not actively using it.” The exposure analysis and the access control are one system, not three tools you cross-reference by hand.
Being Precise About What This Does and Does Not Do
We would rather you deploy this understanding the boundary clearly.
What posture and JIT genuinely change: the blast radius. They do not stop a zero-day from existing, and they do not patch the appliance for you. What they do is ensure that when an edge device is exploited — and some will be — the attacker finds a short, ranked list of exposed assets for you (so you fix the right one first) and a set of short-lived, narrowly-scoped credentials for them (so the harvested credential is nearly worthless).
What still needs the fundamentals: you still patch, you still hunt for compromise, you still rotate credentials after exposure, and you still restrict management-plane exposure. Think of patching as locking the front door and posture-plus-JIT as making sure the house holds nothing valuable that is not actively in use. You want both.
Being honest about this boundary is deliberate. We are not promising to make edge-device zero-days disappear. We are describing how to make the next one a contained, ranked worklist instead of an open-ended cloud breach.
Key Takeaways
- Patch CVE-2026-104935 now, then assume compromise. KEV inclusion means active exploitation. Patch the appliance, hunt for prior intrusion, and rotate every credential the device could touch.
- The exploit is stage one; the breach is stages two and three. The attacker’s goal is credentials that pivot into your cloud and data. That is where the outcome is decided.
- You cannot prioritize what you cannot see. A continuous external attack-surface view turns “are we exposed?” into a minutes-long answer instead of a scramble.
- Flat severity hides the one that matters. Context — internet-facing, on KEV, reachable identity, nearby data — is what separates the urgent instance from the theoretical one.
- Short-lived access breaks the pivot. Standing credentials turn one exploited gateway into a cloud breach. JIT turns a harvested credential into an expired token.
Want to see which of your internet-facing assets would be affected by the next critical CVE — ranked by real exposure, and mapped to the identities and data behind them? Book a demo to see Cloudanix attack surface management, contextual severity, and JIT on your own environment.
People Also Read
- A Patch Existed for a Month. 270+ Servers Still Fell. The Zimbra Lesson Is About Exposure, Not Patching
- What is an Attack Path, and Why Isolated Findings Mislead You
- Why Flat, Per-Rule Severity Is Broken — and What Contextual Severity Fixes
- Which Vulnerabilities Are Actually Running in Production
- What is CSPM?
- What is Vulnerability Management?
- Cloudanix: Just-in-Time Access
