RUSTSEC-2022-0028: Use after free in Neon external buffers

What to do

1. See which version you have: cargo tree -i neon (it also shows which of your dependencies pulls it in).
2. Update within your version requirement: cargo update -p neon. If the fix is a newer major or minor than your requirement allows, raise it in Cargo.toml (for example neon = "0.10.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

Neon provides functionality for creating JavaScript ArrayBuffer (and the Buffer subtype) instances backed by bytes allocated outside of V8/Node. The JsArrayBuffer::external and JsBuffer::external did not require T: 'static prior to Neon 0.10.1. This allowed creating an externally backed buffer from types that may be freed while they are still referenced by a JavaScript ArrayBuffer.

The following example demonstrates use after free. It compiles on versions <0.10.1 and fails to compile afterward.

pub fn soundness_hole(mut cx: FunctionContext) -> JsResult<JsArrayBuffer> {
    let mut data = vec![0u8, 1, 2, 3];
    
    // Creating an external from `&mut [u8]` instead of `Vec<u8>` since there is a blanket impl
    // of `AsMut<T> for &mut T`
    let buf = JsArrayBuffer::external(&mut cx, data.as_mut_slice());

    // `buf` is still holding a reference to `data`!
    drop(data);

    Ok(buf)
}

References

• Package: crates.io/crates/neon
• Advisory: rustsec.org/advisories/RUSTSEC-2022-0028.html
• Report: github.com/neon-bindings/neon/issues/896

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