On Windows, configuring a named pipe server with pipe_mode will force ServerOptions::reject_remote_clients as false.

This drops any intended explicit configuration for the reject_remote_clients that may have been set as true previously.

The default setting of reject_remote_clients is normally true meaning the default is also overridden as false.

Workarounds

Ensure that pipe_mode is set first after initializing a ServerOptions. For example:

let mut opts = ServerOptions::new();
opts.pipe_mode(PipeMode::Message);
opts.reject_remote_clients(true);

Impact

Due to a non-constant-time implementation, information about the private key is leaked through timing information which is observable over the network. An attacker may be able to use that information to recover the key.

Patches

No patch is yet available, however work is underway to migrate to a fully constant-time implementation.

Workarounds

The only currently available workaround is to avoid using the rsa crate in settings where attackers are able to observe timing information, e.g. local use on a non-compromised computer is fine.

References

This vulnerability was discovered as part of the "Marvin Attack", which revealed several implementations of RSA including OpenSSL had not properly mitigated timing sidechannel attacks.

In the unique reclaim path of BytesMut::reserve, the condition

if v_capacity >= new_cap + offset

uses an unchecked addition. When new_cap + offset overflows usize in release builds, this condition may incorrectly pass, causing self.cap to be set to a value that exceeds the actual allocated capacity. Subsequent APIs such as spare_capacity_mut() then trust this corrupted cap value and may create out-of-bounds slices, leading to UB.

This behavior is observable in release builds (integer overflow wraps), whereas debug builds panic due to overflow checks.

PoC

use bytes::*;

fn main() {
    let mut a = BytesMut::from(&b"hello world"[..]);
    let mut b = a.split_off(5);

    // Ensure b becomes the unique owner of the backing storage
    drop(a);

    // Trigger overflow in new_cap + offset inside reserve
    b.reserve(usize::MAX - 6);

    // This call relies on the corrupted cap and may cause UB & HBO
    b.put_u8(b'h');
}

Workarounds

Users of BytesMut::reserve are only affected if integer overflow checks are configured to wrap. When integer overflow is configured to panic, this issue does not apply.

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.