The maintainers of curl, the command-line tool and library that quietly moves data for everything from embedded routers to cloud platforms, have released version 8.23.0. Tucked inside the update are fixes for 24 separate security issues, a notably large batch for a project whose footprint is often estimated at tens of billions of installations across devices, operating systems, and applications that bundle libcurl under the hood.

A Credential-Handling Theme Runs Through the Advisories

Most of the newly disclosed bugs share a common thread: curl, in specific configurations, could be tricked into sending authentication material somewhere it was never meant to go, or into exposing it where a developer wouldn’t expect to look.

The most striking example lets an HTTP proxy intercept credentials intended for the actual destination server. During a CONNECT tunnel negotiation, a malicious or compromised proxy can respond with a 401 status and a WWW-Authenticate header instead of the proxy-specific challenge curl expects. Under the right conditions, curl will hand over a Basic authentication password or a Negotiate/Kerberos ticket meant for the far-end server, giving the proxy operator a free credential capture. The flaw has reportedly affected every curl release going back more than a decade, from version 7.10.8 through 8.22.0.

A second issue in the same family can leak saved passwords via curl’s effective-URL reporting. When curl pulls login details from a .netrc file, those credentials can resurface inside the URL returned through the library’s CURLINFO_EFFECTIVE_URL option, or through the equivalent command-line output. Applications and scripts that log the “URL actually used” for debugging or auditing purposes could end up writing plaintext passwords straight into log files without realizing it.

Other Notable Fixes

Beyond the headline credential bugs, the release addresses a grab-bag of subtler problems that mostly stem from curl carrying over connection state or cached settings after the destination, identity, or configuration has changed:

• A redirect during an SFTP or SCP transfer could bypass the SSH host-key verification that’s supposed to confirm the remote server’s identity.
• A reused FTP connection could inherit a client certificate that was configured for a different, earlier request.
• A server-supplied cookie could trigger the unintended deletion of curl’s entire cookie jar, or interrupt the loading of previously stored cookies.
• Stale HSTS (HTTP Strict Transport Security) cache entries could be dropped or overwritten incorrectly, weakening the protection meant to force HTTPS connections.
• A missing response from a server could send curl into an infinite loop, and recursive cleanup of MIME data structures could exhaust the call stack and crash the host application.

One more actively exploitable-sounding bug, an IMAP command-injection flaw tied to the CURLOPT_CRLF option, turned out to have already been quietly patched in curl 8.22.0; its advisory was simply published alongside this release. The issue arose because curl could advertise one message size to a mail server while actually transmitting more bytes after converting line endings, bytes an IMAP server might interpret as additional authenticated commands. Curl’s maintainers note this is IMAP-protocol injection, not operating-system shell injection, and the documented workaround is simply to avoid pairing CURLOPT_CRLF with IMAP uploads until upgrading.

Where the Bugs Came From

Security firm AISLE says it is responsible for discovering 18 of the 24 vulnerabilities disclosed across curl’s two most recent releases, roughly three-quarters of the total, the product of a dedicated audit of the codebase rather than routine bug-hunting. Six additional issues it found were already resolved in the prior 8.22.0 release. curl maintainer Daniel Stenberg has previously welcomed this kind of structured, well-resourced third-party review as a way to surface classes of bugs that don’t always surface through everyday use.

What Administrators Should Do

Because curl ships both as a standalone command-line tool and as an embedded library inside countless other applications, patching is rarely as simple as updating one package. Teams should:

• Upgrade standalone curl and libcurl installations to 8.23.0, or apply vendor backports where a distribution hasn’t yet shipped the new version.
• Audit third-party applications, containers, and appliances that statically link or vendor their own copy of libcurl, since updating the system package won’t touch those embedded copies.
• Review any code or infrastructure that logs “effective URLs” or similar diagnostic output, in case credentials have already been inadvertently captured in historical logs.
• Check configurations that rely on HTTP proxies for outbound connections, particularly where Basic or Negotiate authentication is in use downstream of the proxy.

The release notes also flag the removal of SMB and SMBS protocol support entirely, a change worth testing for before a broad rollout, since it could silently break workflows that still depend on those transfers.

None of the 24 issues appear to be under active, widespread exploitation at the time of disclosure, but the sheer density of credential-handling bugs in one release is a reminder that even mature, heavily scrutinized open-source infrastructure can still hide quiet logic errors for years before a focused audit catches them.