CVE-2023-25136

What it actually does

OpenSSH sshd 9.1 contains a pre-authentication double-free in handling of options.kex_algorithms during key-exchange compatibility processing. A remote unauthenticated client can trigger the vulnerable code path during SSH protocol negotiation, before login, causing memory corruption in the sshd process. The most realistic impact is daemon crash or instability, resulting in denial of service; public research has also described limited control-flow influence and theoretical remote code execution, but practical exploitation is high-complexity because modern OpenSSH privilege separation, sandboxing, ASLR, allocator behavior, and process isolation substantially constrain exploitation.

Why it matters to the business

Internet-facing SSH services running vulnerable OpenSSH builds may be remotely crashed or destabilized without valid credentials, potentially interrupting administrative access, automation, file transfer jobs, backups, and emergency response operations. Because SSH is widely deployed on servers, appliances, network devices, containers, and embedded Linux distributions, exposure can be broad even when the vulnerable version is present through downstream packages. The EPSS score is very high and exploit material is available, so organizations should treat remaining OpenSSH 9.1 exposure as urgent even though this is not currently listed in CISA KEV and is not known as ransomware-driven.

How an attack unfolds

An attacker connects to a reachable sshd service and completes enough of the SSH handshake to influence compatibility and key-exchange algorithm handling. By using a crafted client identification string and negotiation sequence that reaches the vulnerable options.kex_algorithms path, the attacker causes sshd to free the same memory more than once. In common outcomes, the affected pre-authentication sshd child process aborts or crashes, which can produce connection failures and service instability. In a more advanced scenario, an attacker would attempt heap shaping across repeated connections to convert the double-free into controlled memory corruption and redirect execution, although this is considered difficult and highly dependent on platform, allocator, hardening, and OpenSSH sandbox configuration.

How to fix it

Upgrade OpenSSH to version 9.2 or later, or apply the vendor/distribution security update that backports the fix. For source builds of openssh-portable, ensure the tree includes commit 486c4dc3b83b4b67d663fb0fa62bc24138ec3946 or an equivalent downstream patch. Because many Linux distributions backport security fixes without changing the upstream version string, validate using the package changelog or vendor advisory rather than relying only on the SSH banner. If immediate patching is not possible, reduce exposure by restricting SSH to trusted management networks or VPNs, enforcing firewall allowlists, disabling direct Internet exposure, rate-limiting new SSH connections, and ensuring privilege separation, sandboxing, ASLR, and system hardening remain enabled. Restart sshd after patching where required and confirm existing listener processes are running the patched binary.

How to confirm the fix worked

Confirm no SSH listener is running vulnerable OpenSSH 9.1 code. Use package manager metadata, vendor advisories, and changelogs to verify the installed OpenSSH package includes the fix or is based on OpenSSH 9.2 or later. For source deployments, verify the openssh-portable commit includes 486c4dc3b83b4b67d663fb0fa62bc24138ec3946 or the equivalent patch. Remotely fingerprint SSH banners as a triage step, but do not treat the banner as authoritative because banners can be customized and distro packages may be backported. After patching, restart sshd and confirm the running process path and package version match the patched package. Review system journals for recent sshd crashes before and after remediation to confirm exploit attempts are no longer causing abnormal process exits.

Typical attack path

1. Identify hosts exposing SSH, typically TCP/22 or another configured SSH port.
2. Fingerprint the SSH banner and package level to find OpenSSH 9.1 or vulnerable downstream builds.
3. Open repeated unauthenticated SSH connections using crafted protocol banners and key-exchange negotiation parameters that trigger the compatibility handling bug.
4. Cause the vulnerable sshd pre-authentication process to double-free options.kex_algorithms.
5. Observe daemon crashes, failed handshakes, or service degradation; in advanced attempts, iterate heap-shaping attempts to seek code execution despite mitigations.
6. If exploitation produces a crash only, repeat connections to create denial of service or operational disruption.

How to detect it

Look for evidence of pre-authentication sshd instability rather than successful logins, because exploitation occurs before authentication and may leave limited application-level traces. Review systemd journal, syslog/auth logs, kernel logs, crash reporters, and EDR telemetry for sshd crashes, aborts, segmentation faults, malloc/free errors, core dumps, or repeated sshd restarts. Correlate crash timestamps with inbound TCP connections to SSH ports from the same source addresses in firewall, load balancer, NetFlow, Zeek, or packet-capture data. Search for unusual or repeated SSH client identification strings associated with compatibility code paths, especially rare clients such as FuTTY, and for high rates of incomplete SSH handshakes. Because a successful advanced memory-corruption exploit may not create a distinctive log entry, also review for unexpected child processes spawned by sshd, anomalous outbound network connections from sshd context, unexpected files written around the time of crashes, and privilege-separation sandbox violations. Treat absence of logs as inconclusive on systems without verbose SSH, crash, or network telemetry.

• OpenSSH_9.1
• SSH-2.0-FuTTY
• FuTTY
• sshd.*segmentation fault
• sshd.*Segmentation fault
• sshd.*core dumped
• sshd.*double free
• malloc(): double free
• free(): double free
• free(): double free detected in tcache
• sshd.*malloc
• sshd.*abort
• sshd.*SIGABRT
• sshd.*SIGSEGV
• sshd.*privsep.*abnormal
• systemd-coredump.*sshd
• /var/lib/systemd/coredump/core.sshd
• /var/crash/*sshd*
• /var/log/auth.log
• /var/log/secure
• /var/log/messages

What your security team should do

• Prioritize inventory and remediation of externally reachable SSH services reporting OpenSSH 9.1 or unknown/custom OpenSSH builds because exploit availability and EPSS indicate high scanning interest.
• Patch to OpenSSH 9.2 or a vendor-fixed package immediately; for source builds, include commit 486c4dc3b83b4b67d663fb0fa62bc24138ec3946 or equivalent.
• Validate distribution backports through package changelogs and security advisories, not only through the OpenSSH banner.
• Temporarily restrict SSH access to trusted IP ranges, VPNs, bastion hosts, or management networks until remediation is complete.
• Enable monitoring for sshd crashes, core dumps, abnormal restarts, and unusual volumes of failed or incomplete SSH handshakes.
• Review exposure on nonstandard SSH ports, appliances, containers, embedded systems, jump boxes, CI/CD workers, and backup infrastructure where OpenSSH may be bundled independently.
• Maintain rate limiting and connection throttling for SSH to reduce denial-of-service impact from repeated unauthenticated trigger attempts.