libssh CVE-2026-59842

Exploitation requires the target server to be running libssh with GSSAPI key exchange support compiled in and actively enabled - this is a non-default configuration. Specifically, the server must be configured to advertise and accept GSSAPI key exchange algorithms such as gss-curve25519-sha256. The attack occurs during the pre-authentication key exchange phase, so no credentials are required (PR:N per CVSS). The high attack complexity rating (AC:H) reflects this configuration prerequisite: default libssh server deployments without GSSAPI are not affected by this vulnerability. Exploitation is further limited by the minimal data exposed per attempt; repeated connections may be needed to leak useful memory contents, which increases detection risk.

The CVSS 3.1 score of 3.7 (Low) accurately reflects a constrained risk profile. AV:N confirms network reachability and PR:N confirms no authentication is required, which are concerning signals in isolation, but AC:H significantly limits real-world exposure - GSSAPI key exchange must be explicitly compiled and enabled on the server, a configuration not present in the majority of libssh deployments. Confidentiality impact is Low (C:L), consistent with the description's qualifier of 'small amounts' of memory, and there is no integrity or availability impact (I:N/A:N). EPSS data was not provided in the available intelligence and is therefore unknown. The vulnerability is not listed in the CISA KEV catalog, and no proof-of-concept code has been identified. The realistic attack yield is low: memory leakage per attempt is small and unlikely to directly expose private keys or credentials unless heap layout is highly favorable. This is a low-priority finding for most organizations; highest risk applies to environments running libssh as a server with GSSAPI enabled that also handle sensitive in-memory data.

A remote attacker connects to an SSH server running libssh with GSSAPI key exchange enabled and deliberately initiates a GSSAPI Curve25519 key exchange, supplying a public key shorter than the required 32 bytes. The server processes the malformed key without length validation, reads beyond the allocated heap buffer, and may return small amounts of adjacent server memory as part of the exchange. No public proof-of-concept code has been identified at time of analysis.