CVE-2025-48753 is a low severity flaw (CVSS 2.9) in the anode Rust crate, version 0.1.0. Data races can occur in unlock in SpinLock. The record names no fixed version. The maintainer's reply on the public issue says only the lock owner should call unlock.
What's affected
The CVE record lists the anode crate 0.1.0 for Rust, from the obsidiandynamics anode project. The public issue is dated 15 May 2025 and was closed when I fetched it. It argues that the unlock function on SpinLock should be marked unsafe, because safe code can call it while another thread holds the lock. In the thread, a project member replies that only the lock owner should call unlock.
No fixed version is named in the record. The issue thread shows the maintainer treating this as a usage rule, so a code change may never come. That is a reasonable position for the project and a reason for you to follow the rule in your own code. Check the crate page on crates.io and the repository issue for a newer release before you decide to patch or replace it.
The CVSS vector in the record is local, with high attack complexity and no privileges, and the only impact is on availability. That is why the score is Low (2.9). The finding came from a static analyser that flagged a potential unsound API, and the public issue says so.
How to check if you're exposed
Find out whether the crate is in your dependency tree. In a Cargo project:
cargo tree -i anode
If the command prints a tree, something in your project depends on the crate, and the first line shows the version. If it reports that the package ID did not match anything, you do not use it. Then confirm the version in your lock file:
grep -A1 'name = "anode"' Cargo.lock
If the version is 0.1.0, you are in the range in the record. Also run an advisory scan on your lock file with the tool your team uses, and note that a crate marked Low can be missing from the severity filters in some tools.
Finally, find out how your code uses it. Reachability analysis answers that question for the exact functions the record names, which is the difference between a finding that matters and one that does not.
What to do now
- Check whether anode 0.1.0 is in any of your projects, direct or through another crate.
- Look on crates.io and in the repository for a newer release, and update if one exists.
- If you call the affected function, review those call sites. Never call unlock yourself unless you own the lock, and let the guard release it instead.
- If the crate is unmaintained and you rely on it, plan a move to a maintained alternative or vendor a patched copy.
- Add the crate to your tracking list so that a later fix does not go unnoticed.
Why it matters
The record lists the weakness as CWE-362, race condition. Rust's safety rules let safe code avoid memory errors and data races, and a library that exposes a safe looking function with an unsafe contract breaks that promise for everyone who calls it. A static analyser found this, and the report argues that the function should be marked unsafe, or should check its input.
Most readers will rate this low, and the score agrees. The reason to track it is practical. These findings show up in scan results next to serious issues, and teams that cannot tell them apart waste time. A clear rule, such as review local, low impact findings only where the code path is reachable, saves effort.
The issue is not listed in the CISA Known Exploited Vulnerabilities catalogue.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Do I need to patch anode 0.1.0 urgently?
Usually not. The record rates it Low, local and limited to availability. Check whether your code calls the affected function, and look for a newer release.
How do I find out if my project uses the crate?
Run cargo tree with the invert flag for the crate name, and check the version in the lock file.
Sources
Last reviewed: 18 October 2026.
