curl 8.22 Fixes Public-Suffix Cookie Scope: A Proxy Collector Audit

The curl project published CVE-2026-82209 on September 2, 2026, together with curl 8.22.0. The advisory describes a low-severity cookie-scope flaw affecting curl and libcurl when Public Suffix List support is enabled.

In the documented case, an origin that is itself a public suffix can send a Set-Cookie header whose Domain explicitly matches that suffix. Instead of converting the cookie to a strict host-only cookie, affected versions can store it with wildcard domain scope. A later request or redirect to a sibling subdomain can then receive the cookie.

The curl project emphasizes that an attacker cannot plant the initial cookie. Exploitation requires the public-suffix apex to issue it and the client later to contact an attacker-controlled sibling. The issue nevertheless matters to proxy-enabled collectors because long-running workers often combine redirects, persistent cookie jars and many unrelated destinations.

Confirm the affected scope

Treat a worker as potentially exposed only when these conditions are true or unknown:

1. It runs curl or libcurl 7.46.0 through 8.21.0.
2. The build has libpsl support enabled.
3. The workflow accepts and reuses cookies.
4. It can visit or follow redirects between sibling domains under a public suffix.
5. The same cookie state survives across those requests.

Versions before 7.46.0 and versions 8.22.0 or later are outside the advisory's affected range. The command-line curl tool is also in scope when used with cookies; this is not limited to embedded libcurl applications.

Inventory cookie state before testing

For every collector or verification worker, record:

application_build
loaded_curl_version
libpsl_enabled
cookie_engine_enabled
cookie_jar_scope
redirect_policy
destination_tenant
proxy_session_alias
worker_region

Do not record cookie values, proxy passwords, tokens or customer identifiers. The audit needs configuration and scope evidence, not secrets.

Check both memory-only cookies and cookie files. A process may load an old jar at startup, share a jar across jobs, or write a jar that a later worker reuses. Container replacement does not remove risk if the jar lives on shared storage.

Apply the remediation order

The curl advisory recommends:

1. upgrade curl and libcurl to 8.22.0;
2. apply the official patch to the deployed version;
3. avoid cookies if neither remediation is immediately possible.

Verify the library actually loaded by the process. A newer curl binary on the host does not prove that an SDK or service uses the same libcurl. Restart or drain long-lived workers and confirm their runtime version after deployment.

Build an isolated regression test

Use only domains and DNS zones you own or are authorized to test. A safe laboratory can model the boundary with a private test suffix or controlled equivalent without sending any secret cookie.

Create a harmless marker cookie and run this sequence:

1. start with a clean, isolated cookie jar;
2. confirm the test client reports libpsl support and the expected curl version;
3. have the controlled apex return the boundary-case Domain attribute;
4. inspect the stored cookie metadata without exposing its value;
5. request a controlled sibling hostname through the same worker;
6. assert that the marker is not sent to the sibling;
7. repeat through an HTTP redirect;
8. repeat after connection reuse and after process restart;
9. compare an affected laboratory build with curl 8.22.0.

The pass condition is host-only containment. A successful HTTP response, proxy tunnel or redirect is not evidence that the cookie boundary was preserved.

Separate cookie identity from proxy identity

Rotating an IP address does not clear application cookies. Likewise, keeping a sticky residential proxy session does not justify sharing one cookie jar across users, sites or tenants.

Use a partition key that includes the authorized browser or job identity and the destination trust boundary. Never use only the proxy exit IP as the cookie-jar key. Two jobs can reuse an exit while requiring completely isolated state, and one job can rotate exits while retaining its own legitimate session.

Audit redirects and replay

Collectors frequently follow redirects automatically. Record the original host, each redirect target, registrable-domain transition and whether a cookie was attached. Use cookie-name aliases or counts rather than values.

Limit redirect depth and reject unexpected scheme or trust-boundary changes. Do not retry a suspicious redirect through multiple proxy exits: that increases exposure and obscures the original sequence.

Cookie files also need lifecycle controls. Restrict permissions, encrypt sensitive storage where required, assign a clear owner, set a short retention period and delete test jars through an approved cleanup process.

Rollout checklist

• [ ] Runtime curl or libcurl versions are known.
• [ ] libpsl support is confirmed per artifact.
• [ ] Cookie engines, files and shared storage are inventoried.
• [ ] Redirect policies and destination transitions are logged safely.
• [ ] curl 8.22.0 or the official patch is deployed.
• [ ] Long-running workers have reloaded the fixed library.
• [ ] A controlled sibling-domain test proves containment.
• [ ] Memory and file-backed jars are both tested.
• [ ] Cookie jars are partitioned by job or tenant identity.
• [ ] Proxy exit IP is not the sole state-partition key.
• [ ] Logs and fixtures contain no real cookies or credentials.
• [ ] Suspicious redirects do not trigger unbounded retries.

Related 98IP guidance covers proxy credential rotation, residential proxy session stickiness testing, and curl 8.22 trust-cache auditing.

FAQ

Is every cookie handled by curl exposed?

No. The advisory describes a narrow Public Suffix List boundary case. Confirm version, libpsl support, cookie use, domain behavior and subsequent sibling requests before declaring exposure.

Does changing the proxy IP mitigate the issue?

No. The problem is cookie scope in the client. IP rotation changes the network path but does not repair or erase an overly broad cookie.

Is disabling redirects enough?

Not necessarily. A later explicit request to a sibling can also carry the cookie. Redirect review is important, but upgrading or patching is the primary remediation.

Should production cookies be used in the regression test?

No. Use a harmless marker inside an authorized laboratory. The test validates scoping behavior and does not need real authentication material.

Compliance note

Test only domains, accounts and proxy resources you own or are authorized to use. Protect cookies as credentials, minimize retention, respect destination terms and privacy requirements, and never attempt to access sibling domains or user sessions without permission.

Source note: curl project, “domain-scoped PSL domain cookie,” CVE-2026-82209, published September 2, 2026; curl 8.22.0 change log, September 2, 2026.