CVE-2025-48756 is a low severity flaw (CVSS 2.9) in the scsir Rust crate, version 0.2.0. The group_number function accepts values that a hardware device may not expect, so an overflow is possible. The record names no fixed version, so check the crate page and update.
What's affected
The CVE record lists the scsir crate 0.2.0 for Rust, a library for sending SCSI commands to storage devices. The public issue is dated 10 May 2025 and was closed when I fetched it. It concerns the group_number setting of the write same command: a code comment says the value must be below 0x20, but the function does not check it, and a device may expect only a few bits.
No fixed version is named in the record. The repository issue was closed when I reviewed it, which may mean a fix or a decision in a newer release. Confirm it on crates.io before you rely on that. 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 scsir
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 = "scsir"' Cargo.lock
If the version is 0.2.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 scsir 0.2.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. Validate the group number against the limit in the code comment before you pass it in, and test against a disposable device.
- 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-843, access of a resource using an incompatible type. 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 scsir 0.2.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.
