curl Takes LOW and MEDIUM Vulnerabilities Public From 26 October

From 26 October 2026 the curl project handles vulnerability reports it rates LOW or MEDIUM as public GitHub issues in curl/curl, while HIGH and CRITICAL stay private on HackerOne. Anyone shipping curl or libcurl should watch that public tracker, not only CVE feeds, and shorten the path from a fix commit to a rebuilt image.

This is not a breach and nothing was compromised. It is a change to how one of the most widely embedded libraries in the world tells its users about flaws. curl lead developer Daniel Stenberg announced it on his blog on 20 October, and the reason he gives is volume: a flood of vulnerability reports that has left the maintainers, in his words, "brought to the brink of what we can muster."

For defenders the practical effect is simple to state and harder to act on. Until now, almost every curl vulnerability reached the world at the same moment as its fix, its advisory and its CVE, all on release day. From 26 October, a LOW or MEDIUM issue can be visible in public before there is a release, before there is an advisory, and in some cases without a CVE ever being assigned. Tooling that only listens for CVE records will see these issues late or not at all.

This post explains exactly what curl changed, what curl's four severity levels mean, what the last three curl releases fixed (with versions, CWE identifiers and fix commits from curl's own advisories), how to find every copy of libcurl you ship, and how to track public curl issues in a way that fits a real patch process.

What happened

On 20 October 2026 at 08:09 CEST, Stenberg published "Do minor curl vulnerabilities in the open" on daniel.haxx.se. The post sets out four rules that take effect on 26 October:

1. Vulnerability reports that curl deems LOW or MEDIUM severity should be filed as issues in the curl GitHub repository.
2. Only reports deemed HIGH or CRITICAL stay private in curl's HackerOne tracker.
3. A researcher who is unsure can still file on HackerOne and the curl team will say what severity it assigns.
4. Reports filed on HackerOne and rated LOW or MEDIUM will be closed there as informative, publicly disclosed, and the reporter asked to resubmit on GitHub.

Stenberg backs the change with one number: over the last few years, more than 90 percent of all submissions could quickly be judged to be below HIGH. curl's own vulnerability data supports the direction of that claim. Of the 69 curl CVEs published so far in 2026, according to the publication dates in curl's vuln.json feed, 53 were rated Low, 15 Medium, one High and none Critical.

The post is frank about why. Stenberg writes that the flood of reports alone triggered the change, that the team sees no end to it in the coming months, and that the step is part of a survival strategy that may not be the last one. He describes AI-assisted researchers generating unusual sequences of libcurl options and protocol combinations that produce something unexpected but are unlikely to occur in real applications, and treating each discrepancy as a vulnerability.

The Register covered the announcement the same day and quoted the same reasoning. iThome in Taiwan summarised it for its readers on 21 October, noting that outside developers will now be able to take part in confirming LOW and MEDIUM issues, checking patches and drafting advisories.

Not a breach, and not the end of private disclosure

Nothing in this change affects HIGH or CRITICAL issues. Those still go through curl's private process: a small security team, a private fix branch, a pre-notification to the distros mailing list no more than seven days before release, and coordinated publication with the release. The serious flaws, the ones that can be turned into code execution or easy data exposure, keep the embargo.

What changes is the bottom of the scale, which is also where most of the volume sits.

How we got here: a year of pressure on curl's security process

The October policy is the latest in a series of steps. The Register reported in January 2026 that Stenberg had committed a change titled "BUG-BOUNTY.md: we stop the bug-bounty end of Jan 2026", ending curl's paid bug bounty after a long run of low quality, often AI-generated submissions. The Register noted that Stenberg had been complaining publicly about AI-generated reports since early 2024 and had also acknowledged that some AI-assisted reports were good.

Then curl took July 2026 off from vulnerability intake altogether. In a 3 August post titled "What the bliss taught us", Stenberg wrote that the maintainers took all of July off from handling vulnerability reports, that the HackerOne page told visitors to come back in August, and that it was "possibly our best project decision in a long while." He also recorded that curl, as a CVE Numbering Authority, had been reminded that CNA rules require a response within 72 hours for some critical vulnerabilities, and that no emergency assignment turned out to be needed.

