The core vulnerability in CVE-2026-54367 is not the missing authorization checks — it's the static shared encryption key that CentreStack uses to generate EntAcctId values. This key encrypts user GUIDs across the entire installation, including the cluster-level account that governs tenant isolation. Once you understand the encryption scheme, you can generate valid identifiers for any user, including administrators, without ever authenticating. The missing authorization checks aren't a separate flaw; they're a consequence of an encryption model that assumes the key never leaves the system.
This makes exploitation deterministic rather than probabilistic. The CVSS 8.6 reflects the severity accurately, but the EPSS of 0.00188 is misleading — EPSS models likelihood of exploitation assuming the key remains secret. In practice, the key may have been distributed far beyond the CentreStack server: embedded in configuration files, stored in backups, present in container images, or accessible to every MSP or support technician who administered a deployment. An attacker who obtains the key doesn't guess or brute force; they compute valid session identifiers at will.
The blast radius is total and simultaneous, not escalating. Compromising the cluster settings account gives you administrative control over every tenant, every dataset, and all isolation boundaries simultaneously. This isn't privilege escalation within a tenant — it's infrastructure-wide credential forgery.
Prioritise these actions: First, confirm whether your CentreStack deployment uses a static encryption key (versions before 17.2) and assess how many parties have had filesystem or backup access to that key over the product lifetime. Second, upgrade to 17.2 immediately, but verify whether the patch introduces per-deployment key generation or merely obfuscates the existing static key — the latter leaves the architecture fundamentally unchanged. Third, audit logs for enumeration activity against tenant administrator accounts prior to patching; if the key was obtained, attackers would have targeted cluster settings accounts first. Fourth, treat old CentreStack binaries, backups, and decommissioned hardware as potentially containing exposed key material — revoke and rotate all tenant credentials post-patch under the assumption the key may have been compromised.