RustSec warns core2 maintenance stop leaves no-std users exposed

RustSec’s latest informational notice did not flag a memory-safety bug or a supply-chain exploit. It flagged something quieter, and in no_std work just as disruptive: the maintainer of core2 decided to stop maintaining the crate and yanked every published version.

RUSTSEC-2026-0105 was reported on April 14, 2026 and issued on April 22, 2026. RustSec classified it as Type INFO and marked the package unmaintained. That matters because core2 sits squarely in the embedded and constrained-device world, where one small utility crate can be wired into firmware, libraries, and downstream APIs across a large dependency tree.

core2’s own description says it provides a stable interface for I/O and error traits in no_std environments, and that its current code corresponds to the stable API of Rust 1.47.0. Its README says the crate is std by default, switches to no_std mode with no default features, and can enable optional alloc support. It also exposes nightly-only buffer features such as BufReader and BufWriter. For projects that built around those assumptions, the maintenance stop was not abstract. It was a signal that the ground had shifted.

RustSec pointed users toward embedded-io and no-std-io2 as replacements. embedded-io is maintained by the HAL team, offers replacement traits for embedded systems, and deliberately diverges from std::io by making Error an associated type while treating Read and Write as always blocking. For non-blocking designs, it adds ReadReady and WriteReady. That path is not free, though. embedded-io says its minimum supported Rust version is stable 1.81 and up, which immediately puts pressure on older downstream baselines.

Cargo’s rules make the migration problem sharper. A yanked version is not selected for new projects or checkouts without an existing lockfile, and Cargo says crates should only be yanked in exceptional circumstances, with a semver-compatible replacement published first when possible. In other words, a yanked crate can continue to limp along in existing lockfiles, but reproducible builds, fresh checkouts, and registry-aware tooling can start failing fast.

The disruption was visible almost immediately in the RustSec advisory database itself. Maintainers noted that core2 was a hard dependency of libflate and may be part of its public API. A separate libflate issue said core2 was no longer supported and that all published versions had been yanked. That makes this more than a maintenance footnote. For embedded teams, it is a reminder that a crate without a CVE can still become a practical risk the moment old tutorials, sample code, and transitive dependencies keep pointing at it.