RustSec Flags Unsound Drop Implementation in Unmaintained dyn-future Crate

A drop handler that quietly breaks memory safety while your safe code watches: that is what RUSTSEC-2026-0079 documents. The RustSec advisory database published the finding on April 2, flagging that `dyn-future`'s `Drop` implementation performs an unchecked transmute of trait-object metadata into unrelated reference types. The result is a dangling reference, memory that Rust's borrow checker believed was sound, rendered invalid at destruction time.

The crate, hosted at xacrimon/dyn-future on GitHub and advertised as a convenient performance-oriented replacement for `Box<dyn Future<Output = T>>`, sits at version 3.0.4 with no patched release in sight. The advisory is explicit: the crate is unmaintained, no fix is forthcoming, and the unsound behavior is reproducible under Miri against that exact version.

Here is the one-paragraph explanation of "unsoundness" worth committing to memory: Rust's safety guarantees rest on a contract between safe and unsafe code. When an `unsafe` block upholds that contract by only performing transmutes that preserve lifetime and ownership invariants, the surrounding safe code can trust what it sees. When it does not, the entire contract collapses. A dangling reference created inside an unsafe `Drop` handler does not announce itself; it can sit dormant until the memory it points to is reallocated, at which point a program is reading or writing someone else's data. That is precisely the class of bug Rust was built to eliminate, and a single unsound crate reintroduces it through the back door even when every line of caller code is safe-Rust.

To answer "Am I affected?" in under a minute: run `cargo audit` from the workspace root. If `dyn-future` appears anywhere in `Cargo.lock`, the advisory surfaces immediately. For teams using `cargo deny`, add an explicit deny rule for RUSTSEC-2026-0079 in `deny.toml` to block any version of the crate from passing CI. To trace exactly which dependency pulls `dyn-future` in transitively, run `cargo tree -i dyn-future`; it walks the dependency graph in reverse and names every crate responsible for the inclusion. Version 3.0.4 is the confirmed affected release and the only published version in the advisory's scope.

The migration path is straightforward for most callers. The crate's own documentation frames `DynFuture<T>` as a speed improvement over the standard boxed future pattern, which means reverting to `Box<dyn Future<Output = T>>` is the lowest-friction exit for the majority of use cases. Projects that require allocation reuse have a maintained option in tokio-util's reusable box future utilities. For teams that cannot migrate immediately, the advisory recommends auditing every code path that exercises `dyn-future`'s destruction logic and vendoring a corrected `Drop` implementation as a short-term measure. Adding a Miri-based test invocation in CI, even scoped to the async destruction paths, will catch equivalent regressions before they reach production.

The issue is also tracked as GHSA-j3w3-p6mr-3hrh in the GitHub Advisory Database, meaning it will surface in GitHub's dependency review workflow for any repository with that feature enabled. The dual advisory listing reflects how seriously the Rust advisory infrastructure now treats supply-chain soundness: Miri caught what the compiler and Clippy both missed.