CVE-2013-6480 json
Libcloud does not properly scrub data when destroying a DigitalOcean node
published 2014-01-07 12 y ago modified 2026-06-17 4 mo ago also GHSA-g892-9h8m-r69r , PYSEC-2014-97 , EUVD-2014-0003
- cvss
- 2.1
- version 2.0, NVD
- cisa kev
- Not listed
- not in CISA's catalog
- epss
- 2.1%
- EPSS 2.1% chance of exploitation in 30 days, percentile 81%
- public exploits
- 1
- Exploit-DB
Summary
Libcloud 0.12.3 through 0.13.2 does not set the scrub_data parameter for the destroy DigitalOcean API, which allows local users to obtain sensitive information by leveraging a new VM.
Patch / fix
Vendor advisories
What the vendors themselves say about their products: affected, fixed or not affected, and what to do.
red hat product security vex CVE-2013-6480 updated cvss 2.6
python-libcloud: doesn't send scrub_data query parameter when destroying a DigitalOcean node
-
Red Hat All currently supported Red Hat productsnot affected: vulnerable code not present
Red Hat CSAF VEX © Red Hat, Inc., from https://security.access.redhat.com/data/csaf/v2/vex/; changed: reduced to product statuses and remediations. CC BY 4.0 · csaf
Timeline
- First public exploit (EDB-38937)
- Published
Exploit prediction
2.06% chance of exploitation in the next 30 days, higher than 81% of all scored CVEs (FIRST EPSS, 2026-11-09).
Exploits and checks
- EDB-38937 Apache Libcloud Digital Ocean API - Local Information Disclosure local, 2014-01-01
CVSS scores
| assigned by | version | score | vector |
|---|---|---|---|
| NVD | 2.0 | 2.1 | AV:L/AC:L/Au:N/C:P/I:N/A:N |
Affected packages
| ecosystem | package | affected | fixed in |
|---|---|---|---|
| pypi | apache-libcloud | >=0.12.3, <0.13.3 |
0.13.3 |
Classification
- Weakness
-
- CWE-200 Exposure of Sensitive Information to an Unauthorized Actor
References
-
github.com
/apache/libcloud/commit/4449e165a00756dc61430e6ad9520f005b045d29
web
-
lists.opensuse.org
/opensuse-updates/2014-02/msg00015.html
vendor-advisory, web
-
libcloud.apache.org
/security.html
web, vendor-advisory
-
securityfocus.com
/bid/64617
vdb-entry, web
-
securityfocus.com
/archive/1/530624/100/0/threaded
mailing-list, web
-
digitalocean.com
/blog_posts/transparency-regarding-data-security
article
-
github.com
/fog/fog/issues/2525
web, report
-
nvd.nist.gov
/vuln/detail/CVE-2013-6480
advisory
-
github.com
/apache/libcloud
package
-
github.com
/apache/libcloud/blob/abba8c1719a8bda6db8efde2d46fd1b423ae4304/CHANGES.rst#compute-48
web
-
github.com
/pypa/advisory-database/tree/main/vulns/apache-libcloud/PYSEC-2014-97.yaml
web
-
issues.apache.org
/jira/browse/LIBCLOUD-487
web
-
web.archive.org
/web/20131230232003/https://digitalocean.com/blog_posts/transparency-regarding-data-security
web
-
web.archive.org
/web/20140129025443/http://www.securityfocus.com/bid/64617
web
-
web.archive.org
/web/20201209074449/http://www.securityfocus.com/archive/1/530624/100/0/threaded
web
-
github.com
/advisories/GHSA-g892-9h8m-r69r
advisory
Sources
- CVE List CVE-2013-6480
- GitHub Advisory GHSA-g892-9h8m-r69r
- NVD CVE-2013-6480
- OSV PYSEC-2014-97
Fencer Intel keeps one entry per vulnerability: the CVE id wins, then GHSA, and records that alias each other are merged, except that two CVEs always keep separate entries. The same data is available as JSON.