Intake reopened on Monday 3 August. In his weekly mailing list note on 8 August, Stenberg wrote that the first report arrived 30 minutes after reopening, that seven reports came in that week, and that one was a confirmed new vulnerability with low severity.

Since then curl has shipped two releases with large security batches: 8.22.0 on 2 September and 8.23.0 on 14 October. The October release alone carried 24 CVEs. Six days later came the announcement.

Timeline

Who is affected

Almost everyone, a little. libcurl sits inside operating systems, language runtimes, package managers, container base images, embedded firmware, desktop applications and countless internal tools. curl's own advisories carry a standing reminder that many applications use libcurl without saying so.

The effect is different depending on where you sit.

How it works: curl's process before and after 26 October

The process until now

curl's published vulnerability disclosure policy, which on 24 October still read the same on curl.se and in VULN-DISCLOSURE-POLICY.md in the curl repository, lays out a private, release-synchronised flow:

1. The reporter files on HackerOne, where reports reach a small group of selected, trusted people.
2. A member of the security team acknowledges the report and the team accepts or rejects it, explaining rejections to the reporter.
3. For accepted issues, the team works out a fix, assesses impact and proposes a release schedule.
4. The team writes an advisory, identifies the CWE, and requests a CVE ID. curl is its own CNA, so it assigns its own numbers.
5. The fix is committed on a private branch. The policy already allowed one exception: if severity is Low or Medium, the fix may be merged to master through a normal pull request, as long as it does not mention that it is a security fix.
6. No more than seven days before release, curl informs the distros list at Openwall with the advisory draft, CVE and patch. That list does not accept embargoes longer than seven days.
7. No more than 48 hours before release, the private branch is merged and pushed.
8. curl releases, announces on its mailing lists and publishes the advisory on curl.se.
9. The HackerOne report is disclosed. The policy says every report, valid or not, should be made public.

The policy also says plainly that curl never offers rewards for reported vulnerabilities, that it cannot handle reports sent by email, and that reports should be written in the reporter's own words rather than pasted AI output.

What changes

From 26 October, steps 1 to 5 move into public view for LOW and MEDIUM issues. The report, the discussion, the review of the fix and the drafting of the advisory can all happen in a GitHub issue that anyone can read. HIGH and CRITICAL keep the private path above.

Stenberg lists the benefits the project hopes for:

• Spreading the work of assessment, fixing and advisory writing across more people.
• Public review of fixes before release. He notes that whenever curl announces new CVEs, AI-assisted researchers quickly test the fixes for similar mistakes; doing that review before the release is better than after.
• Earlier visibility for distributions and other curl users.
• Lessons and documentation that are easier to find later.

He also lists the risks:

• A researcher might file a HIGH issue publicly thinking it is LOW or MEDIUM. Stenberg calls this a low risk, since researchers rarely understate their findings, and notes that someone could always have filed publicly by mistake.
• Public handling gives attackers a somewhat longer window to exploit a flaw before users update. He calls this unfortunate and unavoidable, and says it is the reason the change stops below HIGH.

Why LOW issues still get CVEs

Stenberg says the team discussed simply dismissing LOW issues, but the CVE program has an appeals process, and if curl declines to assign a CVE to a real vulnerability, someone else can. So true vulnerabilities cannot be ignored. What he does say is that he intends to decline more reports that do not actually harm users or existing applications, particularly the AI-found option combinations that either never occur in practice or fail every time they are used and so would be caught immediately.

That has a direct consequence for anyone who uses CVE counts as a measure of risk. Some issues that would have become curl CVEs in 2026 may in future be fixed as ordinary bugs in public, with no CVE at all.

Technical details

This section collects the concrete, defender-useful facts from curl's own published material: the severity scale, the scope rules, and the actual versions, CVEs, CWE identifiers and fix commits from the most recent advisories. Every value here was read from curl.se, curl's vuln.json feed or the curl repository on 24 October 2026.

curl's four severity levels

curl rates every vulnerability as Low, Medium, High or Critical. Its policy says the project does not use numerical scoring and does not support CVSS, calling it "a broken system", and so does not set CVSS scores on the CVE records it publishes. Other organisations do publish CVSS scores for curl CVEs, and curl's policy tells users to decide for themselves whether those scorers understand the issue.

