Loading story…
A memory-corruption vulnerability in the Rust crate metacall allows a bad-free to be triggered through the safe public API MetaCallException::new(). The flaw affects crate version 0.5.10 and stems from passing the address of a stack-allocated Rust exception structure into C code, then later wrapping that pointer while the destructor still treats it as heap memory and frees it. RustSec assigned the issue RUSTSEC-2026-0156, warning that simply creating and dropping a MetaCallException can cause invalid memory deallocation without requiring callers to use unsafe Rust.
A related vulnerability report published in the metacall/core repository said AddressSanitizer reproduces the crash in exception_destroy and traced the root cause to storing a pointer to Rust stack memory while an internal leak flag remains false, causing Drop to free an invalid pointer. The same report flagged broader unsoundness in the crate, including shallow-copy Clone implementations over raw pointers and a safe new_raw API that accepts arbitrary raw pointers and dereferences C memory. No patched version was listed in the advisory, and the reporter recommended heap-allocating structures passed to C and marking raw-pointer constructors unsafe or otherwise restricting them.
See affected versions and whether adversaries are exploiting it.
2 events from the most recent confirmed update back to the earliest known activity.
RustSec published advisory RUSTSEC-2026-0156 for a memory-corruption flaw in metacall involving a bad-free in MetaCallException::new. The advisory stated that creating and dropping a MetaCallException through the safe public API could trigger the flaw and listed no patched versions.
A vulnerability report disclosed multiple memory-safety issues in the Rust crate metacall, centered on a bad-free in MetaCallException::new and Drop affecting version 0.5.10. The report included a proof of concept, sanitizer-based reproduction steps, and analysis of related unsound APIs and pointer-handling flaws.
See whether adversaries are exploiting this yet, and where the affected versions run in your environment.
2 references tracked. Mallory keeps watching after this page renders.
Map indicators from this story to your assets and identify affected systems in minutes.
Every observed campaign, victim, and pivot linked to actors named in this story.
Malware, exploits, and IOCs connected to the activity described here.
YARA, Sigma, and Snort rules deployed to your SIEM as soon as they’re published.
Get matching new stories delivered to your team as they break — not the next morning.
Ask questions about this story and take action on the answers.
Other stories Mallory is tracking that overlap on entities, sources, or topic labels.
A soundness flaw in the Rust `cgmath` crate allows `Matrix2::swap_columns`, `Matrix3::swap_columns`, and `Matrix4::swap_columns` to trigger undefined behavior from safe Rust code when callers pass identical column indices. The affected implementations in `cgmath` `0.18.0` use `std::ptr::swap` on two mutable references derived from the same matrix when inputs such as `m.swap_columns(0, 0)` are supplied, violating Rust aliasing guarantees and creating a memory-corruption risk. The issue was documented in **RustSec** as `RUSTSEC-2026-0197` and reproduced with proof-of-concept examples and Miri diagnostics showing a **Stacked Borrows** violation inside `std::ptr::swap`. No patched release was listed in the advisory, though the reported fix is straightforward: return early when both indices are equal before performing the swap, and apply that guard consistently across the `Matrix2`, `Matrix3`, and `Matrix4` implementations.
Jul 3, 2026
Two high-severity vulnerabilities were disclosed in **rust-openssl**, the Rust bindings for OpenSSL, affecting multiple `0.9.x` and `0.10.x` releases prior to **`0.10.78`**. **`CVE-2026-41898`** affects versions from `0.9.24` up to, but not including, `0.10.78`, where several FFI trampoline callback paths passed a closure-returned `usize` to OpenSSL without validating it against the output buffer size. The flaw can trigger buffer overflows and leak adjacent memory to a network peer, and it is mapped to **`CWE-126`** and **`CWE-130`**. A second issue, **`CVE-2026-41681`**, affects versions from `0.10.39` up to, but not including, `0.10.78`, in `MdCtxRef::digest_final()`, which writes `EVP_MD_CTX_size(ctx)` bytes to the caller buffer without checking whether the buffer is large enough. The resulting out-of-bounds write can cause stack corruption and is reachable from safe Rust, with the weakness classified as **`CWE-121`**. Both vulnerabilities were addressed in **`rust-openssl 0.10.78`**, with public advisories, code references, and fix details released alongside the CVE records.
Jun 29, 2026
Multiple vulnerabilities in the Rust serialization crate **rkyv** allow crafted untrusted archives to bypass validation in supposedly safe checked deserialization paths and trigger memory safety failures. RustSec advisories `RUSTSEC-2026-0233`, `RUSTSEC-2026-0234`, and `RUSTSEC-2026-0235` describe flaws that can lead to a heap use-after-free in `ArchivedString::deserialize`, out-of-bounds reads in archives containing hash tables, and out-of-bounds reads involving `Rc`/`Arc` shared pointers. Affected safe APIs include `rkyv::access` and `rkyv::from_bytes`, and the resulting impact includes process crashes, denial of service, and potential memory exposure when applications process attacker-controlled archive bytes. The issues were fixed in **rkyv 0.8.17**, which strengthens archive range validation, rejects malformed relative pointers and inconsistent hash table states, and hardens shared-pointer verification. An upstream code change shows the project now validates shared pointers using both erased data pointers and pointer metadata, explicitly detecting conflicting metadata such as forged slice lengths that reference the same memory region. The maintainers said the `0.7` series is also affected but unsupported, and advised users handling untrusted archives to upgrade to `0.8.17` or later.
Aug 4, 2026