Buy commercial curl support. We
help you work out your issues, debug your libcurl applications, use the API,
port to new platforms, add new features and more. With a team lead by the
curl founder Daniel himself.
Re: [SECURITY ADVISORIES] for curl 8.21.0
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Dan Fandrich via curl-users <curl-users_at_lists.haxx.se>
Date: Sat, 27 Jun 2026 11:09:02 -0700
On Sat, Jun 27, 2026 at 11:24:42AM -0600, toby via curl-users wrote:
> are any of these exploitable?
We wouldn't have created security advisories if we didn't feel they were
potentially exploitable. But, most of them require very specific configurations
with specific preconditions to be an issue.
For example (to pick one at random) for CVE-2026-9080: UAF after pause in
socket callback (LOW), the application would need to call curl_easy_pause()
within the event-based CURLMOPT_SOCKETFUNCTION to be at risk. If the
application doesn't call curl_easy_pause() then this CVE isn't exploitable
there. But even if the application DOES call curl_easy_pause() in the callback,
that doesn't mean it's automatically at risk. A remote attacker would need to
have some control over (or know deterministically) what that memory will be
used for next and potentially what gets overwritten in the buffer, too, in
order to have a hope of getting remote code execution, and even then it might
not be possible. It would also need to be able to control (or know exactly
when) when curl_easy_pause() is called. It might "merely" result in a simple
crash, which is a DoS and also not good, but since we can't completely rule out
the possibility of something worse, it gets a CVE. But it's rated low because
the chance that everything could align to make it dangerous is also low.
> i do find it amazing and sorta scarry that the ai (i assume it was ai bots that scrutinized your release in 4 minutes) can locate such esoteric (to me anyway) 'bugs'
Some of the things they're finding these days are very impressive. As they get
better with time, the issues they're finding are more and more crafty.
Dan
Date: Sat, 27 Jun 2026 11:09:02 -0700
On Sat, Jun 27, 2026 at 11:24:42AM -0600, toby via curl-users wrote:
> are any of these exploitable?
We wouldn't have created security advisories if we didn't feel they were
potentially exploitable. But, most of them require very specific configurations
with specific preconditions to be an issue.
For example (to pick one at random) for CVE-2026-9080: UAF after pause in
socket callback (LOW), the application would need to call curl_easy_pause()
within the event-based CURLMOPT_SOCKETFUNCTION to be at risk. If the
application doesn't call curl_easy_pause() then this CVE isn't exploitable
there. But even if the application DOES call curl_easy_pause() in the callback,
that doesn't mean it's automatically at risk. A remote attacker would need to
have some control over (or know deterministically) what that memory will be
used for next and potentially what gets overwritten in the buffer, too, in
order to have a hope of getting remote code execution, and even then it might
not be possible. It would also need to be able to control (or know exactly
when) when curl_easy_pause() is called. It might "merely" result in a simple
crash, which is a DoS and also not good, but since we can't completely rule out
the possibility of something worse, it gets a CVE. But it's rated low because
the chance that everything could align to make it dangerous is also low.
> i do find it amazing and sorta scarry that the ai (i assume it was ai bots that scrutinized your release in 4 minutes) can locate such esoteric (to me anyway) 'bugs'
Some of the things they're finding these days are very impressive. As they get
better with time, the issues they're finding are more and more crafty.
Dan
-- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-users Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2026-06-27