Ivanti Connect Secure vulnerability: what to ask IT now

The Ivanti Connect Secure vulnerability chain that CISA added to its Known Exploited Vulnerabilities (KEV) catalog on October 30, 2026 is being used in real attacks against a VPN appliance many organizations rely on for remote access. If you run Ivanti Connect Secure, directly or through an IT provider, treat this as a this-week item: confirm patch status, check the appliance for signs of compromise, and reset the credentials that pass through it.

This briefing is written for executives and leadership teams who need to ask the right questions, not configure the device themselves. It explains what the flaws do, what KEV listing means, how to confirm exposure, what to tell your IT team or managed service provider (MSP), and when the situation has moved from patching to incident response.

What the Ivanti Connect Secure vulnerability chain does

Two newly listed flaws are at the center of this event:

• CVE-2026-118527 is listed in the National Vulnerability Database as a generation of predictable numbers or identifiers vulnerability in Ivanti Connect Secure.
• CVE-2026-111357 is listed as a missing authentication for critical function vulnerability in the same product.

In plain language:

• Predictable identifiers. Software often names files, sessions or tokens with values that are supposed to be hard to guess. When those values are predictable, an attacker can locate or reach things they should never be able to find.
• Missing authentication for a critical function. A sensitive action that should require a login can be triggered without one.

As the chain has been described, these weaknesses work together: the attacker gets a file onto the appliance in a location they can predict, then uses it and escalates privileges to take greater control of the device. The chain has also been linked to CVE-2026-104935, an associated Ivanti flaw. Ivanti's advisory is the authority on the exact role of each CVE and which versions are affected, and your IT team should read it against the version you actually run.

Why a VPN appliance compromise is a business problem

A remote access appliance is your front door. It sits on the internet and inside your network at the same time. It usually holds or brokers:

• Employee and contractor login sessions
• A trust relationship with your directory, often through a service account
• Certificates and keys that identify your organization
• Network routes into internal systems

A VPN appliance compromise therefore gives an attacker a position inside the network that looks like legitimate remote access. It also tends to be a blind spot. Appliances like this generally cannot run the endpoint security software that protects laptops and servers, so activity on the device itself is easy to miss.

Do the flaws require authentication?

One of the two weaknesses is, by its classification, about a critical function that lacks authentication. That is a serious category for an internet-facing device, because it suggests at least part of the chain may be reachable by someone who has never logged in. Confirm the exact preconditions in Ivanti's advisory.

Even where a step does require a login, do not take much comfort. VPN credentials are a common target for phishing, and password reuse is widespread. If any part of the chain needs a valid account, assume an attacker can obtain one. That is also why the credential resets later in this article are not optional.

Is the Ivanti VPN exploit active, and what CISA KEV listing means

Yes. CISA adds a vulnerability to the KEV catalog only when there is evidence it is being exploited in the wild. KEV is not a list of theoretical risks. It is a list of flaws attackers are using.

What the listing means depends on who you are:

• Federal civilian agencies are required under CISA's Binding Operational Directive 22-01 to remediate KEV entries by the due date CISA sets.
• Federal contractors are not directly bound by that directive, but the expectation tends to flow down. Agency customers and prime contractors often use KEV as a baseline, and they may ask. If your contracts include cyber incident reporting clauses, a confirmed compromise may start a reporting clock. Know those terms before you need them.
• Everyone else should treat a CISA KEV Ivanti listing as a strong signal that patching cannot wait for the next maintenance window. Insurers, auditors and customers may ask how quickly you acted.

For organizations in Northern Virginia and Washington, DC that serve government customers, the practical point is simple: you will likely be asked whether you were affected and what you did. A dated, written record of your response is worth creating now.

How to find out if you run Ivanti Connect Secure

Many leaders do not know which remote access product their organization uses, especially when an MSP runs it. Here is a quick way to find out.

1. Ask in writing. Send your IT lead or MSP one question: "Do we run Ivanti Connect Secure, Ivanti Policy Secure or any other Ivanti gateway, and what version?" Ask for a reply today.
2. Check for older names. The product was formerly called Pulse Connect Secure. Some staff still know it as "Pulse" or "the Pulse VPN."
3. Look at what your remote staff use. If employees connect through an Ivanti Secure Access client, or a login page branded Ivanti or Pulse Secure, you have the appliance somewhere.
4. Review your internet-facing systems. Your IT team or an outside assessor can list what your public IP addresses expose. Remote access gateways are usually easy to identify this way.
5. Ask your critical vendors. A vendor or MSP that connects into your environment through its own Ivanti appliance is part of your exposure. If that appliance is compromised, the attacker may reach you through it.

If the answer is "we don't know" after a day, that is a finding in itself. An accurate inventory of internet-facing systems is a basic control. If yours is incomplete, a cybersecurity risk assessment (expert-led) is a reasonable next step once the immediate response is done.

What to do now: Ivanti Connect Secure patch and containment steps

Give your IT team or MSP this list. The order matters.

