CVE-2026-59654

This CVE describes a resource leak in Apache CloudStack's scoped global configuration system spanning an extraordinary version range—4.7.0 through 4.22.1.0, across eight years and multiple release trains. The leak manifests in different modules (notably Quota and Host-HA), and the dual upgrade paths (4.20.3.1 and 4.22.1.1) suggest either the fix was ported across branches or each branch exhibited distinct manifestations of the same underlying problem. The 'eventual DoS' phrasing is critical. This isn't an on-demand exploit—it requires resource accumulation over time, which means the vulnerability is effectively invisible until your management server degrades. An operator experiencing unexplained slowdowns in month six may never connect it to a configuration leak present since installation. That creates a class of persistent, hard-to-diagnose operational risk fundamentally different from immediate-exploit vulnerabilities. The eight-year detection gap is itself analytically significant. A flaw persisting across independent code paths in multiple modules wasn't caught in code review, wasn't caught in testing, and wasn't caught by the project itself. This suggests the scoped configuration system's API created ergonomic traps—where correct resource handling was difficult to discover, implement, or maintain. When correct behavior is cognitively expensive, bugs reflect design failure, not developer failure. Two operational implications demand attention. First, the patch is forward-looking, not curative: upgrading does not remediate resources already leaked in your deployment. After applying the patch, you must restart the management server to clear accumulated state. Second, the CVSS 6.8 MEDIUM rating is analytically misleading—the exposure window wasn't a moment but eight years of continuous accumulation across every deployment spun up during that period. Deployments experiencing 'unexplained' performance degradation may have been experiencing this leak all along. The disclosure now provides context to re-evaluate past root-cause misdiagnoses. For defenders: apply the relevant patch (4.20.3.1 or 4.22.1.1 depending on your branch), then restart the management server to clear leaked resources. Monitor post-restart resource consumption to confirm the leak is actually closed. If you operate long-running management servers, consider establishing baseline metrics for configuration-related resource handles to detect future accumulation. The architectural question—whether this was fixed at the API level or just patched per-module—will determine whether future modules face the same traps.

Reviewed through automated stages and approved by a human before publication.