Vulnerability
curl/libcurl: URL Buffer Overflow
libcurl's URL parser function can overflow a heap based buffer in two ways, if given a too long URL. These overflows happen if you 1 - pass in a URL with no protocol (like "http://") prefix, using no slash and the string is 256 bytes or longer. This leads to a single zero byte overflow of the heap buffer. 2 - pass in a URL with only a question mark as separator (no slash) between the host and the query part of the URL. This leads to a single zero byte overflow of the heap buffer. Both overflows can be made with the same input string, leading to two single zero byte overwrites. The affected flaw cannot be triggered by a redirect, but the long URL must be passed in "directly" to libcurl. It makes this a "local" problem. Of course, lots of programs may still pass in user-provided URLs to libcurl without doing much syntax checking of their own, allowing a user to exploit this vulnerability.
No CVSS 3.x base score yet. Since April 2026 NVD only enriches priority CVEs (KEV, federal and critical software), so most CVEs are scored only if the assigning CNA included a score in the CVE record, or by GHSA for open-source packages. Last record update .
For interim severity, fall back on KEV / EXPLOIT signals and the EPSS percentile (lower panel). Re-check this CVE after one cron tick — the score lands automatically when the source publishes.
Low exploitation likelihood — defer if no other signals fire.
No VEX statements published for CVE-2005-4077. Vendors publish VEX (Vulnerability Exploitability eXchange) to assert per-product whether a CVE is actually exploitable in their distribution.
No exploitation, limited impact or prevalence