RUSTSEC-2019-0023: Cloned interners may read already dropped strings

What to do

1. See which version you have: cargo tree -i string-interner (it also shows which of your dependencies pulls it in).
2. Update within your version requirement: cargo update -p string-interner. If the fix is a newer major or minor than your requirement allows, raise it in Cargo.toml (for example string-interner = "0.7.1") or update the dependency that pulls it in.
3. Check again with cargo audit, or paste your Cargo.lock into our Cargo.toml checker.

Details from the advisory

Affected versions of this crate did not clone contained strings when an interner is cloned. Interners have raw pointers to the contained strings, and they keep pointing the strings which the old interner owns, after the interner is cloned. If a new cloned interner is alive and the old original interner is dead, the new interner has dangling pointers to the old interner's storage, which is already dropped.

This allows an attacker to read the already freed memory. The dangling pointers are used by the interners to check a string is already interned. An attacker can do brute force attack to get the data pointed by the dangling pointer.

The flaw was corrected by <https://github.com/Robbepop/string-interner/pull/10>. This patch implements Clone manually to the interner type, so that the internal raw pointers always point the strings owned by the same interner.

PR #10 was also backported to the 0.6 release line in <https://github.com/Robbepop/string-interner/pull/14> and was released in 0.6.4.

References

• Package: crates.io/crates/string-interner
• Advisory: rustsec.org/advisories/RUSTSEC-2019-0023.html
• Report: github.com/Robbepop/string-interner/issues/9

From the RustSec Advisory Database (CC0-1.0) via the OSV export, downloaded Oct 24, 2026. Severity score computed from the published CVSS vector.