[Daniel's week] June 26, 2026

Fri Jun 26 16:09:09 CEST 2026

Hello,

It's been a week.

# release

The release we made this week, curl 8.21.0 [1],  broke at least three new 
project records!

First, we published the largest number of vulnerabilities for a single release 
ever: 18. This huge amount created a new challenge for me in just keeping 
track of them all and explaining them in the release video etc. Let’s hope we 
don’t have a reason to beat this record again. I fear we might though.

The second project record was in the number of people thanked and credited as 
contributors to this release. We included 102 names in the release notes this 
time, which was around ten more names than the previous highscore. This of 
course is a record that I feel better about and I hope we can beat again soon. 
I think it is a good health-sign for the project when we have a lot of people 
involved with a strong interest in improving curl.

The third record is the oldest curl vulnerability reported so far. 
CVE-2026-8932 [2] was included in the curl 7.7 release we shipped in March 
2001, making it more than twenty-five years old. When we list the top-20 
longest lasting vulnerabilities in curl, even the one on the 20th position was 
older than twenty years when found...

Aisle, the company behind six of these latest vulnerability reports, wrote a 
blog post about their work [14].

# security

We saw something of a slow-down in vulnerability reporting last week, but I 
suspect it was just a random fluke or something as we have again received a 
number of new reports after the release shipped. The deluge is not over.

I have been thinking about how to measure and tell when the vulnapocalypse 
eventually slows down or even reaches its end - because yes I am convinced 
that it will happen at some point. We just don’t know if it is within six 
months or four years or something like that. I believe one such tell-sign of 
an approaching end could be when the median age for newly reported 
vulnerabilities starts to seriously drop. This has not happened yet [3]. While 
the median age for curl vulnerabilities dropped when these latest eighteen 
advisories were published, it remains over six years. The average age remains 
at over eight years.

One of the vulnerabilities we reported this time around involved the use of a 
trailing dot for the host name in the URL provided to curl. It was actually 
the third trailing dot related problem fixed in this release alone, and I felt 
the urge to express my frustration in a blog post [4].

After an idea from Stefan Eissing, I created a data visualization video this 
Friday instead of a new graph for the dashboard, illustrating the curl 
vulnerability mounting [5] and how it changes shape over time. It turned out 
pretty cool I think! perl, data, gnuplot and ffmpeg in a glorious combination.

This week we got our first and so far only CVE dispute resolved [6] as the 
powers that be decreed that they stand behind us when we back in November 2025 
decided to not assign a CVE to an issue we decided was not a vulnerability. 
The process was however super weird and totally opaque for everyone involved. 
Not ideal.

# PSL

We have had talks in the curl core team on the PSL situation for curl on 
different platforms and distributions. We involved the Debian curl maintainers 
in this and that resulted in Samuel spotting that the Homebrew curl package 
did not enable libpsl by default [7], making it vulnerable to super-cookies. 
The larger discussion also involves work on making sure and helping more 
distros to update their PSL databases faster.

I also submitted an issue to libpsl [8] about one of the API calls not 
handling trailing dots, which was involved in one of the recently announced 
curl vulnerabilities. Tim Rühsen, the libpsl maintainer, fixed this in no time 
[9].

# inet_ntop

As I wrote up some new test code for the libcurl URL parser API, I get to 
experience that MUSL's inet_ntop() function does not output "::[ipv4]" when 
asked to output an IPv6 address RFC 4291 style. Something both glibc and 
curl's internal replacements do. This output format is deprecated in later 
specifications, it is not mentioned as necessary in POSIX and the MUSL code 
makes no effort to try to support it. I think they are totally entitled to 
this and it seems okay (so I did not submit any bugreport to them), but I 
still want the libcurl URL API to work identically independently of the libc 
used so we had to tweak the curl build this week to make it so. The outcome is 
probably that we always use our own internal inet_ntop() code so that we can 
have it consistent across all platforms.

The reason it matters is because libcurl has an IP address “normalizer” for 
URLs that contain IP addresses instead of hostnames, and that normalizer 
should of course output addresses consistently.

# OpenSSL fuzz

We upgraded to OpenSSL 4.0.1 in our curl-fuzzer [10] repository this week. 
This is the build that is being built and fuzzed as part of the OSS-Fuzz 
effort. We immediately got a heap-buffer-overflow trigger on this version 
which proved to happen deep in a stack trace in OpenSSL code. I reported it 
privately to OpenSSL as it could be security related, but it turns out it 
isn’t and they pointed out someone else already reported this [11]. As a fun 
coincidence it turns out that the “someone else” was from Aisle, the team 
behind six of the last batch of curl CVEs. Friends.

# wolfSSL return code

Like most other Open Source projects, wolfSSL has also been struggling with 
this vulnerability avalanche lately, and they just released a new version with 
many fixes that included many security fixes. As we were trying to upgrade to 
their latest version as part of our CI builds, we ran into an interop issue as 
the new version returns an unexpected return value that now makes one of our 
test cases fail. I submitted an issue to the team about it [12].

# QUERY

I wrote a short blog blurb about the new HTTP method QUERY [13] and what it 
means for curl and how to use it with curl.

## Coming up

- Last week before the summer of bliss starts. Can’t wait

## Links

[1] = https://daniel.haxx.se/blog/2026/06/24/curl-8-21-0/
[2] = https://curl.se/docs/CVE-2026-8932.html
[3] = https://curl.se/dashboard1.html#vulnerability-average-age
[4] = https://daniel.haxx.se/blog/2026/06/25/trailing-dots-are-the-worst/
[5] = https://daniel.haxx.se/blog/2026/06/26/a-curl-mountain-movie/
[6] = https://daniel.haxx.se/blog/2026/06/24/a-cve-dispute/
[7] = https://github.com/Homebrew/homebrew-core/pull/289395
[8] = https://github.com/rockdaboot/libpsl/issues/279
[9] = https://github.com/rockdaboot/libpsl/pull/281
[10] = https://github.com/curl/curl-fuzzer
[11] = https://github.com/openssl/openssl/issues/31315
[12] = https://github.com/wolfSSL/wolfssl/issues/10790
[13] = https://daniel.haxx.se/blog/2026/06/21/query-with-curl/
[14] = https://aisle.com/blog/aisle-discovers-6-new-cves-in-curl-including-the-oldest-issue-ever-reported

-- 

  / daniel.haxx.se