rustdx advisory warns of unsafe byte helpers causing undefined behavior
rustdx’s safe byte helpers could read past slice bounds, and a 3-byte input with pos 10 was enough to trigger undefined behavior.

Public safe functions in rustdx were not memory-safe in practice. RustSec’s RUSTSEC-2026-0123 warned that the crate’s bytes_helper module exposed ordinary calls that could reach undefined behavior whenever an invalid position slipped through boundary checks.
The advisory, reported on May 2, 2026 and issued on May 12, 2026, covered rustdx and listed patched versions as 0.4.4 and later. The affected helpers were into_arr4(), into_arr2(), and u8_from_le_bytes(), each of which used slice.get_unchecked(pos..pos + N) without first verifying that pos + N stayed within slice.len(). In the advisory’s example, into_arr4(&data, 10) on a three-byte slice went out of bounds because the requested range exceeded the available bytes.

That matters because rustdx describes itself in its repository metadata as a Rust data-access tool inspired by pytdx, which points directly at byte-level parsing and market-data extraction. Those are exactly the sorts of workloads where offsets come from external inputs, malformed records, or partially trusted feeds. In that environment, a helper that looks safe at the API level can still become a memory-safety bug if it treats positions as friendly instead of hostile.
The bug was also surfaced in GitHub issue #38, opened by yaokunzhang, who described the problem as a buffer overflow vulnerability in bytes_helper.rs. The report included reproduction code and Miri output showing undefined behavior, which turns this from a theoretical concern into a concrete failure mode. GitHub’s history for zjp-CN/rustdx also shows a cargo bump to v0.4.4 in the main branch history, matching the patched line named by the advisory.

RustSec’s role here is the point of the warning: it is the advisory database for crates published through crates.io, maintained by the Rust Secure Code Working Group. For crate authors, the lesson is blunt. If a safe wrapper calls unsafe indexing internally, audit every range calculation, confirm every offset plus length check, and assume every input position can be attacker-controlled. A helper that reads bytes into typed values is only as safe as its last boundary check, and rustdx showed how quickly that promise collapses when the check is missing.
Know something we missed? Have a correction or additional information?
Submit a Tip