CVE-2025-48751 is a low severity flaw (CVSS 2.9) in the process_lock Rust crate, version 0.1.0. The unlock function allows data races from safe code. The record names no fixed version, so check the crate page and the repository, and review any code that calls unlock directly.
What's affected
The CVE record lists the process_lock crate 0.1.0 for Rust, from the tickbh ProcessLock project. The public issue is dated 16 May 2025 and, when I fetched it, was still open. It argues that the unlock function should be marked unsafe, because safe code can call it while another thread holds the lock, and that produces a data race.
No fixed version is named in the record. The repository issue was still open when I reviewed it, so do not assume a fix is on the way. 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 process_lock
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 = "process_lock"' 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 process_lock 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. Prefer holding the lock through its guard, and let the guard release it, as the crate's own documentation comment suggests for normal use.
- 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.
Quick check
Do I need to patch process_lock 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.
