This project might be open to known security vulnerabilities, which can be prevented by tightening the version range of affected dependencies. Find detailed information at the bottom.

Crate aws-smithy-http-client

Dependencies

(26 total, 3 outdated, 2 possibly insecure)

CrateRequiredLatestStatus
 aws-smithy-async^1.2.121.2.12up to date
 aws-smithy-protocol-test^0.63.120.63.12up to date
 aws-smithy-runtime-api^1.11.41.11.4up to date
 aws-smithy-types^1.4.41.4.4up to date
 bytes ⚠️^1.10.01.11.1maybe insecure
 h2 ⚠️^0.3.240.4.13out of date
 http^1.3.11.4.0up to date
 http-body^1.0.11.0.1up to date
 http-body-util^0.1.30.1.3up to date
 hyper^0.14.261.8.1out of date
 hyper-rustls^0.24.20.27.7out of date
 hyper-util^0.1.160.1.20up to date
 indexmap^2.10.02.13.0up to date
 rustls^0.23.310.23.36up to date
 pin-project-lite^0.2.140.2.16up to date
 rustls-native-certs^0.8.10.8.3up to date
 rustls-pki-types^1.12.01.14.0up to date
 s2n-tls^0.3.330.3.34up to date
 s2n-tls-hyper^0.1.00.1.0up to date
 s2n-tls-tokio^0.3.330.3.34up to date
 serde^1.0.2101.0.228up to date
 serde_json^1.0.1281.0.149up to date
 tokio^1.461.49.0up to date
 tokio-rustls^0.26.20.26.4up to date
 tower^0.5.20.5.3up to date
 tracing^0.1.400.1.44up to date

Dev dependencies

(11 total, 1 possibly insecure)

CrateRequiredLatestStatus
 aws-smithy-async^1.2.121.2.12up to date
 aws-smithy-runtime-api^1.11.41.11.4up to date
 aws-smithy-types^1.4.41.4.4up to date
 base64^0.220.22.1up to date
 http-body-util^0.1.30.1.3up to date
 hyper-util^0.1.160.1.20up to date
 rustls-pemfile^2.2.02.2.0up to date
 rustls-pki-types^1.12.01.14.0up to date
 serial_test^3.23.3.1up to date
 tokio ⚠️^11.49.0maybe insecure
 tokio-rustls^0.26.20.26.4up to date

Security Vulnerabilities

tokio: reject_remote_clients Configuration corruption

RUSTSEC-2023-0001

On Windows, configuring a named pipe server with pipe_mode will force ServerOptions::reject_remote_clients as false.

This drops any intended explicit configuration for the reject_remote_clients that may have been set as true previously.

The default setting of reject_remote_clients is normally true meaning the default is also overridden as false.

Workarounds

Ensure that pipe_mode is set first after initializing a ServerOptions. For example:

let mut opts = ServerOptions::new();
opts.pipe_mode(PipeMode::Message);
opts.reject_remote_clients(true);

h2: Degradation of service in h2 servers with CONTINUATION Flood

RUSTSEC-2024-0332

An attacker can send a flood of CONTINUATION frames, causing h2 to process them indefinitely. This results in an increase in CPU usage.

Tokio task budget helps prevent this from a complete denial-of-service, as the server can still respond to legitimate requests, albeit with increased latency.

More details at "https://seanmonstar.com/blog/hyper-http2-continuation-flood/.

Patches available for 0.4.x and 0.3.x versions.

bytes: Integer overflow in `BytesMut::reserve`

RUSTSEC-2026-0007

In the unique reclaim path of BytesMut::reserve, the condition

if v_capacity >= new_cap + offset

uses an unchecked addition. When new_cap + offset overflows usize in release builds, this condition may incorrectly pass, causing self.cap to be set to a value that exceeds the actual allocated capacity. Subsequent APIs such as spare_capacity_mut() then trust this corrupted cap value and may create out-of-bounds slices, leading to UB.

This behavior is observable in release builds (integer overflow wraps), whereas debug builds panic due to overflow checks.

PoC

use bytes::*;

fn main() {
    let mut a = BytesMut::from(&b"hello world"[..]);
    let mut b = a.split_off(5);

    // Ensure b becomes the unique owner of the backing storage
    drop(a);

    // Trigger overflow in new_cap + offset inside reserve
    b.reserve(usize::MAX - 6);

    // This call relies on the corrupted cap and may cause UB & HBO
    b.put_u8(b'h');
}

Workarounds

Users of BytesMut::reserve are only affected if integer overflow checks are configured to wrap. When integer overflow is configured to panic, this issue does not apply.