This project contains known security vulnerabilities. Find detailed information at the bottom.

Crate attohttpc

Dependencies

(16 total, 4 outdated, 2 insecure)

CrateRequiredLatestStatus
 base64^0.130.23.1out of date
 encoding_rs^0.80.8.44up to date
 encoding_rs_io^0.10.1.8up to date
 flate2^1.01.1.11up to date
 http^0.21.5.0out of date
 log^0.40.4.35up to date
 mime^0.30.3.18up to date
 multipart^0.180.18.0up to date
 native-tls^0.20.2.18up to date
 rustls ⚠️^0.200.23.46insecure
 serde^11.0.229up to date
 serde_json^11.0.154up to date
 serde_urlencoded^0.70.7.1up to date
 url^22.5.8up to date
 webpki^0.220.22.4up to date
 webpki-roots ⚠️^0.221.0.11insecure

Dev dependencies

(10 total, 4 outdated)

CrateRequiredLatestStatus
 anyhow^11.0.104up to date
 env_logger^0.90.11.11out of date
 futures^0.30.3.34up to date
 futures-util^0.30.3.34up to date
 hyper^0.141.12.0out of date
 lazy_static^11.5.1up to date
 tokio^11.54.1up to date
 tokio-rustls^0.220.26.6out of date
 tokio-stream^0.10.1.19up to date
 warp^0.30.4.3out of date

Security Vulnerabilities

rustls: `rustls::ConnectionCommon::complete_io` could fall into an infinite loop based on network input

RUSTSEC-2024-0336

If a close_notify alert is received during a handshake, complete_io does not terminate.

Callers which do not call complete_io are not affected.

rustls-tokio and rustls-ffi do not call complete_io and are not affected.

rustls::Stream and rustls::StreamOwned types use complete_io and are affected.

rustls: Unauthenticated ServerHello can downgrade later connections to classical key exchange

RUSTSEC-2026-0349

The client recorded the server-selected key exchange group for each server name when processing the ServerHello, before the server was authenticated. This record is used to predict which key share to send in future ClientHellos to that server name.

A network attacker can answer one connection attempt with a ServerHello selecting X25519, and then close the connection. Later ClientHellos for that name carry only an X25519 key share, while supported_groups still lists X25519MLKEM768 first. If the genuine server accepts that share rather than sending a HelloRetryRequest for its preferred hybrid group, the handshake completes with classical-only key exchange and no error. This persists for as long as the entry stays in the client's session store.

The impact is loss of post-quantum confidentiality for affected connections ("harvest now, decrypt later"). There is no key compromise and no authentication bypass.

The following are not affected:

  • connections to servers which send a HelloRetryRequest for their preferred group,
  • clients with resumption disabled (as nothing is stored), and
  • other server names.

This behaviour is discussed in draft-ietf-tls-key-share-prediction, so the practical impact depends largely on server policy.

webpki-roots: Bundled root certificates allow trust in distrusted emSign intermediates

RUSTSEC-2026-0381

Affected versions include emSign ECC Root CA - G3, which can allow certificate paths through distrusted emSign intermediates.

Affected versions may accept certificate paths containing distrusted emSign intermediate public keys. The private keys corresponding to these intermediates are now well known.

Version 1.0.10+ removes this root.

The webpki-roots 0.26.11 compatibility package contains no independent trust store and re-exports the roots from its separately resolved 1.x dependency. That parent dependency must resolve to 1.0.10 or newer; an older parent remains affected by this advisory.