ZDF
Sign inSign up

Vulnerabilities

Vulnerability · CVE-2026-111062

A russh SSH server accepts a publickey authentication whose signature uses a different algorithm than the one named in the request

Published Oct 19, 2026 · catalog updated Oct 19, 2026 · A russh SSH server

Open the advisory

Exploitation likelihood is not on this record for CVE-2026-111062. A missing EPSS score is not a low risk. Compare A russh SSH server with the linked advisory before you change production.

Gaps on this record

  • The stored product name is a package slug. The name on this page is taken from the title (A russh SSH server).
  • No vendor fix or required action is stored. Compare the linked advisory before you change production.
  • EPSS is missing. A missing score is not a low risk.
Severity
Low—
Known exploitation
Not in CISA/VulnCheck KEV
EPSS
Awaiting synchronization with FIRST
Remediation
Advisory link
Affected products
crates.io russh

### Details In , (0.63.3, around lines 880-990): * The requested algorithm name ( ) is read and only used to decode the key: . The derived is then dropped ( ). * The signature blob is decoded ( ) and verified with . picks the hash from **the signature's own algorithm** ( ). * and are never compared. So for an RSA key, the request can say while the signature is . The signature is valid for SHA-1, verification succeeds, and is called. **Affected versions: every russh release, from the first ( , 2022-03) through 0.63.3 and current .** The behaviour is inherited from , which russh was forked from. The mechanism changed over time, but the outcome is the same: the hash is always taken from the signature blob, never checked against the request. * **Up to 0.46:** after reading the algorithm name inside the signature blob, russh overwrites the key's hash with it ( ), then verifies. * **From 0.47/0.48 (move to ):** the signature is decoded with its own algorithm ( , later ) and verified with it. Confirmed by running the PoC below on 0.63.3. Confirmed by reading the code of in 0.34.0-beta.1, 0.34.0, 0.36.0, 0.36.1, 0.37.1, 0.40.2, 0.43.0, 0.45.0, 0.46.0, 0.48.2, 0.50.4, 0.54.6, 0.58.1, 0.63.1, 0.63.3 and (2026-09-30), and in thrussh 0.33.5. ### PoC A unit test in the existing test module of . It uses the module's own helpers ( , , ) and needs no network or configuration. 1. Check out russh 0.63.3, or . 2. Paste the code below inside of . 3. Run . Result on unmodified 0.63.3: With the fix below, the test passes and the whole library suite still passes: gives 186 passed. Suggested fix: reject a mismatch through the existing path, so the constant rejection time is kept. ### Impact This is a missing check on the signature algorithm (improper verification of a cryptographic signature's algorithm, CWE-347) in the server's authentication. Who is impacted: applications that use russh as an **SSH server** and rely on the requested algorithm to restrict, record or audit user-key signatu

Are you affected?

Enter the version you run. The result uses only the ranges stored on this record.

The check returns affected, not affected, or incomplete. It does not guess a version that is missing from the record.

  • crates.io russh0.34.0-beta.1 → 0.64.0

How to fix CVE-2026-111062

What to do

Three questions, each answered from this record only. Confirm the vendor advisory before you patch.

Should you patch?

Exploitation likelihood is not on this record for CVE-2026-111062. A missing EPSS score is not a low risk. Compare A russh SSH server with the linked advisory before you change production.

Which versions are affected?

Compare what you have installed with 0.34.0-beta.1 → 0.64.0. Compare the installed version with the linked vendor advisory before you change production.

What should an analyst verify?

CWE-347: Improper Verification of Cryptographic Signature. EPSS is not on this record yet. There is no CISA KEV listing. No Exploit-DB or Metasploit reference is linked. Use the source links for the original advisory.

Code

The project this record applies to. Exploit listings stay in References.

Timeline

Detection, updates, and resolution for this record.

  1. Oct 19, 2026 · GitHub Advisory Database

    Detected

    ### Details In , (0.63.3, around lines 880-990): * The requested algorithm name ( ) is read and only used to decode the key: . The derived is then dropped ( ). * The signature blob is decoded ( ) and verified with . picks the hash from **the signature's own algorithm** ( ). * and are never compared. So for an RSA key, the request can say while the signature is . The signature is valid for SHA-1, v

  2. Oct 19, 2026 · GitHub Advisory Database

    Fix available

    russh fixed in 0.64.0

  3. Oct 19, 2026 · GitHub Advisory Database

    Fix available

    russh fixed in 0.64.0

  4. Oct 19, 2026 · GitHub Advisory Database

    Updated

    ### Details In , (0.63.3, around lines 880-990): * The requested algorithm name ( ) is read and only used to decode the key: . The derived is then dropped ( ). * The signature blob is decoded ( ) and verified with . picks the hash from **the signature's own algorithm** ( ). * and are never compared. So for an RSA key, the request can say while the signature is . The signature is valid for SHA-1, v

Sources

References

Freshness

Last verified in this catalog Oct 19, 2026. Significant claims (KEV, EPSS, CVSS, affected ranges) come from the source rows above — open the original publisher for the authoritative advisory.