Deps.rs

lablup / bssh

[![dependency status](https://deps.rs/repo/github/lablup/bssh/status.svg)](https://deps.rs/repo/github/lablup/bssh)

This project might be open to known security vulnerabilities, which can be prevented by tightening the version range of affected dependencies. Find detailed information at the bottom.

Crate bssh

Dependencies

(50 total, 1 possibly insecure)

CrateRequiredLatestStatus
 bytes^1.11.11.12.1up to date
 tokio^1.52.31.53.0up to date
 russh^0.62.10.62.2up to date
 clap^4.6.14.6.2up to date
 anyhow^1.0.1021.0.103up to date
 thiserror^2.0.182.0.18up to date
 tracing^0.1.440.1.44up to date
 tracing-subscriber^0.3.230.3.23up to date
 serde^1.0.2281.0.228up to date
 serde_yaml^0.90.9.34+deprecatedup to date
 futures^0.3.320.3.32up to date
 async-trait^0.1.890.1.89up to date
 indicatif^0.18.40.18.6up to date
 rpassword^7.4.07.5.4up to date
 dirs^6.06.0.0up to date
 chrono^0.4.440.4.45up to date
 glob^0.3.30.3.3up to date
 whoami^2.1.12.1.2up to date
 owo-colors^4.3.04.3.0up to date
 unicode-width^0.2.20.2.2up to date
 terminal_size^0.4.40.4.4up to date
 zeroize^1.8.21.9.0up to date
 secrecy^0.10.30.10.3up to date
 rustyline^18.0.018.0.1up to date
 crossterm^0.290.29.0up to date
 ratatui^0.300.30.2up to date
 regex^1.12.31.13.1up to date
 signal-hook^0.40.4.4up to date
 nix^0.310.31.3up to date
 smallvec^1.15.11.15.2up to date
 lru^0.18.00.18.1up to date
 uuid^1.23.11.24.0up to date
 tokio-util^0.7.180.7.18up to date
 socket2^0.60.6.5up to date
 shell-words^1.1.11.1.1up to date
 libc^0.20.2.186up to date
 ipnetwork^0.210.21.1up to date
 bcrypt ⚠️^0.190.19.2maybe insecure
 argon2^0.50.5.3up to date
 rand^0.100.10.2up to date
 ssh-key=0.7.0-rc.110.6.7up to date
 async-compression^0.40.4.42up to date
 serde_json^1.01.0.150up to date
 opentelemetry^0.320.32.0up to date
 opentelemetry_sdk^0.320.32.1up to date
 opentelemetry-otlp^0.320.32.0up to date
 url^2.52.5.8up to date
 tokio-rustls^0.260.26.4up to date
 rustls-native-certs^0.80.8.4up to date
 security-framework^3.7.03.7.0up to date

Dev dependencies

(7 total, 1 outdated)

CrateRequiredLatestStatus
 tempfile^3.27.03.27.0up to date
 mockito^1.7.21.7.2up to date
 tokio-test^0.40.4.5up to date
 serial_test^3.43.5.0up to date
 insta^1.471.48.0up to date
 criterion^0.80.8.2up to date
 mockall^0.140.15.0out of date

Crate bssh-russh-sftp

Dependencies

(14 total, all up-to-date)

CrateRequiredLatestStatus
 tokio^1.52.31.53.0up to date
 tokio-util^0.7.180.7.18up to date
 serde^1.0.2281.0.228up to date
 serde_bytes^0.11.190.11.19up to date
 bitflags^2.11.12.13.1up to date
 async-trait^0.1.890.1.89up to date
 futures^0.3.320.3.32up to date
 thiserror^2.0.182.0.18up to date
 chrono^0.4.440.4.45up to date
 bytes^1.11.11.12.1up to date
 log^0.4.290.4.33up to date
 dashmap^6.1.06.2.1up to date
 wasm-bindgen-futures^0.4.710.4.76up to date
 gloo-timers^0.4.00.4.0up to date

Security Vulnerabilities

bcrypt: Panic in `bcrypt::verify` on non-ASCII hash input

RUSTSEC-2026-0199

bcrypt::verify(password, hash) and HashParts::from_str(hash) panic in str::slice_error_fail when given a 60-byte &str containing a multi-byte UTF-8 character at certain byte positions.

Impact

Any Rust code that calls bcrypt::verify (or HashParts::from_str) with an attacker-controlled hash string will panic. The bcrypt crate is #![forbid(unsafe_code)], so this is limited to a denial-of-service and cannot lead to memory corruption.

Realistic attack contexts include:

  • Rust authentication services reading hashes from a database that was previously compromised via, e.g., SQL injection. The attacker can then crash the service on every login attempt against the tampered account.
  • CLI tools accepting hashes from stdin or command-line arguments.
  • Password managers or vault services loading hashes from untrusted configuration sources.

Root cause

split_hash performed five &str slicing operations on the input hash: &hash[1..3], &hash[4..6], &hash[7..], &salt_and_hash[..22], and &salt_and_hash[22..]. None of these were char-boundary-checked. Any input where a multi-byte UTF-8 character spanned one of those byte positions caused a panic.

This is a regression of the fix originally shipped in 2021 for issue #62 (commit 0833509). The regression was introduced in the parser rewrite in PR #95 (commit e9a8394, released as 0.19.0).

The pre-existing regression test does_no_error_on_char_boundary_splitting was not removed, but was silently rendered ineffective by the new bytes[0] != b'$' guard, which rejected its input earlier and prevented it from reaching the buggy slices — leaving CI green through the regression.

Fix

split_hash now rejects any hash string containing non-ASCII bytes up front. A valid bcrypt hash is always exactly 60 ASCII bytes, so this closes the entire class of byte-boundary panics rather than guarding each slice individually.

The fix was merged in PR #103 and released as bcrypt 0.19.2 on 2026-06-20.

Downstream impact

pyca/bcrypt (which depended on bcrypt 0.19.1) is not affected. Its Python-side wrapper performs its own byte-level salt parsing before invoking bcrypt::hash_with_salt, and never reaches the buggy code path in split_hash or verify.