Hurl is a command line tool that runs and tests HTTP requests defined in plain text files. In version 8.0.1 and earlier, the redirect handling in packages/hurl/src/http/client.rs strips Authorization and Cookie headers and basic-auth credentials when a redirect changes host, but it carries RequestSpec.cookies created from the dedicated [Cookies] section into the redirected request. An attacker-controlled redirect can therefore receive authentication or session cookies that should remain scoped to the original host. Cookies supplied through a raw Cookie header are stripped and are not affected by this specific path. This issue is reported as fixed in version 8.1.0.

Affected: crates.io: hurl

## The Bug

Hurl <= 8.0.1 lets you define cookies two ways in a .hurl file:

1. As a raw Cookie: header in the [Header]/headers area 2. In a dedicated [Cookies] section (parsed into RequestSpec.cookies)

When following a redirect to a different host, Hurl correctly strips security-sensitive data (Authorization, Cookie header, and basic-auth user) to avoid leaking credentials cross-host — mirroring libcurl's default behavior. But it only stripped the cookie that came in as a header. Cookies declared in the [Cookies] section were carried over to the new host unchanged — a credential-leak bug.

Hurl file that leaks cookies:

```hurl GET http://localhost:8000/follow-redirect-basic-auth?change_host=true [Cookies] fruit: lemon HTTP 200 ```

Hurl file that doesn't leak cookie:

```hurl GET http://localhost:8000/follow-redirect-basic-auth?change_host=true Cookie: fruit=lemon HTTP 200 ```

## Patch

With Hurl <= 8.0.1, user can use `Cookie` header instead of the dedicated `[Cookies]` section.

Affected: Ubuntu:26.04:LTS: rust-hurl

Hurl is a command line tool that runs and tests HTTP requests defined in plain text files. In version 8.0.1 and earlier, the redirect handling in packages/hurl/src/http/client.rs strips Authorization and Cookie headers and basic-auth credentials when a redirect changes host, but it carries RequestSpec.cookies created from the dedicated [Cookies] section into the redirected request. An attacker-controlled redirect can therefore receive authentication or session cookies that should remain scoped to the original host. Cookies supplied through a raw Cookie header are stripped and are not affected by this specific path. This issue is reported as fixed in version 8.1.0.