Why One Hotfix Is Rarely Enough: Planning for Incomplete Patches

N-able's N-central needed four hotfixes between 2 August and 6 September 2026. The first fixed an authentication bypassAuthentication Bypass📖A security vulnerabilityVulnerability🛡️A weakness in software, hardware, or processes that can be exploited by attackers to gain unauthorized access or cause harm. that allows an attacker to circumvent the login verification process and gain unauthorized access to a system without providing valid credentials.. The second fixed the same bypass again, because the first fix was incomplete and attackers were already using the gap. The third and fourth addressed three new flaws, one of them the pre-authentication remote code execution bug CVE-2026-86218 that was exploited before its patchPatch🛡️A software update that fixes security vulnerabilities, bugs, or adds improvements to an existing program. shipped.

Nothing about that sequence is unusual. It is how vulnerability response typically plays out once a product attracts sustained attention, and operators who plan for one clean fix are repeatedly surprised. This article explains why incomplete patches happen, how to recognise when you are in a multi-round cycle, and how to run patching so the second and third rounds do not catch you flat-footed.

Why the first patch is often incomplete

A vendor under pressure to ship a fix has strong incentives to fix the reported exploitExploit🛡️Code or technique that takes advantage of a vulnerability to cause unintended behavior, such as gaining unauthorized access. path rather than the underlying class of bug. That is not laziness; it is the fastest route to a release that stops the specific attack in progress. But the reporter found one path to the bug. If the root cause is a flawed authentication check, an unvalidated parameter, or a mis-scoped access control filter, there are usually other paths to the same weakness.

Several mechanisms produce the follow-up CVE:

**Narrow fix.** The patch blocks the exact request the researcher used, and a slightly different encoding or endpoint gets through. In the N-central case, CVE-2026-18577 was formally described as the result of an incomplete patchIncomplete Patch🛡️A security fix that blocks the reported exploit path without correcting the underlying weakness, leaving an alternative route to the same bug. The follow-up is often assigned its own CVE; N-central's CVE-2026-18577 was formally described as the result of an incomplete patch for CVE-2026-18556. for CVE-2026-18556; both carried the same CVSS score, and the second was exploited from 1 August.

**Attention effect.** Public disclosure of one bug tells every researcher and every attacker where to look. Diffing the patch shows them which code was touched. The three September N-central CVEs, two access control bypasses and the RCE, arrived within a month of the August pair. Whether they were found by the same reporter or by others following the trail, the timing is typical.

**Related components.** A bug in one feature suggests the same developer, the same framework, or the same review gap affected neighbouring features. N-able's descriptions of CVE-2026-86206 (unauthorized access to internal APIs through the access control filter) and CVE-2026-86207 (authentication bypass in internal-only APIs) point at the same general area as the August bypasses.

**Exploit evolution.** Attackers who already have access do not stop when the patch arrives. They look for a way back in, and if the fix was narrow they find it quickly. Huntress's report describes a fully patched server compromised on 4 September, before the vendor had published anything about the new flaw.

How to tell you are in a cycle

Some signals that the current hotfixHotfix🛡️An out-of-cycle software update that addresses a specific urgent defect, usually a security flaw, on an existing release line without waiting for the next scheduled version. Hotfixes are typically numbered and cumulative on that line, but each covers only the issues named in its notes, so a later one may be required. is unlikely to be the last:

• The advisory language says the fix mitigates or addresses a vulnerability rather than resolving a root cause. N-able's first August hotfix was explicitly titled a mitigation.
• A follow-up CVE is described as a bypass of, or an incomplete fix for, an earlier one.
• The product is a high-value target: a management console, a remote-access appliance, an identity system, or anything with broad privilege. These draw sustained research because a single bug pays out across many victims.
• Exploitation was observed before the vendor's disclosure, meaning at least one group already understands the code well enough to find adjacent bugs.
• The fixes arrive as numbered hotfixes on a single release line in quick succession rather than as a planned version bump.

The Collapsing Patch-to-Exploit Window: Planning for N-Day Attacks covers the related problem of exploits appearing within days of a patch; this article is about the case where the patch itself is not finished.

Planning for round two

Treat an actively exploitedActively Exploited🛡️A vulnerability that attackers are currently using in real-world attacks, requiring immediate patching regardless of severity score. flaw in a tier-zero product as the start of a campaign, not an event. Practical adjustments:

**Keep the maintenance window open.** After an emergency hotfix, do not close the change request and return to the monthly cycle. Expect a second release within days and pre-approve applying it the same day. N-able's Hotfix 2 came four days after Hotfix 1; Hotfix 4 came one day after Hotfix 3.

**Verify by build, not by job status.** Record the exact build number the vendor says fixes the flaw (2026.3.1.14 for N-central Hotfix 4) and confirm it in the product after the upgrade. An upgrade that partly failed will report success in enough tools to fool a checklist.

**Treat each hotfix as cumulative but not complete.** Hotfix 3 did not cover CVE-2026-86218. A server on Hotfix 3 was fully patched on Friday and vulnerable on Saturday. When you see a new hotfix, read what it covers before assuming an earlier one is sufficient.

**Reduce exposure so the next bug hurts less.** The most reliable defence against an unknown follow-up flaw is that the attacker cannot reach the vulnerable interface. Restricting the console to a VPN or IP allowlist turns the next pre-auth RCE from a crisis into a scheduled patch. Why RMM Platforms Are the Highest-Value Target on an MSP Network explains why this matters most for management consoles.

**Extend logging before the next round.** Huntress could not identify which CVE was used in its investigation because the server logs had rotated. Increase retention on authentication, session and administrative logs for the affected product for at least 90 days while the cycle plays out.

**Re-audit after each hotfix, not just the first.** A clean audit after Hotfix 2 says nothing about what happened between Hotfix 3 and Hotfix 4. How to Audit an RMM Console After a Vendor Zero-DayZero-Day🛡️A security vulnerability that is exploited or publicly disclosed before the software vendor can release a patch, giving developers 'zero days' to fix it. gives a checklist that can be re-run cheaply.

**Watch the exploited-vulnerabilities catalogue.** CISA added both August N-central CVEs to its Known Exploited Vulnerabilities catalogue within days, with three-day deadlines for federal agencies. As of catalogue version 2026.09.04 the September CVEs had not yet been added. A KEV entry is a reliable signal that a follow-up flaw has crossed from theoretical to actively used.

What to ask the vendor

The advisory rarely says whether the root cause has been fixed or merely the reported path. It is fair to ask, through your account team or support channel: Was this a fix for the underlying issue, or a mitigation for a specific exploit? Has the surrounding code been reviewed for similar flaws? Is a broader release planned? A vendor that answers those questions candidly, as N-able did when it labelled its first hotfix a mitigation, gives you the information you need to keep the maintenance window open.

The operational lesson

An incomplete patch is not a vendor failure so much as a predictable stage in the lifecycle of a widely exploited bug. The operators who come through these cycles well are the ones who assume there will be a second round, keep the change process warm, verify by build number, shrink the exposed surface so the next flaw is less urgent, and keep their logs long enough to know what happened. The ones who get hurt are the ones who applied the first hotfix, closed the ticket, and went back to the monthly schedule.