curl 8.23.0 is out: check the actual installation and SMB dependencies

curl 8.23.0 was released on 14 October 2026. An updated curl in a terminal does not establish that a business application’s libcurl was updated too. Small IT teams maintaining scripts, containers and vendor applications need to identify the copy actually used, its supplier and functional acceptance criteria. There is also a specific compatibility question: does a job still require SMB?

What is confirmed on 14 October

The release table lists 8.23.0 dated 14 October 2026, and the download page offers its source archives. [1][2] This supersedes the earlier planned-release wording; the previous 8.23.0-rc3 is not the regular release. Available source does not establish availability in your package channel or an updated embedded library. A version number alone also cannot establish the patch status of a distribution package with backports. The changelog records removal of SMB support. [3] Jobs using smb:// or smbs:// therefore need targeted inventory and functional checks before migration. This concerns curl, not automatically the operating system’s SMB capability.

Prerequisites and limits

You need read access to the software inventory and scheduled jobs, an application owner and a separate test environment with non-confidential data. Inventory work requires no administrator-level installation or replacement of system files. Later updates must follow the supported distribution channel. A bundled libcurl is not necessarily the library used by the command-line tool. [4] Do not copy unrelated binaries or DLLs into application directories.

Five steps for a reliable migration

  1. Inventory usage, not just version numbers. Record the application, execution context, executable path, package supplier, owner and business purpose for each important job. Include services, scheduled tasks, CI runners and containers separately. A path found in your personal terminal is not evidence of what a service launches. For vendor software, request a component inventory or supplier confirmation; a filename alone is insufficient.
  2. Identify the executable actually used. On Windows, the read-only PowerShell query Get-Command curl.exe -All helps locate executable matches; on Linux/macOS, command -v curl shows the current shell’s resolution. Run the approved, trusted binary using its full path with --version. curl --version reports library, protocol and feature information. [5] Record the TLS backend and architecture too. This does not inventory other processes or separately embedded libraries. The result of command -v may also be a shell function or alias. Before checking the version, verify that the recorded path identifies the approved executable file.
  3. Assign an update route to each installation. OS packages, container base images, standalone tools and vendor applications each need an owner. Distributors may backport fixes, so an upstream version number alone is not conclusive patch evidence. On release day compare the vendor advisory, package revision and actual availability. Do not substitute another libcurl inside an unchanged vendor build. Record missing approvals with an owner and review date. [7]
  4. Prepare a small business-level test matrix. Select an authorised download, a required proxy/authentication case and a controlled error response in the test environment. Define the expected HTTP status, result content and exit code beforehand: process success alone does not prove that business data is correct. Test only required protocols, not arbitrary production endpoints. Keep secrets out of command lines and shared diagnostic logs. Compare before and after results using the same configuration. New for 8.23.0: inspect authorized scripts and configurations for smb:// and smbs:// without copying credentials. A match is a candidate dependency, not proof of active use. Record the job, the actual curl copy and its owner. If SMB disappears from the protocol list after migration, that is a documented change in this release, not a TLS error. Agree on a supported SMB client or functionally suitable alternative transfer route with the application owner; do not blindly switch protocols. Acceptance means the same authorized test case returns the expected data and error handling through the replacement route. [3]
  5. Schedule the change only after approval. Prepare a supported stable package, a configuration backup, a maintenance window and a verified rollback route. A prerelease is suitable only for optional isolated compatibility testing. Change one representative job first, then check its path, library version and output in the actual service or container context. Expand only after acceptance. An old container or long-running process may still use the previous build; plan any required restart deliberately.

Diagnose failures without disabling TLS checks

If certificate verification fails after changing packages, compare the clock, hostname, certificate chain, TLS backend and trust store first. Different builds may use different CA stores. Do not silence the check with --insecure or -k; curl verifies certificates by default. [6] Obtain internal CA certificates only through an authorised company channel. Stop on unexpected authentication or redirection, retain a sanitised error record and involve the responsible operator.

Acceptance and rollback

The change is complete only when the production job demonstrably uses the approved installation, passes the matrix and has working monitoring and error handling. Record package revision, execution time and acceptance per entry. If a regression occurs, use the documented package/application rollback rather than swapping individual libraries. Returning to a vulnerable build is not a lasting solution: pause the affected workflow if necessary and agree a time-limited measure with the security owner. Workflows that modify data also require a consistent data recovery plan. Log template, not a performed test: “job; service account/container; full executable path; package revision/supplier; protocol dependency; expected content/exit code; result; approval; rollback”. Without suitable options, an HTTP error response does not automatically produce a curl error code; check status, content and exit code separately. [5]

Date and sources

As of 16 October 2026. Source-based editorial guidance, not our own curl compatibility or security test. No measured search-trend claims or affiliate links. Verify the upstream release and local package availability separately; supported delivery channels and approval remain prerequisites.