dbcve.org
CloudstackApplication · Apache

CVE-2024-39864

CRITICAL · 9.8 CVSS v3.1 Published 2024-07-05
Fix available
A fix is available. Upgrade to 4.18.2.1 / 4.19.0.2 or later.
See remediation →
100/100
Remediation priority · Urgent
Remotely reachable No privileges Zero-click

Official description Straight from the sourceThe vendor's or NVD's own wording, published unedited. Authoritative, but often terse — it says what broke, rarely what to do.

NVD · unedited
The CloudStack integration API service allows running its unauthenticated API server (usually on port 8096 when configured and enabled via integration.api.port global setting) for internal portal integrations and for testing purposes. By default, the integration API service port is disabled and is considered disabled when integration.api.port is set to 0 or negative. Due to an improper initialisation logic, the integration API service would listen on a random port when its port value is set to 0 (default value). An attacker that can access the CloudStack management network could scan and find the randomised integration API service port and exploit it to perform unauthorised administrative actions and perform remote code execution on CloudStack managed hosts and result in complete compromise of the confidentiality, integrity, and availability of CloudStack managed infrastructure. Users are recommended to restrict the network access on the CloudStack management server hosts to only essential ports. Users are recommended to upgrade to version 4.18.2.1, 4.19.0.2 or later, which addresses this issue.

Technical summary Written by usOur analysis, written from the advisory, the CVSS vector and the affected-version data. It adds context the advisory leaves out, and never invents facts that are not in the source.

dbcve analysis · high confidence

Apache CloudStack's integration API service has an improper initialization logic flaw. When the integration.api.port is set to 0 (the default value), instead of being disabled as intended, the service binds to a random available port. An attacker on the management network can discover this port via scanning and exploit the unauthenticated API to perform administrative actions and achieve remote code execution on managed hosts.

MitigationUpgrade to CloudStack version 4.18.2.1 or 4.19.0.2 or later, and restrict network access to the management server to only essential ports.

Verify against the referenced sources before acting — the references below are authoritative for this CVE, this summary is not.

Affected products & versions What the vendor confirmedThe version ranges the vendor confirmed as vulnerable. If your version sits inside a range here, treat yourself as exposed until you have upgraded.

NVD · CPE data
CloudstackApplication
Affected:>= 4.0.0, < 4.18.2.1>= 4.19.0.0, < 4.19.0.2

CVSS breakdown How the score is builtThe industry scoring standard. It rates how the flaw is reached, what it takes to exploit, and what an attacker gains — the score is derived from those, not the other way round.

From the vector
Attack vector
Network
Complexity
Low
Privileges
None
User interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
High
Availability
High

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Am I affected? How to checkSteps we derive from the advisory and the affected-version data, so you can decide whether this CVE reaches your setup. They are a guide, not a scan — your own configuration is the authority.

dbcve checks

Work through these to decide whether this CVE applies to you.

  1. Determine CloudStack version
    Query the CloudStack API endpoint /api/apiVersion or check the management server JAR files (cloud-server-*.jar) in /usr/share/cloudstack-management/lib/ or check RPM/DEB package version with 'rpm -q cloudstack-management' or 'dpkg -l cloudstack-management'
    Affected if Version is 4.0.0 through 4.18.2.0, or 4.19.0.0 through 4.19.0.1 (check against the affected ranges given)
  2. Locate integration API configuration
    Search for the 'integration.api.port' setting in the CloudStack configuration files such as /etc/cloudstack/management/cloud.properties or /etc/cloudstack/agent/agent.properties, or query the CloudStack configuration table in the database
    Affected if The configuration file or database contains 'integration.api.port=0' as the setting value
  3. Verify port is unexpectedly listening
    Run 'netstat -tlnp' or 'ss -tlnp' on the management server and look for any listening ports in the ephemeral range (typically 49152-65535) that are NOT the standard CloudStack ports (8096, 8080, 8443)
    Affected if A non-standard port is listening and responds to requests at /client/api (unauthenticated)
  4. Test integration API accessibility
    Use curl to send an unauthenticated API request to the potentially exposed port: curl -s 'http://<management-server>:<port>/client/api?command=listUsers' - analyze the response
    Affected if The API returns user data or any administrative response without requiring authentication

You are affected if your CloudStack version falls within the vulnerable ranges AND integration.api.port is set to 0 AND an unexpected port is listening that exposes the unauthenticated integration API.

Generated from the published advisory. Verify against your own configuration.

Check your environment

Paste your version and any relevant configuration and it will be compared against the affected criteria above. Do not include secrets or credentials.

AI-assisted, checked against the advisory. Informational, not a guarantee.

Remediation Closing itWhat it takes to close this. Where a vendor fix exists we point at it; where none exists we say so plainly, and can build one. Effort estimates are scoped from the advisory, not from your codebase.

dbcve · scoped
Upgrade available Upgrade to 4.18.2.1 / 4.19.0.2 or later
Fixed in 4.18.2.14.19.0.2
Interim mitigation

Upgrade to CloudStack version 4.18.2.1 or 4.19.0.2 or later, and restrict network access to the management server to only essential ports.

Recommended fix High confidence

4.18.2.1 or 4.19.0.2

  1. Identify the current CloudStack version by checking the management server
  2. If running version >= 4.0.0 and < 4.18.2.1, plan upgrade to 4.18.2.1 or later
  3. If running version >= 4.19.0.0 and < 4.19.0.2, plan upgrade to 4.19.0.2 or later
  4. Review upgrade documentation at https://docs.cloudstack.apache.org/en/upgrade/ for your current version
  5. Perform a backup of the CloudStack database and configuration
  6. Test the upgrade in a non-production environment first
  7. Execute the upgrade following the official upgrade path
  8. After upgrade, verify integration.api.port is not set to 0 (set to a specific port or leave disabled)
Caveat Review release notes for version-specific breaking changes before upgrading

Generated from the published advisory — verify against the referenced sources before acting.

Fix this in Cloudstack Scoped from the published advisory
  • Consultation4.0 h
  • Implementation2.0 h
  • Testing4.0 h
  • Review / QA2.0 h
12.0 hours of engineering $2,120
Get the upgrade done

An estimate, not a bill — we confirm scope with you before any work starts. Need it this week? Rush from $3,392.

Scan for this in your stack

Free · runs locally
dbcve dependency scanner

Check whether your project pulls in CVE-2024-39864 — or any other known-vulnerable package — straight from your lock files. Free and open source; it runs locally and uploads nothing.

Get it on GitHub Scan in the browser

References Go to the primary sourcePrimary sources — vendor advisories, patches and trackers. Where our summary and a reference disagree, the reference wins.

Primary sources

Practitioner notes

Contributed

Peer-ranked notes from engineers who’ve handled CVE-2024-39864 in production — separate from our analysis above.

No notes yet

Be the first to add a field note for this CVE — a mitigation you’ve verified, a version caveat, or a link to a working fix. Sign in above to contribute.

What this is

A place for practitioners to share what actually worked: a mitigation you’ve tested, a configuration change, a version- or environment-specific caveat, or a link to a verified patch. The most useful notes rise to the top as peers upvote them, so the signal stays high.

What belongs here
  • Verified mitigations, workarounds, and config changes
  • Version or environment caveats, and links to real fixes
  • No weaponised exploit code, or anything meant to cause harm
  • No spam, self-promotion, credentials, or personal data