N-able's incident notice this week confirms active exploitation of the maximum-severity remote code execution flaw in its N-central remote monitoring and management platform, the same one Hotfix 3 was supposed to close a day earlier. Hotfix 4 now applies to every on-premises N-central build below version 2026.3.1.14, including servers that administrators had already patched within the last 24 hours. Four emergency releases in five weeks is not a patch cadence. It is a company finding out in production what it did not find in testing.

For a Hong Kong or Singapore bank, N-central sits in the same trust tier as the endpoint agents it manages: an RMM platform with standing access to every device it monitors is a single point of compromise for the fleet. The HKMA's Technology Risk Management framework treats vendor patch management as a supervised control, not a vendor courtesy, which means the relevant question for a compliance team is not whether Hotfix 4 was applied but whether Hotfix 3's failure was logged as a control breach in its own right. A patch that gets replaced within a day is evidence the prior version's assurance testing was inadequate, and that gap belongs in the vendor risk file regardless of whether the second patch holds.

The fix here is not another hotfix cycle. It is isolating N-central's management plane from the internet-facing surface until N-able publishes a root-cause note explaining why three prior releases failed to close the hole, because a fourth patch without that explanation is a guess dressed as a fix.