CVE-2026-43868: Apache Thrift: Rust implementation vulnerable to CVE-2020-13949 pattern

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::readbytes (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:

rust fn readbytes(&mut self) -> crate::Result<Vec<u8>> { let numbytes = self.transport.readi32::<BigEndian>()? as usize; // length from the wire let mut buf = vec![0u8; numbytes]; // unbounded eager allocation self.transport.readexact(&mut buf).map(|| buf).maperr(From::from) }

There is no check that numbytes 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.

readstring routes through readbytes, 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, readbytes goes through readbinarylen, which rejects negative sizes and enforces TConfiguration::maxstringsize (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 readbytes unbounded allocation (CVE-2026-43868), fixed in 0.23.0.