CVE-2026-55654

What it actually does

This vulnerability is a heap out-of-bounds read in OpenSSH during cleanup of GSSAPI authentication indicators. When OpenSSH is built and configured for GSSAPI/Kerberos authentication, a malformed or unexpected auth-indicators array without a trailing NULL terminator can cause the SSH authentication path to read beyond the intended heap allocation. The expected impact is process crash or abort rather than code execution, resulting in denial of service for SSH authentication. The issue is remotely reachable over the network, requires no prior authentication, but has high attack complexity because it depends on specific GSSAPI/Kerberos configurations and authentication-path behavior.

Why it matters to the business

The primary business risk is loss or instability of SSH access, which can disrupt administrative access, automation, patching, incident response, and operational maintenance. The vulnerability has a low CVSS score, low EPSS probability, no CISA KEV listing, and no known mature exploit in the provided intelligence, so broad opportunistic exploitation is not currently indicated. However, because OpenSSH is widely deployed across Linux and Unix-like systems, including Red Hat Enterprise Linux and hardened image distributions, organizations that enable GSSAPI/Kerberos SSH authentication should treat exposed management interfaces as sensitive availability dependencies.

How an attack unfolds

An attacker first identifies an SSH service that supports GSSAPI authentication in a Kerberos-backed environment. They initiate an SSH authentication attempt that reaches the GSSAPI authentication handling code path. Under the vulnerable condition, OpenSSH later cleans up GSSAPI auth-indicator data that is missing the expected trailing NULL terminator. During cleanup, the process reads past the end of the heap allocation and may hit invalid memory or internal consistency checks, causing the sshd authentication process to abort or crash. Repeating the interaction can cause repeated authentication worker failures and may degrade or interrupt SSH availability, especially on systems with weak connection throttling, aggressive restart limits, or limited process capacity.

How to fix it

Apply vendor-provided OpenSSH updates for all affected distributions and images as soon as they are available. No exact fixed package versions were provided in the input, so track the relevant OpenSSH advisories for OpenBSD OpenSSH, Red Hat Enterprise Linux, and Red Hat hardened images. Where GSSAPI/Kerberos SSH authentication is not required, disable it by setting `GSSAPIAuthentication no` in `sshd_config` and reloading or restarting sshd. Restrict SSH exposure to trusted management networks, VPNs, or bastion hosts. Use connection throttling such as `MaxStartups`, sensible `LoginGraceTime`, firewall rate limits, and intrusion-prevention controls to reduce repeated unauthenticated authentication attempts. Ensure sshd is supervised by the operating system service manager so that crashed worker processes or the daemon are restarted, while also monitoring for restart loops.

How to confirm the fix worked

Confirm installed OpenSSH package versions against the latest vendor advisory for the operating system or image in use. Validate runtime SSH configuration with commands such as `sshd -T | grep -i gssapi` and confirm whether `gssapiauthentication` is enabled. If GSSAPI is not required, verify it is disabled in both the effective configuration and any included sshd configuration snippets. Confirm SSH is reachable only from intended management sources by reviewing firewall, security group, host firewall, and network ACL rules. After patching or mitigation, restart or reload sshd and confirm normal SSH logins still work. Review system logs for new sshd crashes, coredumps, abnormal service restarts, or repeated GSSAPI authentication failures after the change.

Typical attack path

1. Discover hosts exposing SSH, typically TCP/22 or another configured SSH port.
2. Determine whether the SSH service advertises or accepts GSSAPI authentication mechanisms.
3. Target systems integrated with Kerberos or otherwise configured with GSSAPI authentication enabled.
4. Initiate crafted or abnormal GSSAPI authentication attempts that exercise the vulnerable cleanup path.
5. Trigger an out-of-bounds read during auth-indicator cleanup, causing the sshd authentication process to abort or crash.
6. Repeat attempts to cause recurring SSH authentication failures or service instability.

How to detect it

Look for evidence of SSH service instability rather than data theft or command execution. Primary log sources include system journal logs, `/var/log/auth.log`, `/var/log/secure`, `/var/log/messages`, kernel logs, systemd unit logs for sshd, coredump records, endpoint telemetry, and network logs for SSH connection spikes. Focus on systems where GSSAPI/Kerberos SSH authentication is enabled. Indicators include repeated sshd child crashes, segmentation faults, abort messages, coredumps involving sshd, systemd restart loops, sudden increases in unauthenticated SSH sessions, and repeated GSSAPI authentication failures from the same source or distributed sources. Correlate crash timestamps with inbound SSH connections and authentication attempts. Since exploitation is expected to cause denial of service and no reliable exploit-specific payload indicators are provided, absence of a unique IOC does not rule out exploitation.

• GSSAPIAuthentication yes
• gssapiauthentication yes
• sshd
• segfault at
• comm="sshd"
• dumped core
• core dumped
• sshd.service: Main process exited
• sshd.service: Failed with result 'core-dump'
• sshd.service: Scheduled restart job
• fatal:
• GSSAPI
• gssapi-with-mic
• Unspecified GSS failure
• Authentication failed for gssapi-with-mic

What your security team should do

• Prioritize inventory of internet-exposed or broadly reachable SSH services that have GSSAPI/Kerberos authentication enabled.
• Patch OpenSSH through the operating system vendor as soon as fixed packages are available, especially on Red Hat Enterprise Linux, hardened images, and other centrally managed Linux baselines.
• Disable GSSAPIAuthentication on SSH servers where Kerberos-based SSH login is not explicitly required.
• Restrict SSH access to trusted administrative networks, VPNs, or bastion hosts and enforce rate limiting for unauthenticated connection attempts.
• Create detections for sshd crashes, coredumps, service restart loops, and spikes in GSSAPI-related authentication failures.
• Because this is not listed in KEV, has low EPSS, and has no known mature exploit in the provided data, handle as a targeted availability risk rather than an active widespread exploitation emergency unless local telemetry indicates otherwise.