curl says it weighs attack vector, attack complexity, required privileges, build configuration, protocols, platform specifics and the confidentiality, integrity and availability effects. In other words the same inputs CVSS uses, combined by judgement rather than formula.

What curl does not treat as a vulnerability

The disclosure policy has a long "not security issues" section. It matters more after 26 October, because these categories are where many public reports will land and be closed. The list includes small memory leaks, never-ending transfers, flaws not practically executable on existing hardware, API misuse outside documented behaviour, attacks needing a local attacker who already has elevated rights, debug or experimental features off by default, test code, URL parser differences from browsers, incomplete blanking of command line arguments, busy-loops that eventually end, overwriting files in a directory an attacker can write to, tricking a user into running a command line, terminal escape sequences in downloaded content, NULL dereferences and crashes triggered by a malicious server, legacy dependencies over ten years old and unsupported, weak algorithms used only when explicitly requested, and CRLF sequences that a user passes in.

Two scope rules affect version planning directly:

• Non-released code. Only curl releases are considered secure. Code on master between releases may contain flaws that are not treated as vulnerabilities.
• Old releases. Low or Medium reports that only affect releases older than three years are out of scope and closed without action.

The second rule is worth reading twice if you run old curl. If your product embeds a libcurl from 2022 or earlier and someone finds a Low or Medium issue that only affects that old code, curl will not issue an advisory for it.

The last three releases in numbers

curl's release table and vuln.json give the following.

All-time, curl's vuln.json lists 239 CVEs: 102 Low, 94 Medium, 41 High and 2 Critical. By publication year it lists 13 in 2021, 21 in 2022, 18 in 2023, 11 in 2024, 9 in 2025 and 69 so far in 2026. That jump is the workload Stenberg describes, and it is also why the shift to public handling matters: the bulk of 2026's volume is exactly the Low and Medium band that moves to GitHub.

The 8.23.0 batch (published 14 October 2026)

The single High in the batch is CVE-2026-92392, an HTTP/2 upload use-after-free. According to curl's advisory:

• Flaw: during an upload, curl mishandles an HTTP/2 RST_STREAM from the server with reason HTTP_1_1_REQUIRED or REFUSED_STREAM, leading to a use-after-free of a struct Curl_easy object.
• Weakness: CWE-416, Use After Free. Severity: High.
• Impact note: curl says the flaw has been shown to be convertible into remote code execution when a long list of specific conditions about the build, allocator, TLS behaviour and timing are met by a malicious server.
• Affected: curl 8.12.0 up to and including 8.22.0, both the library and the command line tool.
• Not affected: below 8.12.0; 8.23.0 and later; 8.20.2 and later on the 8.20.x branch; 8.16.2 and later on the 8.16.x branch; 8.14.3 and later on the 8.14.x branch.
• Fix commit: 8b0744af5b1b631da5b938ca31c (prefix as shown in the advisory).
• Recommendations: upgrade to 8.23.0, apply the patch to your local version, or do not use HTTP/2.
• Timeline: reported 15 September 2026; fixed and published with 8.23.0 on 14 October 2026.

The other 23 CVEs published on 14 October were all rated Low. Here is the full list from vuln.json, with the version where each was introduced and the leading characters of the fix commit in curl/curl.

For the 21 records whose last affected version is 8.22.0, vuln.json lists the same fixed versions as the High: 8.23.0 on the main line, plus 8.20.2, 8.16.2 and 8.14.3 on their branches where the flaw reaches back that far. The last three rows were last affected in 8.21.0 and are marked fixed in 8.22.0 (and 8.20.2, 8.16.2, 8.14.3 on branches).

Every one of these 23 Low issues went through the full private process, the CVE assignment and the coordinated release. Under the new policy, issues of this kind would be reported, discussed and probably fixed in public, and some of them might be fixed without a CVE.

