RUSTSEC-2026-0103: Use-After-Free and Double Free in thin-vec 0.2.13

[Loirooriol]

Seems that Firefox fixed their vendored thin-vec, but didn't update Stylo's Cargo.toml...

error[vulnerability]: Use-After-Free and Double Free in IntoIter::drop When Element Drop Panics
   ┌─ /home/oriol/src/stylo/Cargo.lock:96:1
   │
96 │ thin-vec 0.2.13 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
   │
   ├ ID: RUSTSEC-2026-0103
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0103
   ├ A Double Free / Use-After-Free (UAF) vulnerability has been identified in the
     `IntoIter::drop` and `ThinVec::clear` implementations of the `thin-vec` crate.
     Both vulnerabilities share the same root cause and can trigger memory
     corruption using only safe Rust code - no unsafe blocks required. Undefined
     Behavior has been confirmed via Miri and AddressSanitizer (ASAN).

https://rustsec.org/advisories/RUSTSEC-2026-0103

[Loirooriol]

So, cargo update -p thin-vec addresses it, and since we aren't tracking Cargo.lock, there is nothing to commit.

However, I checked the published https://crates.io/crates/stylo/0.19.0/, and it's using thin-vec 0.2.14, which has the vulnerability.

@mrobinson It may be good to recreate the Cargo.lock before publishing, to ensure it uses the latest patch version for dependencies

[nicoburns]

The Cargo.lock of a library doesn't apply to dependents of thst library anyway. It's only thw Cargo.lock in the workspace of the final compile (+Cargo.toml of libs) that counts (so end users will need to cargo update to get the fix)