CVE-2026-110927 in Red Hat
Summary
by MITRE • 10/15/2026
A flaw was found in OpenSSH. After compression is negotiated, a compressed payload can expand past the maximum supported packet size because the inflate loop does not stop at that limit. Memory use grows in the process handling that connection.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/15/2026
The vulnerability identified in OpenSSH represents a critical failure in input validation and resource management within the protocol's compression implementation. Specifically, this flaw occurs during the negotiation phase where data compression is enabled for an SSH session. When a client or server initiates compressed communication, the system relies on decompression routines to process incoming payloads. The core technical defect lies in the inflate loop, which is responsible for expanding compressed data into its original form. This loop fails to enforce the maximum supported packet size limit during the expansion process. Consequently, if an attacker sends a specially crafted payload that compresses efficiently but expands significantly upon decompression, the resulting memory footprint can exceed the predefined boundaries set by the protocol specification.
This lack of boundary checking leads directly to excessive memory consumption within the specific process handling the compromised connection. As the inflated data grows beyond expected limits without triggering appropriate error conditions or termination signals, the operating system allocates increasingly large blocks of memory to accommodate this unbounded growth. This behavior effectively creates a resource exhaustion scenario that can be exploited remotely by an authenticated user who has negotiated compression with the target OpenSSH server. The impact is primarily characterized as a Denial of Service condition, where the targeted service becomes unstable or crashes due to out-of-memory errors, thereby disrupting availability for legitimate users and potentially causing system-wide instability if memory pressure affects other critical processes on the host machine.
From a classification perspective, this vulnerability aligns with CWE-400, which describes uncontrolled resource consumption, as well as CWE-789, relating to memory allocation with incorrect size or count values during decompression operations. In terms of offensive security frameworks such as MITRE ATT&CK, this flaw facilitates the T1499 endpoint denial of service tactic by allowing an attacker to degrade system performance through targeted resource exhaustion rather than attempting direct code execution or privilege escalation at this stage. The attack vector requires network access and authentication, placing it in a medium-to-high severity category depending on the deployment context and whether compression is enabled by default or negotiated dynamically.
Mitigation strategies must focus on both immediate remediation and long-term architectural improvements. The primary solution involves applying vendor-provided patches that update OpenSSH to versions where the inflate loop has been corrected to strictly enforce packet size limits during decompression. Administrators should verify their current version against known vulnerable ranges and apply updates promptly. In environments where patching is not immediately feasible, disabling SSH compression via configuration directives such as Compression no can serve as an effective workaround, although this may impact performance for legitimate users transferring large amounts of data. Additionally, implementing network-level rate limiting or memory quotas for SSH daemon processes can provide a layer of defense-in-depth to mitigate the severity of resource exhaustion attacks even if the underlying code flaw remains unpatched temporarily.