Why Partial Security Patches Mean Upgrading Twice

Partial security patches fix part of a vulnerability chain and leave the rest for a later release, so an appliance that was fully patched last week can be listed as vulnerable this week. Ivanti Connect Secure showed this in October 2026: the October 13 fix closed the authentication bypass, and the root privilege escalation needed a second upgrade on October 29. Plan for this pattern on every edge device you run.

What is a partial security patch?

A partial security patch is a vendor release that closes some of the flaws used in an attack but not all of them. The vendor ships what is ready, usually the step that is easiest to reach from the internet, and finishes the rest later.

It is usually a reasonable decision. Ivanti explained it directly: when it found exploitation, its fix for CVE-2026-104935 was already in quality assurance, "and we made the decision to not delay getting a fix to customers that resolved the primary exploitation path when the LPE was discovered." Closing the unauthenticated entry point breaks the chain for outside attackers. Waiting for every fix would have left that entry point open for another two weeks.

Why does a partial patch mean upgrading twice?

A partial patch means upgrading twice because the build that fixed the first flaw is the build that contains the remaining ones. When the second fix ships, it is a new version, and the version you just installed moves onto the affected list.

In the Ivanti case:

• October 13: 25.1.1.2 and 22.8R2.5 fixed CVE-2026-104935.
• October 29: 25.1.1.3 and 22.8R2.6 fixed CVE-2026-111357 and CVE-2026-118527. The affected list for the new CVEs is 25.1.1.2 and earlier, and 22.8R2.5 and earlier.

Every team that patched promptly in October was back on a vulnerable build two weeks later. Details are in our report on the Ivanti Connect Secure CVE-2026-111357 fix.

There was also an earlier partial step. Ivanti said its own product security program found part of the issue and fixed it in 25.1.3.0 in July, then started backporting the fix to other branches. Exploitation began before that work was done.

Where the process usually breaks

The patch itself is rarely the problem. The tracking around it is.

• Tickets close on the first fix. The change record says "CVE-2026-104935 remediated" and the item leaves the queue. Nobody is assigned to watch for the second release.
• Advisories change in place. Ivanti added the new CVEs to the existing October 13 advisory instead of publishing a new one. If you only watch for new advisories, you miss revisions.
• Low scores get deferred. CVE-2026-118527 is rated 4.3. Sorted by CVSS alone, it waits for the next quarterly window, even though it is a link in an exploited chain.
• Change windows are spent. VPN upgrades disconnect remote users, so teams fight for one window. A second emergency window two weeks later is harder to get.

How should you plan for staged fixes?

Plan by keeping the vulnerability open until the vendor states the whole chain is fixed, and by agreeing in advance that a follow-up release gets the same emergency priority as the first one.

Practical rules that work:

1. Track the chain, not the CVE. When a researcher or vendor describes several flaws working together, open one item for the chain and close it only when every stage has a fix installed. Volexity's October write-up named three stages; the first Ivanti fix covered two.
2. Record "fix pending" explicitly. If the vendor says a fix is coming "in the coming weeks," put a review date on the ticket and an owner on it.
3. Watch revisions, not just releases. Subscribe to the vendor's advisory feed and re-check open advisories weekly until they say all issues are addressed. The site's guide on why vendor security advisory subscriptions matter covers setting that up.
4. Use KEV as the priority signal. CISA listed both new Ivanti CVEs on October 30 with deadlines of November 2 and November 13. A KEV listing means the flaw was exploited, whatever its base score. For more on scoring chained flaws, see what a predictable identifier vulnerability is.
5. Pre-approve the second window. When you raise the first emergency change, note that a follow-up release is expected and get the second window approved in principle at the same time.

Why does this keep happening with edge devices?

It keeps happening because VPN gateways and other edge appliances combine an internet-facing pre-login surface, several supported release branches and attackers who find chains faster than vendors can backport fixes to every branch.

Each extra branch is another build the vendor must fix, test and release. Ivanti's October advisory covered the 22.8, 25.1.1, 25.1.2 and 25.1.3 code lines, and the fixes did not arrive on all of them at once. Coverage of the advisory also noted a January 31, 2027 end-of-life date for the 22.x line. Running fewer branches, and moving off a line before its end of life, shortens the gap between a fix existing and a fix being available for your box. The background on branch strategy is in why firmware release trains matter for patching.

Patching is not the same as being clean

A second upgrade closes the remaining flaws. It does nothing about an attacker who used them before the fix existed. For Connect Secure, the privilege escalation was exploited for weeks while no patch was available. Pair every staged fix with a compromise check: see how to detect Ivanti Connect Secure exploitation for the signals to look for.