Look at the shape of the list. Many entries are about connection reuse, credentials sent to the wrong origin, cookies and HSTS state. These resemble the option combination bugs Stenberg describes: real, but tied to specific features (Negotiate authentication, FTP wildcards, TFTP, wolfSSL pinning, IMAP APPEND with CRLF conversion) that a given application may not use at all. Triage by feature use is the most useful habit you can build for the post-26 October world.

The 8.22.0 batch (published 2 September 2026)

The nine CVEs published with 8.22.0 were 8 Low and 1 Medium. The Medium was CVE-2026-19931, "Negotiate ambient user conn reuse", introduced in 7.64.1. The Lows included CVE-2026-80230 (OpenSSL pinning bypass), CVE-2026-80229 (OpenSSL provider use-after-free, introduced in 8.14.0), CVE-2026-18924 (HTTP/2 server push use-after-free) and CVE-2026-13608 (OpenLDAP SASL authentication bypass). Fixed versions in vuln.json for that batch are 8.22.0 on the main line and 8.20.1, 8.16.1 and 8.14.2 on branches.

Where curl publishes machine-readable data

Each OSV record in vuln.json carries a database_specific block with severity, CWE, last_affected, affects (lib, tool or both), and an issue link to the original report. That last field is worth noting: for issues handled on GitHub after 26 October, it will presumably point to a GitHub issue rather than a HackerOne report, though curl has not said so.

No indicators of compromise

There are no hashes, domains or IP addresses to block. This is a disclosure process change. The technical artefacts that matter are versions, fix commits and the places those are published.

What to do now

The goal is a process that notices a public curl issue when it matters to you, without drowning your own team in the same flood curl is trying to escape.

1. Find every copy of libcurl you ship

You cannot act on a curl issue if you do not know where curl is. Start with the obvious places and work outwards.

On a Linux host or inside a container:

# The command line tool, and the libcurl it is linked against
curl -V

# The development package view of libcurl
curl-config --version
pkg-config --modversion libcurl

# Debian and Ubuntu
dpkg -l | grep -E 'libcurl|^ii  curl'

# RHEL, Fedora, Amazon Linux
rpm -qa | grep -i curl

# Alpine
apk info -v | grep -i curl

Inside language runtimes that wrap libcurl:

# PHP
php -r 'print_r(curl_version());'

# Python with pycurl
python3 -c 'import pycurl; print(pycurl.version)'

