CVE-2026-48108: Russh SSH Server Denial of Service via Malformed Identification String

Technical summary

CVE-2026-48108 stems from insufficient enforcement of SSH RFC identification-string requirements in russh's server-side banner-reading logic. The vulnerability exists because the server parser reuses the same permissive client-side identification reader, which permits pre-banner data and does not enforce a bounded limit on malformed lines. An unauthenticated remote attacker can establish connections and send multiple invalid identification strings, holding open connection state and consuming server resources before authentication occurs—a classic denial-of-service pattern in the pre-encrypted phase. The CWE-20 (Improper Input Validation) classification reflects the root cause: insufficient validation of the SSH protocol handshake. Version 0.61.0 introduces proper identification-string validation aligned with OpenSSH's stricter behavior.

Business impact

Organizations using russh-based SSH servers in production face availability risk. An attacker with network access to the SSH service can launch a resource exhaustion attack by opening multiple connections and sending malformed identification strings, potentially exhausting connection limits, file descriptors, or thread pools before legitimate clients can authenticate. This is particularly damaging in multi-tenant or service-provider environments where SSH is a gateway. The attack requires no credentials and occurs before encryption is established, making it trivial to automate. Impact is mitigated if the deployment sits behind rate-limiting or connection-pooling infrastructure, but russh library users relying on application-level control are exposed.

Affected systems

Any SSH server or application built on russh versions 0.34.0-beta.1 through 0.60.x is affected. The vulnerability does not impact russh clients, only servers. Versions prior to 0.34.0-beta.1 and version 0.61.0 and later are not affected. Users should check their dependency manifests (Cargo.toml) for russh version constraints and confirm they are not pinned or tolerating a version range that includes the vulnerable span.

Exploitability

Exploitability is high from a practical standpoint. The attack requires only network access to port 22 (or whichever port the russh server listens on), no authentication, and no special knowledge of the application. An attacker can write a trivial script that opens connections and sends invalid SSH banners in a loop. The CVSS score of 5.3 (MEDIUM) reflects that the attack causes availability loss (resource exhaustion) but does not grant confidentiality or integrity breaches—data is not leaked or modified, only the service is degraded. However, a determined adversary could use this to disrupt SSH access, potentially cascading to depend­ent systems. The fact that this is not yet in CISA's Known Exploited Vulnerabilities (KEV) catalog does not reduce practical risk; it reflects newness or limited public weaponization rather than a lack of exploitability.

Remediation

Upgrade russh to version 0.61.0 or later. This is a library upgrade—no application code changes are required unless your codebase has compatibility constraints with later versions. After upgrading, rebuild and redeploy SSH services. If immediate patching is not possible, implement network-level mitigations: rate-limit inbound SSH connections per IP, enforce connection quotas, or use a proxy/firewall rule to drop connections with malformed initial data. Monitor SSH server logs for repeated connection attempts with truncated or invalid identification strings as a signal of active exploitation attempts.

Patch guidance

Update russh in your Cargo.toml to version 0.61.0 or higher. Run `cargo update` and test your SSH server integration in a staging environment before production deployment. Verify that your application's Cargo.lock reflects the new version. If your project pins russh to an exact version, explicitly change the version constraint; if you use a caret (^) or tilde (~) constraint, re-run dependency resolution to pull in the patch. After deployment, monitor SSH connection logs for any behavioral changes in client connection timing or errors.

Detection guidance

Enable SSH debug logging on affected russh servers to observe identification-string parsing. Look for repeated connection attempts from a single source IP that disconnect or timeout during banner exchange, or logs showing truncated or invalid identification frames. Network detection: use a packet sniffer to identify SSH flows that send multiple banner lines before the server sends its identification. Host-based signals include spikes in CLOSE_WAIT or TIME_WAIT socket states on the SSH port, or rapid increases in failed SSH handshakes. A security information and event management (SIEM) rule could trigger on >50 failed SSH handshakes from a single IP within 60 seconds.

Why prioritize this

Although rated MEDIUM by CVSS, this vulnerability warrants prompt attention for any organization operating russh-based SSH services. The low barrier to exploitation (no credentials, trivial script), combined with the direct availability impact, makes it a practical DoS vector. Prioritize upgrading within 60–90 days, or sooner if SSH is a critical gateway service. Organizations not running russh (e.g., using OpenSSH or other SSH implementations) are unaffected and need not act.

Risk score, explained

CVSS 5.3 (MEDIUM) correctly captures a network-accessible, unauthenticated attack with a Low complexity barrier (basic socket operations and repeated malformed SSH packets). There is no confidentiality impact (C:N), no integrity impact (I:N), but availability is lowered (A:L) through resource exhaustion. The score does not account for context-specific factors: if SSH is critical to your infrastructure, internal blast radius could be high, warranting a local risk elevation. Conversely, if SSH sits behind firewall rules limiting access to trusted networks, risk is lower.

Frequently asked questions