I think there may be a problem in native/Cargo.lock around line 1988.
The russh-cryptovec crate (<= 0.60.2) contains unsafe memory handling that allows attacker‑controlled frame lengths to trigger unchecked buffer growth. This can lead to out‑of‑bounds writes, memory corruption, and potentially remote code execution when processing SSH traffic. Because the library is used in both client and server contexts, the vulnerability has a broad attack surface and is classified as HIGH severity.
Something like this might fix it:
*** Begin Patch
*** Update File: Cargo.toml
@@
- russh-cryptovec = "0.59.0"
+ russh-cryptovec = "0.60.3"
*** End Patch
After updating the version, run `cargo update -p russh-cryptovec` to regenerate Cargo.lock with the patched crate. If russh-cryptovec is only pulled transitively (e.g., via the `russh` crate), bump the `russh` dependency to a version >= 0.60.3, which will bring in the fixed cryptovec version.
For reference: rule CVE-2026-46673. Rated high.
I have not run the test suite here, so treat the suggestion as a starting point rather than something ready to merge.
Found with automated scanning (RedGem) and reviewed before opening. If it is not useful, closing it is completely fine.
I think there may be a problem in
native/Cargo.lockaround line 1988.The russh-cryptovec crate (<= 0.60.2) contains unsafe memory handling that allows attacker‑controlled frame lengths to trigger unchecked buffer growth. This can lead to out‑of‑bounds writes, memory corruption, and potentially remote code execution when processing SSH traffic. Because the library is used in both client and server contexts, the vulnerability has a broad attack surface and is classified as HIGH severity.
Something like this might fix it:
For reference: rule
CVE-2026-46673. Rated high.I have not run the test suite here, so treat the suggestion as a starting point rather than something ready to merge.
Found with automated scanning (RedGem) and reviewed before opening. If it is not useful, closing it is completely fine.