curl 8.23.0-rc1 Opens a Short Proxy Regression Window Before an Accelerated Release

The curl project announced on September 17 that it was shortening the current release cycle by two weeks for security reasons. The project closed its feature window immediately, published curl 8.23.0-rc1 on September 18, and scheduled the final release for October 14, 2026. The official release-candidate guidance says candidates are for testing and verification, not production use.

For teams that depend on curl or libcurl behind HTTP, HTTPS CONNECT, SOCKS4, SOCKS5, residential or dual-stack proxy routes, the operational message is simple: the time to expose a regression is before the final package reaches a base image or dependency update. That does not justify moving a candidate into production. It justifies a narrow, controlled comparison against the exact stable build currently in use.

What changed in the release timeline

The usual curl cycle includes a feature freeze and three release candidates before the final release. This cycle was compressed so pending vulnerability fixes can ship sooner. The first candidate marks the start of the stabilization window; the project can still change or fix behavior before the final release.

Treat the dates as planning inputs:

• September 17: feature window closed early and the shorter cycle was announced;
• September 18: curl 8.23.0-rc1 became available for testing;
• October 14: current target date for the final 8.23.0 release.

Do not infer that every build problem is security-related, and do not infer that the candidate is safer than the latest stable version. The purpose of an RC is to find regressions while there is still time to report and correct them.

Build a two-lane test plan

Keep a stable lane and a candidate lane. Both must use the same controlled destinations, proxy accounts, route selections, request corpus, concurrency and observation windows. Record the binary or library digest, TLS backend, resolver backend, enabled protocols, operating system, architecture and package source for each lane.

The comparison is invalid when the stable job uses one network path and the candidate job uses another. Pin the same authorized gateway, market, session policy and destination fixture wherever possible. If the proxy product rotates exits by design, repeat enough bounded samples to separate route variance from client variance.

Minimum proxy regression matrix

Run at least these cases before calling the candidate compatible:

The proxy response integrity test provides a reusable pattern for asserting status, headers, body markers and route identity. Use the proxy connection pool age test when the application keeps libcurl handles or long-lived pools.

Capture evidence that can explain a failure

For each case, record a synthetic test ID, client version, build digest, proxy protocol, route class, requested market, address family, DNS mode, TLS backend, start time, total duration, status or error class, retry count, connection reuse decision, expected marker result and final verdict.

Do not store proxy passwords, authorization headers, cookies, raw customer URLs or response bodies in the report. A failure bundle should be reproducible without exposing secrets. When verbose curl output is necessary, sanitize it before retention and restrict access.

Compare outcomes before comparing speed. A faster request that used the wrong route, bypassed the proxy, accepted an unexpected certificate or returned a partial body is a failed test.

Test the behaviors proxy fleets commonly miss

Proxy authentication boundaries

Validate both correct and incorrect credentials. Check that the destination receives nothing when proxy authentication fails. If credentials differ by market, account or workload, verify that a connection created under one identity cannot be reused for another identity unless the provider and application explicitly support that design.

DNS location

For SOCKS and other configurable modes, prove whether name resolution occurs locally or remotely. Use a synthetic hostname in a controlled zone and compare resolver logs with client evidence. A release candidate must not silently change the privacy or routing assumption.

Dual-stack selection

Run IPv4-only, IPv6-only and dual-stack cases separately. Record the selected family and observed endpoint. A dual-stack success alone can hide a broken IPv6 path because the client may have completed over IPv4.

Tunnels and reused connections

Exercise fresh CONNECT tunnels, reused tunnels, idle connections and maximum-age boundaries. Verify that headers from the proxy layer never contaminate destination metadata and that a failed tunnel is not returned to the pool.

Retry and cancellation

Inject a bounded timeout, connection reset and explicit cancellation. The retry controller must distinguish them. A candidate that changes an error code can accidentally turn a single failure into a retry storm, a new exit selection or duplicate collection.

Define promotion and stop conditions first

Write the decision rules before the run. A practical candidate canary might require:

• zero direct-route fallback;
• zero credential, cookie or diagnostic leakage;
• identical success for every required proxy protocol and market;
• correct negative-test outcomes;
• no unexplained increase in retries, connection churn or transferred bytes;
• response-integrity checks equal to the stable lane;
• latency and error-rate differences within a predeclared tolerance;
• a reproducible rollback to the stable artifact.

Stop the candidate test immediately if it reaches an unauthorized destination, bypasses a required proxy, sends credentials to the wrong layer, corrupts response framing, or creates unbounded traffic. Do not average away a security or policy failure.

Keep the candidate out of production

Use an isolated runner, disposable credentials, synthetic destinations and conservative concurrency. Do not replace the production base image tag, shared library or system package with the RC. Do not publish the candidate into a general internal repository where another team can consume it accidentally.

When the final 8.23.0 release ships, repeat the acceptance matrix against the signed final artifact. An RC pass is useful evidence, but it is not a substitute for final-build validation.

Pre-release checklist

• Stable and candidate artifacts are identified by digest.
• Package source, TLS backend and resolver backend are recorded.
• Candidate testing is isolated from production traffic and secrets.
• HTTP proxy, CONNECT and required SOCKS modes are covered.
• IPv4-only, IPv6-only and dual-stack cases are separate.
• Positive and negative authentication cases are included.
• DNS location is verified, not assumed.
• Connection reuse, idle age and cancellation are exercised.
• Retry count and transferred bytes are compared.
• Direct fallback is explicitly prohibited and tested.
• Logs are sanitized before retention.
• Final-release retest and rollback owners are assigned.

FAQ

Is curl 8.23.0-rc1 a production upgrade?

No. The curl project explicitly describes release candidates as work in progress for testing and verification. Keep the current supported stable build in production until the final release passes your controls.

Does the shorter cycle prove a vulnerability affects my proxy client?

No. It means the project chose to ship pending vulnerability fixes sooner. Determine exposure from the final advisories, the exact curl or libcurl build and the features your application uses.

Should every proxy route be tested?

Test every materially different class: protocol, authentication method, DNS mode, address family, market, session policy and TLS backend. Sampling several identical endpoints is less valuable than covering distinct behavior.

Can a successful request prove the proxy was used?

No. Assert route identity, disable direct fallback, verify the controlled response marker and inspect authorized proxy-side evidence where available.

What if the RC fails but the stable build passes?

Preserve a minimal sanitized reproduction, confirm that the lanes differ only by the candidate artifact, and report the issue through the curl project's documented channel. Keep the stable production artifact and retest the next candidate or final release.

Compliance note

Test only proxy accounts, credentials, destinations and markets you are authorized to use. Use synthetic data, bounded request rates and isolated runners. Respect destination terms, robots policies, privacy requirements and rate limits. Proxy rotation must not be used to evade access controls, publisher decisions or regional restrictions.

Source note: curl project, “A shortened release cycle,” September 17, 2026; curl project, “curl release candidates,” updated September 18, 2026. External research locations are retained only in the internal operations record.