CVE-2026-59843

What it actually does

The flaw is a denial-of-service condition in libssh channel handling. A remote peer that has successfully authenticated can send an SSH_MSG_CHANNEL_OPEN message advertising a maximum packet size of zero. Subsequent attempts by the libssh-based service to write data to that channel can enter an indefinite loop, consuming CPU and degrading or preventing availability of the affected service. The issue does not provide confidentiality or integrity impact, but it can cause high CPU usage and service disruption over the network with low attack complexity once the attacker has valid credentials or equivalent authenticated access.

Why it matters to the business

An authenticated attacker can disrupt services that rely on vulnerable libssh versions, potentially causing SSH-backed management, automation, file transfer, or embedded administrative functions to become slow or unavailable. Because libssh is a library used by downstream applications, exposure depends on which products or services include the vulnerable package; organizations with broad use of libssh-based components may have multiple affected service paths. The vulnerability is not listed in CISA KEV, has low EPSS at the time of assessment, and has no reported mature public exploit in the supplied data, but it is simple to trigger for an authenticated attacker and should be remediated during normal priority patch cycles or faster where libssh-backed services are internet-facing or operationally critical.

How an attack unfolds

An attacker first obtains credentials or otherwise reaches an authenticated SSH session against an application or service using the vulnerable libssh library. After authentication, the attacker crafts an SSH channel open request using SSH_MSG_CHANNEL_OPEN and sets the advertised maximum packet size to zero. The vulnerable libssh implementation accepts or mishandles this channel parameter. When the service later attempts to write data to that channel, the zero packet size causes channel write logic to loop indefinitely instead of making progress or failing cleanly. Repeating this interaction or maintaining multiple affected sessions can drive sustained CPU consumption, eventually degrading responsiveness or causing denial of service for legitimate users. No specific threat actor exploitation or ransomware use is indicated in the supplied data.

How to fix it

Upgrade affected Red Hat libssh-main packages to the fixed release identified by the vendor: libssh-main fixed in 0.12.1-4.hum1 via RHSA-2026:42922. Where libssh is bundled into appliances, containers, or statically linked applications, obtain updated builds from the product vendor and redeploy affected images or binaries. Restart services that dynamically link to libssh after patching so the corrected library is loaded. If immediate patching is not possible, reduce exposure by limiting network access to libssh-backed services, enforcing least-privilege accounts, disabling unnecessary SSH-based features, applying connection and session rate limits, and monitoring or terminating sessions that cause abnormal CPU consumption. These mitigations reduce exploitability but should not be treated as a substitute for applying the fixed version.

How to confirm the fix worked

Confirm installed package versions show libssh-main at 0.12.1-4.hum1 or later, or confirm the applicable vendor advisory RHSA-2026:42922 has been applied. Verify that all running services using libssh have been restarted after the update by checking loaded library mappings or restarting the host where appropriate. Inventory containers, appliances, and embedded products separately because they may carry their own libssh copy independent of the host package manager. Where safe and authorized, validate resilience in a test environment by attempting an authenticated SSH channel open with a zero maximum packet size and confirming the service rejects it or closes the session without sustained CPU growth. Operationally, confirm no libssh-linked process exhibits abnormal CPU usage after patching and that SSH-backed service availability remains stable under normal authenticated use.

Typical attack path

1. Identify a reachable service or application that uses a vulnerable libssh build.
2. Authenticate to the service using valid credentials, a compromised account, or another permitted authentication path.
3. Open an SSH channel using SSH_MSG_CHANNEL_OPEN while advertising a maximum packet size of zero.
4. Trigger or wait for the server-side application to write data to the malformed channel.
5. Maintain or repeat the malformed channel interaction to cause indefinite looping and sustained CPU consumption.
6. Degrade or deny access to the affected libssh-based service for legitimate users.

How to detect it

Investigate whether libssh-based services experienced unexplained CPU saturation, hangs, watchdog restarts, or availability degradation correlated with authenticated SSH sessions. Relevant sources include system logs, authentication logs, service-specific SSH logs, endpoint process telemetry, CPU and service health metrics, container runtime logs, and network telemetry capable of decoding SSH message types. Look for repeated authenticated connections followed by abrupt disconnects, long-lived sessions with little normal activity, high CPU in processes linked against libssh, and error messages referencing invalid channel parameters, channel open failures, zero packet sizes, or SSH_MSG_CHANNEL_OPEN. Because SSH payloads are encrypted after handshake, most network devices will not see the malformed channel parameter unless they terminate or instrument SSH; host-side service logging and process telemetry are typically more useful. If threat hunting historical activity, correlate time windows of elevated CPU or service unresponsiveness with source accounts and IP addresses that established authenticated SSH sessions shortly before the event.

• SSH_MSG_CHANNEL_OPEN
• maximum packet size 0
• max packet size 0
• zero maximum packet size
• invalid channel packet size
• channel open failed
• libssh
• RHSA-2026:42922
• libssh-main-0.12.1-4.hum1
• sshd
• sftp-server

What your security team should do

• Inventory externally reachable and business-critical services that use libssh, including packaged applications, containers, appliances, and embedded management interfaces.
• Apply RHSA-2026:42922 and upgrade Red Hat libssh-main to 0.12.1-4.hum1 or later; restart dependent services after patching.
• Prioritize remediation for internet-facing, partner-facing, or high-availability services where authenticated users are numerous or less trusted.
• Review SSH authentication logs for unusual authenticated sessions preceding high CPU events, especially repeated short-lived connections from the same source.
• Temporarily restrict access to affected services using network controls, VPN requirements, allowlists, or bastion hosts until patching is complete.
• Apply connection limits, session limits, and CPU/service watchdog controls to reduce the blast radius of attempted denial-of-service activity.
• Ensure vulnerable container images or statically linked applications are rebuilt and redeployed rather than only patching the host OS package.
• Add monitoring for sustained high CPU in libssh-linked services correlated with authenticated SSH channel activity.