Apache CloudStack API keys sit below account and domain policy
An Apache CloudStack API key is only the visible half of a credential pair. The secret key signs requests, while the user's account, domain and role decide which commands that credential can execute. Inventory work that finds management interfaces should therefore separate three questions: is the service reachable, can API-key authentication be used and whose authority does the key represent?
Account structure shapes the blast radius
CloudStack organizes resources under domains and accounts. Root administrators cross the whole hierarchy, domain administrators work within a domain and user accounts have narrower scope. API-key access can be disabled for an account or a domain, and a user-level setting can prevent access even when the surrounding account is enabled.
That hierarchy matters during response. Revoking one key may not remove access created through another user in the same account. Changing a domain policy can affect many accounts at once. Keep an inventory of key ownership, creation time, last use, linked user, account and domain, and test the effective command set instead of inferring it from the label on the account.
Role rule order also belongs in the review. A request is checked against configured role rules in order, so a broad allow rule can overshadow a later restriction. Test sensitive commands with the actual user role and include API-key authentication in the test matrix.
Measurements from ZoomEye
On 2026-11-07 UTC, a page-one count-only ZoomEye probe with sub_type=all returned 2,330 matches for app="Apache CloudStack" and 2,228 for title="Apache CloudStack". These are application and title observations, not a count of vulnerable installations. The title query uses ordinary contains matching and can include documentation, mirrors and pages that mention the product without running it.
The similar counts suggest that both fields expose a useful inventory lead for this product. They do not prove version, authentication mode or API-key status. A team should validate each candidate through an owned management path and compare the observed build against supported releases.
Response priorities
Review the historical API-key authorization issue fixed in CloudStack 4.19.3.0 and 4.20.1.0, then verify the installed release and patch path. Audit keys that belong to administrators, keys with no recent use and keys created during recovery or automation. Check whether 2FA policy can be changed through an API credential and restrict that operation to a small administrative group.
After revocation, test the old key from the same network and confirm that it fails for every affected command. Recheck the account and domain policy, because removing the credential does not repair an overly broad role rule.
The useful inventory record combines product evidence, patch state and effective authorization. A count of management pages is only the first field.
Top comments (0)