# Which binaries on this host load a shared libcurl
for f in /usr/bin/* /usr/local/bin/*; do
  ldd "$f" 2>/dev/null | grep -q libcurl && echo "$f"
done

Statically linked and vendored copies do not show up in package managers. libcurl normally embeds its version in a string of the form libcurl/8.x.y, so a string search finds most of them:

# Search a binary or a directory of binaries for an embedded libcurl version string
strings -a ./your-binary | grep -oE 'libcurl/[0-9]+\.[0-9]+\.[0-9]+' | sort -u

find /opt /usr/local -type f -perm -u+x 2>/dev/null | while read -r f; do
  v=$(strings -a "$f" 2>/dev/null | grep -oE 'libcurl/[0-9]+\.[0-9]+\.[0-9]+' | head -1)
  [ -n "$v" ] && echo "$v  $f"
done

For container images, scan the image rather than the Dockerfile, because the base layer decides which curl you get:

docker run --rm --entrypoint sh your-image:tag -c 'curl -V 2>/dev/null || echo no curl binary'

Our earlier post on the 8.23.0 release goes further into embedded copies, including git, language wheels and firmware: curl 8.23.0: 24 CVEs and finding embedded libcurl.

2. Record which curl features each product actually uses

Because most curl issues are tied to specific protocols, TLS backends and options, the most useful single fact about a product is not "it has libcurl 8.21.0" but "it has libcurl 8.21.0, built with OpenSSL, used only for HTTPS GET requests with no cookies, no proxy and no Negotiate authentication."

Two commands give most of the build picture:

curl -V
# The "Protocols:" and "Features:" lines show what was compiled in,
# for example HTTP2, HTTP3, HSTS, GSS-API, Kerberos, NTLM, alt-svc.

curl-config --features
curl-config --protocols

The application side needs a short code search. For a C or C++ codebase:

grep -rhoE 'CURLOPT_[A-Z0-9_]+' src/ | sort | uniq -c | sort -rn

Keep the result next to your SBOM. When a public issue mentions CURLOPT_INTERFACE, CURLAUTH_NEGOTIATE, FTP wildcards or the wolfSSL backend, you will know within a minute whether it matters to you.

3. Add a source that is not keyed on CVEs

Here are four practical feeds, from least to most effort.

curl's own OSV feed. Poll vuln.json and alert on new records. This covers everything that does get a curl CVE, on release day:

curl -s https://curl.se/docs/vuln.json \
  | jq -r '.[0:10][] | [.aliases[0], .database_specific.severity, .database_specific.last_affected, .summary] | @tsv'

Releases. curl's website advertises a releases feed from GitHub. Subscribe to https://github.com/curl/curl/releases.atom so a new release is a ticket, not a surprise.

Public issues. From 26 October, LOW and MEDIUM vulnerability discussion will happen in curl/curl issues. With the GitHub CLI:

# Issues opened since the policy change
gh issue list -R curl/curl --state all \
  --search "created:>=2026-10-26 sort:created-desc" --limit 50

# Narrow to likely security discussion
gh issue list -R curl/curl --state all \
  --search "created:>=2026-10-26 vulnerability OR CVE OR security in:title,body" --limit 50

# The same through the API, for a scheduled job
gh api -X GET search/issues \
  -f q='repo:curl/curl is:issue created:>=2026-10-26 vulnerability' \
  --jq '.items[] | [.number, .state, .title, .html_url] | @tsv'

When we checked curl's repository labels on 24 October, there was no label named "security" or "vulnerability". The existing labels include memory-safety, TLS, HTTP/2, authentication, cookies and others. curl may add a dedicated label once the policy is live; until then, a text search plus a weekly human skim is more reliable than a label filter.

Commits. Fixes for LOW and MEDIUM issues could already land on master through normal pull requests under the old policy. Now they will also be linked from public discussion. https://github.com/curl/curl/commits/master.atom gives you a feed if you want to watch closely.

Your distribution's tracker. If you rely on distribution packages, the distribution's own security tracker for its curl source package tells you when a fixed build is available to you, which is the date that actually matters for your images.

4. Write down your triage rule before the first issue arrives

Without a rule, a public tracker turns into either noise you ignore or panic you cannot sustain. A rule like this one works for most teams:

1. Is the reported code in a curl release you ship? If it only exists on master, curl does not treat it as a vulnerability.
2. Does the issue depend on a protocol, option, TLS backend or feature your product uses? If not, log it and move on.
3. What severity has curl assigned, or proposed, in the issue? LOW and MEDIUM by curl's definitions usually need something else to go wrong.
4. Is a fix commit available? If so, could you build from it, or will you wait for the next release?
5. Does your product face untrusted servers? Many curl flaws need a malicious server, so an internal tool talking only to your own endpoints usually carries less risk than a client that follows redirects across the internet.

Write the outcome against the product in your inventory. If the answer to questions 2 and 5 is yes and the issue is MEDIUM, treat it like a security fix even before a CVE exists.

5. Keep the release path short

curl has shipped roughly every six to ten weeks this year. In 2026 that meant 11 March, 29 April, 24 June, 2 September and 14 October. If your process can move from a new curl release to rebuilt, tested and deployed images within a week, the longer public window Stenberg describes is mostly absorbed. If it takes a quarter, the public window is the least of your problems.

Concretely:

# Debian or Ubuntu based image: pick up the patched distribution package at build time
RUN apt-get update && apt-get install -y --only-upgrade curl libcurl4 && rm -rf /var/lib/apt/lists/*

# Alpine based image
RUN apk upgrade --no-cache curl libcurl

# Rebuild without cache so the base layer is refreshed
docker build --pull --no-cache -t your-image:tag .

For vendored source, pin the curl version in one place and make the bump a one-line pull request with a test run.

6. Know how to carry a single fix commit

For a MEDIUM issue that matters to you, with a fix on master and no release yet, you may want to carry the patch. curl's advisories already list "apply the patch to your local version" as a supported option. A minimal, auditable way:

git clone https://github.com/curl/curl.git && cd curl
git checkout curl-8_23_0                 # the release tag you ship
git cherry-pick <fix-commit-sha>         # the commit linked from the issue
autoreconf -fi && ./configure --with-openssl && make && make test

Keep the carried patch list short and drop each patch as soon as a release contains it.

What changed since the first reports

The announcement and the first press coverage on 20 October all describe the same plan. As of 24 October:

• The new policy text is in Stenberg's blog post. curl's formal disclosure policy on curl.se and in docs/VULN-DISCLOSURE-POLICY.md in the repository still says vulnerabilities should not be entered in the public bug tracker. We expect those documents to change on or around 26 October.
• No new label, issue template or separate public tracker for vulnerabilities had appeared in curl/curl.
• The HackerOne program remains the channel for HIGH and CRITICAL reports and for researchers who want a severity ruling.

Open questions

These are things curl has not yet said, or that will only become clear once the policy runs for a while:

• How LOW and MEDIUM issues will be labelled on GitHub. Without a label, tracking depends on text search.
• Whether every public LOW or MEDIUM vulnerability still gets a CVE. Stenberg says true vulnerabilities cannot be ignored because of the CVE appeals process, and that he will decline more non-issues. Where the line falls will show in practice.
• What the issue field in vuln.json will point to for publicly handled issues.
• How the distros pre-notification changes. The seven-day distros notice was designed for private fixes; for public issues it may matter less.
• How the branch releases are aligned. curl's 8.23.0 advisories list fixed versions on the 8.20.x, 8.16.x and 8.14.x branches. If you rely on one of those branches, confirm with whoever supplies your build how quickly public LOW and MEDIUM fixes reach it.
• Whether other projects follow. Stenberg noted in August that several other open source projects took time off after curl's summer pause. A public-by-default approach for low severity issues may spread.

The bigger pattern: maintainers and the report flood

curl is the clearest public case of an open source project changing its process because of report volume, but it is not the only one. The same month brought the PHP2Shell disclosure debate and a wider conversation about AI-found vulnerabilities; we covered that in AI-found vulnerabilities after PHP2Shell and PwnEscape.

What is different about curl's response is that it does not try to slow down disclosure. It speeds it up. LOW and MEDIUM issues will be visible earlier, to defenders and attackers alike. That is a reasonable trade for a project with a small security team and a long history of careful releases, and it puts more responsibility on downstream teams to have their own intake.

The good news is that this is the same intake any team needs for every other dependency: know where the component is, know which features you use, watch the right feed, and have a fast rebuild. curl just made the case for it explicit.

What would have helped

There is no incident to prevent here. The useful question is what makes a team comfortable with a world where minor flaws in core libraries are discussed in public before a release.

Practices any team can use

• A component inventory that includes vendored and static copies. Package lists are not enough for libcurl. Use string searches and image scans as above, and keep SBOMs for each build.
• Feature-level notes per product. Record TLS backend, protocols and key options. Most curl advisories are conditional on these.
• A non-CVE intake. Upstream issue trackers, release feeds and distribution trackers, filtered by the components you actually ship.
• A written triage rule. The five questions above, applied the same way each time, so the public tracker becomes signal.
• A fast, boring rebuild. Base images pulled fresh, curl pinned in one place, tests that exercise the network paths that matter. Time from release to deploy measured in days.
• A patch carrying policy. When you will carry an upstream commit, who reviews it, and when you drop it.
• Respect for upstream's process. Read curl's "not security issues" list before filing, write in your own voice, and do not push a LOW issue into the private queue to gain attention. A healthier upstream is a direct benefit to everyone downstream.

Zero-Day Discovery and Gold

Two Safeguard capabilities are relevant to the habit this post argues for, and we want to be precise about what they are and are not.

Zero-Day Discovery looks for previously unknown flaws before a CVE exists, in an agentic mode and a deterministic scanner mode. Findings are issued as SGZ advisories before they reach public CVE databases, and it covers seven package ecosystems.

Gold Open Source at gold.safeguard.sh is free and needs no login. It offers searchable CVE intelligence with CVSS, EPSS, CISA KEV status, affected and fixed versions and a recommended safe version, plus a free read API and a CI gate GitHub Action. Gold Registry at registry.safeguard.sh, a paid service, provides hardened drop-in components and container images held to zero exploitable critical or high CVEs, with SLSA L3 or higher provenance, Sigstore signatures and evidence pages; an artifact loses its badge if it regresses.

We have not confirmed that Gold holds records or hardened builds for the specific curl CVEs above, so we do not claim it. The habit these capabilities support is the right one for curl's new process: look up the safe version quickly, pull patched and signed components from a curated source, and rebuild fast.

Where Safeguard fits

Safeguard is a software supply chain security platform. For this change, the honest fit is inventory, matching and rebuilding:

• Finding libcurl. safeguard scan --dir . scans a repository, safeguard scan --image <name> scans a container image and safeguard scan --sbom <file> scans an SBOM, with results written as JSON under ./output. The platform shows which projects contain a given component and version, which is the question you need to answer when a curl issue becomes public.
• Matching against vulnerability databases. Once a curl issue becomes a CVE, Safeguard matches it against your components. Reachability analysis helps rank which findings sit on code paths your application calls.
• Policies and gates. Policies evaluated in the platform can block builds that carry a curl version you have decided not to ship.
• Autonomous remediation. When a fixed version exists, fix pull requests can bump the dependency. It ships off by default.
• The Safeguard CLI assistant. It can edit a Dockerfile or build file and run your build and tests, asking before each command under the permission mode you choose (/permissions: Ask, Accept edits, Plan, Auto, Strict). safeguard exec runs the same work in CI.

Where Safeguard does not help: it does not watch curl's GitHub issues for you, it does not assign curl severities, and a LOW or MEDIUM issue that never receives a CVE will not appear as a vulnerability match. For that window, the feeds in step 3 above are the right tool. Safeguard also does not patch a curl that ships inside a vendor's appliance or a hosted service; that fix comes from the vendor.

When you are ready to try it, download Safeguard and read the CLI documentation.

Common mistakes and troubleshooting

Treating every public curl issue as a vulnerability. Many reports will be closed as not security issues under curl's published list. Wait for curl's severity call or apply your triage rule.

Ignoring LOW because it is LOW. curl's Low means hard to trigger in general. In your product it may be trivially reachable, for example if you use the exact option combination. Check feature use first.

Reading the CVSS score instead of curl's level. curl does not set CVSS scores. Scores you see elsewhere come from other organisations. They may be useful, but curl's level and the advisory text are the primary assessment.

Checking only the curl binary. curl -V shows the tool and the libcurl it links. Language bindings, static builds and vendored copies can carry a different version on the same host.

Assuming the distribution has the fix because upstream released. Distribution packages often backport fixes to an older version number. Check the distribution's advisory or package changelog, not only the version string.

Building production from master. curl says only releases are considered secure. If you must carry a fix early, cherry-pick it onto a release tag.

Running releases older than three years. Low and Medium reports that only affect those versions are now out of scope for curl. Old embedded copies are a growing blind spot.

Filing a HIGH issue in public. If you find what you believe is serious, file it privately on HackerOne. If you are unsure, file it there and ask for curl's severity call.

FAQ

What exactly is curl changing on 26 October 2026?

Vulnerability reports curl rates LOW or MEDIUM will be handled as public GitHub issues in curl/curl. HIGH and CRITICAL reports stay private on HackerOne. LOW or MEDIUM reports filed on HackerOne will be closed as informative, publicly disclosed, and the reporter asked to refile on GitHub.

Why is curl doing this?

Volume. Stenberg says an avalanche of reports, many created with AI help, has left the maintainers overloaded, and that over 90 percent of submissions in recent years were quickly assessed as below HIGH. Moving the lower band into public lets more people help with assessment, fixes and advisories.

Is curl less secure now?

Not in the sense of more bugs. The change affects how LOW and MEDIUM issues are disclosed. Stenberg acknowledges it gives attackers a slightly longer window before users update, and limits the change to below HIGH for that reason.

Will LOW and MEDIUM issues still get CVEs?

Real vulnerabilities still need CVEs, because the CVE appeals process lets others assign one if curl does not. Stenberg says he intends to decline more reports that do not hurt real users or applications, so some reported issues may be fixed as plain bugs without a CVE.

What do curl's severity levels mean compared with CVSS?

curl uses four levels, Low, Medium, High and Critical, assigned by judgement. It does not set CVSS scores on its CVE records and calls CVSS a broken system. Other organisations publish CVSS scores for curl CVEs, and those may differ from curl's level.

What was in the most recent curl release?

curl 8.23.0, released on 14 October 2026, was published with 24 CVEs: one High (CVE-2026-92392, an HTTP/2 upload use-after-free affecting 8.12.0 through 8.22.0) and 23 Low. Fixed versions are 8.23.0, or 8.20.2, 8.16.2 and 8.14.3 on their respective branches.

How do I find out whether my product uses libcurl?

Check package managers, run curl -V and curl-config --version, check language bindings such as PHP's curl_version() and Python's pycurl, search binaries for the libcurl/ version string, and scan container images. Keep an SBOM per build.

How do I track public curl issues without drowning?

Use a scheduled search on curl/curl issues created after 26 October, filtered by text, and match the results against the features your products use. Combine it with curl's vuln.json feed and the releases feed. Apply a written triage rule so each issue gets a quick yes or no.

Should I build curl from master to get fixes earlier?

No. curl says only releases are considered secure. If you need a specific fix before the next release, cherry-pick the fix commit onto the release tag you already ship, test it, and drop the patch once a release includes it.

Does this affect HackerOne reports already filed?

Stenberg's post describes how reports will be handled from 26 October. It does not say how already-open private reports will be treated. Watch curl's updated policy documents for that detail.

Fix it without waiting for upstream

curl's change means some fixes will be visible as commits and issues before a release exists. Whether you wait for the release or carry the commit, the gaps below are the same.

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would have helped

None of these demos shows curl. Each shows a real flow that maps onto the work this policy change asks of downstream teams.

The first demo is a real Safeguard CLI session. It installs the CLI, opens the interactive terminal, and asks it to fix a lodash CVE: the assistant reads the finding and advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with approval, and pushes nothing. For a public curl issue you would ask the same assistant to bump the curl package in your Dockerfile, or pin a new vendored release, then run your build and tests, approving each step.

Click through it at your own pace, or open it full screen.

The second demo sets up the Safeguard runner on your own machine, approves it with a device code, and then scans from the terminal. That is the step that answers "where do we ship libcurl" across repositories and images you already have checked out, before the next curl issue lands.

Click through it at your own pace, or open it full screen.

The third demo is a real desktop app session. The CLI session appears in the conversation list, you ask for work on your computer, pick the folder, and Approve or Deny each command and file edit; it ends with an upgrade done and tests passing. The same flow fits a curl rebuild: point it at the image repository, let it propose the base image or package bump, and approve the build and test commands one by one.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• Do minor curl vulnerabilities in the open (Daniel Stenberg, 20 Oct 2026)
• What the bliss taught us (Daniel Stenberg, 3 Aug 2026)
• Daniel's week, August 8, 2026 (lists.haxx.se)
• curl vulnerability disclosure policy (curl.se)
• VULN-DISCLOSURE-POLICY.md (curl/curl on GitHub)
• SECURITY.md (curl/curl on GitHub)
• curl CVEs (curl.se)
• curl vulnerability table (curl.se)
• curl vuln.json OSV feed (curl.se)
• CVE-2026-92392: HTTP/2 upload Use-After-Free (curl advisory)
• CVE-2026-94266: password leak in CURLINFO_EFFECTIVE_URL (curl advisory)
• curl security advisory guidelines (curl.se)
• curl release table (curl.se)
• curl changelog (curl.se)
• curl/curl repository labels (GitHub API)
• curl/curl issues (GitHub)
• curl on HackerOne
• Swamped curl maintainers take low-level flaws public (The Register, 20 Oct 2026)
• curl shutters bug bounty program to stop AI slop (The Register, 21 Jan 2026)
• iThome report on curl's disclosure change (Traditional Chinese)

Last reviewed: 24 October 2026. This is a developing story; check the linked advisories for the latest status.