Exposure of temporary credentials in logs in Apache Arrow Rust Object Store, version 0.10.1 and earlier on all platforms using AWS WebIdentityTokens.

On certain error conditions, the logs may contain the OIDC token passed to AssumeRoleWithWebIdentity. This allows someone with access to the logs to impersonate that identity, including performing their own calls to AssumeRoleWithWebIdentity, until the OIDC token expires. Typically OIDC tokens are valid for up to an hour, although this will vary depending on the issuer.

Users are recommended to use a different AWS authentication mechanism, disable logging or upgrade to version 0.10.2, which fixes this issue.

Details

When using AWS WebIdentityTokens with the object_store crate, in the event of a failure and automatic retry, the underlying reqwest error, including the full URL with the credentials, potentially in the parameters, is written to the logs.

Thanks to Paul Hatcherian for reporting this vulnerability

Affected versions of the thrift crate size a buffer directly from an attacker-controlled 4-byte length read off the wire, before reading any payload and with no upper bound, allowing a hostile peer to force a large eager allocation or an immediate abort (denial of service, CWE-400 / CWE-789). This is the Rust implementation's instance of the CVE-2020-13949 pattern, published by the Apache Thrift PMC as CVE-2026-43868.

Details

In TBinaryInputProtocol::read_bytes (src/protocol/binary.rs), the length is read as a i32 from the transport and cast straight to usize to size a zeroing buffer before any payload is read:

fn read_bytes(&mut self) -> crate::Result<Vec<u8>> {
    let num_bytes = self.transport.read_i32::<BigEndian>()? as usize; // length from the wire
    let mut buf = vec![0u8; num_bytes];                               // unbounded eager allocation
    self.transport.read_exact(&mut buf).map(|_| buf).map_err(From::from)
}

There is no check that num_bytes is non-negative or that it fits within the data actually available:

• A length of 0x7FFFFFFF forces a ~2 GiB allocation; 0x20000000 forces 512 MiB; and so on, from only a 4-byte input.
• A negative length casts to a huge usize (up to usize::MAX), causing an immediate allocation failure / abort.

read_string routes through read_bytes, so string fields are affected the same way. The sink is reachable from any peer sending binary-protocol data, so this is an unauthenticated, network-reachable denial of service.

The fix

From thrift 0.23.0 onward, read_bytes goes through read_binary_len, which rejects negative sizes and enforces TConfiguration::max_string_size (default 100 MiB), alongside default message, frame, and recursion limits.

A separate, related gap on the non-strict message-name path was published as CVE-2026-58389 and fixed in 0.24.0; this advisory covers the read_bytes unbounded allocation (CVE-2026-43868), fixed in 0.23.0.