CVE-2025-48752 is a low severity flaw (CVSS 2.9) in the process-sync Rust crate, version 0.2.2. The drop function does not check whether the pthread mutex is unlocked before it destroys it. The record names no fixed version, so check the crate page and the repository.
What's affected
The CVE record lists the process-sync crate 0.2.2 for Rust, from the Forestryks process-sync-rs project. The public issue is dated 16 May 2025 and, when I fetched it, was still open. It concerns the SharedMutex type: dropping it while it is locked destroys a locked pthread mutex, which the pthread documentation treats as undefined behaviour.
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-sync
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-sync"' Cargo.lock
If the version is 0.2.2, 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-sync 0.2.2 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. Make sure a SharedMutex is never dropped while a lock guard on it is still alive, and avoid sharing one across processes unless you control the lifetime of every holder.
- 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-416, use after free. 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-sync 0.2.2 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.