1. Confirm the version and the fix. Compare your running version against Ivanti's advisory. Apply the fixed release. If a fix is not yet available for your version, apply Ivanti's published mitigation and consider restricting who can reach the appliance until it is.
2. Preserve evidence first. Before rebooting, resetting or upgrading, export the appliance's logs and configuration. If something is found later, this is what investigators will need.
3. Run an integrity check before and after patching. Ivanti provides an Integrity Checker Tool for Connect Secure, including an external version. Patching closes the door. It does not remove an attacker who is already inside.
4. Reset credentials that touch the appliance. This includes local administrator accounts, the directory service account the appliance uses to check logins, and any API keys. Plan to reissue certificates and private keys stored on the device if there is any sign of compromise.
5. End active sessions. Revoke existing VPN sessions so every user re-authenticates under the patched system. Consider resetting passwords for users who connected during the exposure window.
6. Send logs off the device. Forward appliance logs to a central log system you control and keep them. An attacker with control of the appliance can alter logs stored on it.
7. Lock down the management interface. The administrative interface should be reachable only from an internal administration network, never from the open internet.
8. Document what was done and when. Version before and after, patch time, integrity check results, credentials rotated. This record answers the questions customers, insurers and your board will ask.

How to tell whether you were already compromised

An Ivanti Connect Secure patch protects you from the date it is applied. The harder question is what happened before. Ask your team to look for:

• Integrity checker results showing new, modified or unexpected files
• Unfamiliar files in web-accessible directories on the appliance
• New or changed administrator accounts, or configuration changes nobody can explain
• Outbound connections from the appliance to unfamiliar addresses
• VPN sessions from unexpected countries, at unusual hours, or for accounts that rarely connect
• Unusual directory activity from the appliance's service account, such as queries or logins outside its normal pattern
• Gaps in logs, or logging that was turned off

A clean result is encouraging, not conclusive. A capable attacker who controls a device can tamper with what it reports, which is why off-device logs and an external integrity check carry more weight than anything the appliance says about itself.

When to bring in incident response

Move from patching to incident response if any of these are true:

• The integrity check flags anything you cannot explain
• The appliance was unpatched and internet-facing during the period of active exploitation, and you lack logs to rule out access
• You see suspicious activity on internal systems reachable from the VPN
• You handle government, regulated or sensitive client data and may have contractual reporting duties

If you do not already have an incident response plan and a retained responder, put both in place as part of this response. Do not wipe the appliance before evidence is captured, and involve legal counsel early if reporting obligations may apply.

Should you keep relying on Ivanti edge appliances?

This is a fair question. Ivanti Connect Secure and its predecessor have appeared in CISA's KEV catalog several times in recent years. Leaders are right to ask whether the pattern is acceptable.

The honest answer is that every internet-facing remote access product is a target, and replacing one appliance does not by itself fix the underlying risk. The decision should rest on a few questions:

• How fast can we patch? If edge devices routinely wait weeks for updates, the product matters less than the process.
• How much does a VPN login grant? If a VPN session puts a user on a flat network with access to everything, any compromise is serious. Segmenting so remote users reach only what they need limits the damage.
• How strong is the login? Phishing-resistant multifactor authentication, such as hardware security keys, makes stolen passwords far less useful.
• Do we need a network-level VPN at all? Many organizations now publish individual applications through identity-aware access instead of placing users on the network. That reduces the value of any single edge device.
• Can we see what the device is doing? If the answer is no, add off-device logging and monitoring regardless of vendor.

Make this decision deliberately, after the immediate response is complete, with a clear view of cost, disruption and risk. A rushed migration during an incident creates new gaps. If you want senior outside input on that decision, see our fractional CISO services.

What to tell the board this week

The board does not need technical detail. It needs to know whether the organization was exposed, what was done, and what decision, if any, is being asked of it. A short written update should cover:

• Whether you run the affected product, directly or through a provider
• The date the fix or mitigation was applied
• Integrity check and log review results
• Whether incident response was engaged, and why or why not
• Any customer, contractual or insurance notifications under consideration
• Whether a longer-term remote access review is recommended

Directors can use these questions to test the answer:

| Question for management | A good answer sounds like | |---|---| | Do we run Ivanti Connect Secure, including through vendors? | Yes or no, with versions, confirmed in writing by IT and the MSP | | When was it patched? | A specific date and time, compared with the KEV listing date | | How do we know we were not compromised before patching? | External integrity check, off-device log review, credential resets completed | | What could an attacker have reached through it? | A clear description of what VPN users can access | | How fast do we patch internet-facing systems in general? | A defined target that is measured and reported | | What would make us change products or architecture? | A planned review with criteria, not a reaction |

For more on structuring these updates, see our article on board cyber reporting.

The practical takeaway

This is an exploited flaw in the device that controls remote access to your network. Find out today whether you run it, including through providers. Patch or mitigate, check integrity before and after, preserve logs, rotate the credentials that pass through the appliance, and escalate to incident response if anything is unexplained. Then, once the urgency has passed, decide on purpose how much your organization should depend on any single internet-facing appliance, and how quickly you expect such devices to be patched the next time.

If you want help assessing your exposure, request a consultation or see what our cybersecurity assessment covers.

For the field guide version of what I publish here each week, pick up a copy of Exposed: Inside Risks and the New Architecture of AI Defense on Amazon.

NightFortress works with executives, founders and leadership teams in Northern Virginia and the DC metro area to assess exposure, govern risk, and build security programs that match the actual threat landscape. Contact us to start a conversation.

The information in this article is for educational and informational purposes only. It is not intended as legal, compliance, or professional cybersecurity advice for any specific organization. Consult qualified professionals before making security or compliance decisions.