Approved changes feed: RSS · Atom

cpe:2.3:a:haxx:libcurl:7.54.1:*:*:*:*:*:*:*

part: a version: 7.54.1 update: *

VendorHaxx (d671a1c6-5c93-5e0c-94d0-7f7092cb4b41)
ProductLibcurl (3b3523ef-9710-50bf-8391-80ac7eb566e1)
Edition*
Language*
Software edition*
Target software*
Target hardware*
Other*
NotesImported from NVD CPE 2.0 feed

PURL mappings

PURLSourceLast updated
pkg:curl/libcurl purl2cpe 2026-06-01 10:12:18.985579
pkg:deb/debian/curl purl2cpe 2026-06-01 10:12:18.985581
pkg:deb/ubuntu/curl purl2cpe 2026-06-01 10:12:18.985582
pkg:github/curl/curl purl2cpe 2026-06-01 10:12:18.985584
pkg:rpm/fedora/curl purl2cpe 2026-06-01 10:12:18.985585
pkg:rpm/opensuse/curl purl2cpe 2026-06-01 10:12:18.985586

Vulnerability references

IdentifiercpeApplicabilitySubmitteddb.gcve.eu detailsRationale
CVE:CVE-2017-1000254 vulnerable 2026-06-08 05:08:34.379467 Details available
libcurl may read outside of a heap allocated buffer when doing FTP. When libcurl connects to an FTP server and successfully logs in (anonymous or not), it asks the server for the current directory with the `PWD` command. The server then responds with a 257 response containing the path, inside double quotes. The returned path name is then kept by libcurl for subsequent uses. Due to a flaw in the string parser for this directory name, a directory name passed like this but without a closing double quote would lead to libcurl not adding a trailing NUL byte to the buffer holding the name. When libcurl would then later access the string, it could read beyond the allocated heap buffer and crash or wrongly access data beyond the buffer, thinking it was part of the path. A malicious server could abuse this fact and effectively prevent libcurl-based clients to work with it - the PWD command is always issued on new FTP connections and the mistake has a high chance of causing a segfault. The simple fact that this has issue remained undiscovered for this long could suggest that malformed PWD responses are rare in benign servers. We are not aware of any exploit of this flaw. This bug was introduced in commit [415d2e7cb7](https://github.com/curl/curl/commit/415d2e7cb7), March 2005. In libcurl version 7.56.0, the parser always zero terminates the string but also rejects it if not terminated properly with a final double quote.
Published: 2017-10-06T13:00:00.000Z
Updated: 2024-08-05T22:00:39.675Z
Reference links
Imported from gcve-enriched-dumps CVE data
CVE:CVE-2017-1000100 vulnerable 2026-06-08 05:08:33.975190 Details available
When doing a TFTP transfer and curl/libcurl is given a URL that contains a very long file name (longer than about 515 bytes), the file name is truncated to fit within the buffer boundaries, but the buffer size is still wrongly updated to use the untruncated length. This too large value is then used in the sendto() call, making curl attempt to send more data than what is actually put into the buffer. The endto() function will then read beyond the end of the heap based buffer. A malicious HTTP(S) server could redirect a vulnerable libcurl-using client to a crafted TFTP URL (if the client hasn't restricted which protocols it allows redirects to) and trick it to send private memory contents to a remote server over UDP. Limit curl's redirect protocols with --proto-redir and libcurl's with CURLOPT_REDIR_PROTOCOLS.
Published: 2017-10-04T01:00:00.000Z
Updated: 2026-04-16T13:34:51.252Z
Reference links
Imported from gcve-enriched-dumps CVE data
CVE:CVE-2017-1000099 vulnerable 2026-06-08 05:08:33.931906 Details available
When asking to get a file from a file:// URL, libcurl provides a feature that outputs meta-data about the file using HTTP-like headers. The code doing this would send the wrong buffer to the user (stdout or the application's provide callback), which could lead to other private data from the heap to get inadvertently displayed. The wrong buffer was an uninitialized memory area allocated on the heap and if it turned out to not contain any zero byte, it would continue and display the data following that buffer in memory.
Published: 2017-10-04T01:00:00.000Z
Updated: 2024-08-05T21:53:06.676Z
Reference links
Imported from gcve-enriched-dumps CVE data

Contribute

You can submit an edit proposal for this CPE entry or suggest a related product/vendor addition using the action button above.