# Connection pool reuse ignores security options

Does the pool's match key include every security-relevant option, compared with correct semantics?

_Area: Web infrastructure and server-side requests. Seen in 3 disclosed reports; 2 confirmed bounties: $480 and $2,400; latest 2022-05-12. Updated 2026-10-23._

## How it works
A connection pool decides whether an existing connection can serve a new request by comparing a stored configuration tuple against the requested one. The safety assumption is that two requests with "equal" configs share the same security boundary. When the comparison omits a security-relevant field, or compares it with the wrong semantics, a connection established under one identity or trust setting is handed to a request that asked for another. The later transfer silently inherits the earlier connection's TLS settings, credentials, or network scope.

## Where it shows up
- A match/equivalence function that enumerates config fields by hand rather than deriving them from the option set.
- Case-insensitive comparison of paths, fingerprints, or binary blobs that should be byte-wise or case-sensitive.
- Options added after the pool was written (proxy variants, TLS auth, SSH key files, CA/issuer blobs) absent from the predicate.
- Address tuples compared without scope/zone/interface fields.
- Tests that only exercise single requests, never paired requests differing in one field.

## How to review
Enumerate every security-relevant option and confirm each appears in the cache-key/match predicate with correct semantics: binary blobs byte-wise, paths and fingerprints case-sensitively, address fields including zone id and scope. The invariant: if two requests differ in any field that affects trust, identity, or network scope, they must not share a pooled connection. Test pairs that differ only in one field; a lone request passing while the paired request reuses is the failure signal.

## Variants seen
- Case-insensitive path/fingerprint comparison plus omitted CA/issuer blob options, allowing reuse of a weaker TLS connection [E1](https://bugbountylibrary.com/r/h1%3A1223565.md).
- TLS and SSH options (CRL, SSL options, TLS auth, SSH key files, proxy variants) left out of the match check, so connections matched too easily [E2](https://bugbountylibrary.com/r/h1%3A1565624.md).
- IPv6 zone index ignored, so a scoped connection was reused across interfaces [E3](https://bugbountylibrary.com/r/h1%3A1551588.md).

## Why fixes fail
Each fix patched the specific omitted fields; the underlying pattern is a hand-maintained list that drifts as options are added. Later-added options were exactly what E2 missed.

## Impact and severity
Led to MITM via weaker TLS, wrong identity or credentials on later transfers, and cross-interface data leakage. Severity rises with the sensitivity of pooled credentials and the attacker's ability to influence the first connection.

## Evidence
- E1: https://bugbountylibrary.com/r/h1%3A1223565.md
- E2: https://bugbountylibrary.com/r/h1%3A1565624.md
- E3: https://bugbountylibrary.com/r/h1%3A1551588.md