CVE-2026-59845

What it actually does

The flaw is a local denial-of-service condition in libssh when the ProxyCommand feature is used. If libssh attempts to fork a ProxyCommand process and fork() fails, the failure can be stored internally as process ID -1. During cleanup, libssh may then send signals to PID -1, which on Unix-like systems can signal many processes that the caller is permitted to signal. This can terminate or disrupt unrelated processes under the same security context, causing availability impact. The issue does not provide remote code execution, data theft, or privilege escalation by itself, but impact can be broader when affected applications run with elevated privileges or manage critical workloads.

Why it matters to the business

Applications or services that rely on libssh and use ProxyCommand can be crashed or disrupted by a local low-privileged attacker under specific conditions. The operational risk is service interruption, failed automation, broken administrative sessions, and instability in systems where libssh-backed tools are used for orchestration, administration, or connectivity. The issue is not known to be exploited in the wild, is not in CISA KEV, has very low EPSS, and requires local access plus a failure condition, so urgency is moderate; however, organizations using Red Hat libssh packages should still patch during the next appropriate maintenance window, especially on shared or multi-user systems.

How an attack unfolds

An attacker first needs local access to a system where an application or tool uses libssh with ProxyCommand enabled. The attacker then creates or waits for conditions that cause fork() to fail, such as process-limit exhaustion, PID exhaustion, memory pressure, or other local resource constraints. When the affected libssh code tries to start the ProxyCommand helper and fork() fails, it may record the child process ID as -1 instead of treating the failure safely. Later, during cleanup or error handling, libssh sends a signal to that stored PID. Because PID -1 has special meaning on Unix-like systems, the signal may be delivered to many processes the calling user is allowed to signal. The result is disruption or termination of unrelated processes, producing a local denial of service. No public exploit maturity or named threat actor activity is currently reported for this vulnerability.

How to fix it

Upgrade affected Red Hat libssh packages to a fixed version. For the provided package stream, update libssh-main to 0.12.1-4.hum1 or later as delivered in RHSA-2026:42922. After updating, restart long-running services and applications that dynamically link to libssh so they load the patched library; where restart coverage is uncertain, schedule a reboot. As interim mitigation, reduce exposure by disabling or avoiding ProxyCommand in libssh-based workflows where practical, limiting local shell access on shared systems, enforcing process and memory limits to reduce abusive resource exhaustion, and running libssh-consuming applications with least privilege so any signal fan-out is constrained to the smallest possible process set.

How to confirm the fix worked

Confirm installed libssh packages are at or above the fixed release for the operating system package stream, specifically libssh-main 0.12.1-4.hum1 or later for the listed Red Hat advisory. Verify running processes have loaded the patched library by restarting dependent services or using platform tools to identify processes still mapped to old deleted libssh shared objects. Review SSH client and application configuration for ProxyCommand usage to understand remaining exposure. In test environments, validate that forced fork() failure during ProxyCommand setup is handled as an error and does not result in kill or signal operations against PID -1. Confirm package scanners and vulnerability management tools no longer report the affected libssh build after patching and service restart.

Typical attack path

1. Obtain local low-privileged access to a system using an affected libssh build.
2. Identify a libssh-based application, script, or workflow that uses ProxyCommand.
3. Trigger or wait for the application to initiate a ProxyCommand-backed SSH connection.
4. Induce fork() failure through local resource pressure, such as process-count limits, PID exhaustion, or memory pressure.
5. Cause libssh cleanup logic to operate on the incorrectly stored PID value of -1.
6. Resulting signals affect multiple processes that the caller is permitted to signal, disrupting user sessions, automation, or services.

How to detect it

To assess possible prior exploitation, review endpoint, audit, system, and application logs for the sequence of local resource exhaustion, failed process creation, ProxyCommand use, and broad process termination. Useful sources include Linux auditd logs, systemd journal, syslog, EDR process telemetry, kernel logs, shell history where appropriate, application logs from libssh-consuming tools, and configuration repositories containing SSH or libssh ProxyCommand settings. Look for fork failures such as resource temporarily unavailable, pids controller denials, out-of-memory activity, repeated process-limit hits, and subsequent signal activity from libssh-linked applications. In auditd telemetry, hunt for kill-family syscalls where the target PID argument is -1, especially when the process name is an SSH/libssh-based tool or the event occurs immediately after ProxyCommand execution failure. Also investigate bursts of terminated processes under the same user account, unexpected service restarts, user-session drops, or automation failures that align with fork failures. Because there is no reported in-the-wild exploitation and no stable public exploit signature, detection should focus on behavioral correlation rather than a single definitive indicator.

• ProxyCommand
• fork: Resource temporarily unavailable
• fork failed
• Cannot fork
• Resource temporarily unavailable
• pids.max
• fork rejected by pids controller
• Out of memory: Kill process
• syscall=62
• syscall=kill
• a0=ffffffffffffffff
• a0=-1
• pid=-1
• target_pid=-1
• kill(-1
• libssh
• libssh.so

What your security team should do

• Patch Red Hat libssh packages to the fixed advisory version, prioritizing shared, multi-user, administrative, and automation systems that use libssh-based tooling.
• Inventory use of ProxyCommand in libssh-consuming applications and scripts, and disable or replace it where it is unnecessary.
• Restart services that link against libssh after patching; reboot systems where dependency restart scope is unclear.
• Review local access controls on systems running affected libssh versions, because exploitation requires local access.
• Monitor for resource-exhaustion activity followed by abnormal process termination, especially around libssh-based tools and ProxyCommand execution.
• Use audit or endpoint telemetry to detect attempts to send signals to PID -1 from processes associated with libssh-consuming applications.
• Treat this as a moderate-priority availability issue given low EPSS, no KEV listing, and no known public exploitation, but do not defer indefinitely on shared or critical systems.