CVE-2026-3497

What it actually does

This is a remotely reachable memory-safety flaw in downstream OpenSSH builds that include distribution-maintained GSSAPI patches; the upstream OpenSSH project itself is not described as affected. During GSSAPI key exchange, an attacker can send an unexpected GSSAPI message type that causes the server to call a disconnect helper that does not actually terminate processing. Execution continues with connection-related variables left uninitialized, and later code may read or dereference random memory. The most likely technical result is sshd child-process crash or other undefined behavior; the practical severity depends heavily on compiler, build flags, memory initialization, stack protections, and other hardening used by the Linux distribution package.

Why it matters to the business

Organizations running affected Linux distribution OpenSSH packages may face remote SSH service instability from unauthenticated network traffic, potentially disrupting administrative access, automation, file transfer workflows, and emergency operations. Because SSH is commonly internet-exposed and widely deployed across Ubuntu, Debian, Red Hat Enterprise Linux, and related systems, exposure can be broad even though current public exploit maturity is reported as none, the EPSS score is low and flat at 0.0218 over 30 days, and the issue is not currently listed in CISA KEV or associated with ransomware campaigns.

How an attack unfolds

An attacker identifies a reachable SSH server using an OpenSSH package that includes the vulnerable distribution GSSAPI delta and has GSSAPI key exchange reachable. The attacker opens a normal SSH transport connection to port 22 and steers negotiation into the GSSAPI key-exchange path. Instead of following the expected protocol sequence, the attacker sends an unexpected GSSAPI message type at the vulnerable point. The server attempts to disconnect using a helper that records an error but does not stop execution. Because processing continues without initializing the associated connection variables to safe NULL values, later code accesses uninitialized memory. Depending on the platform hardening and memory layout, this can cause a crash, abnormal disconnect, or other undefined behavior in the sshd child handling that connection.

How to fix it

Apply the Linux distribution vendor’s corrected OpenSSH package as soon as it is available; no universal fixed version was provided in the input, so use the exact package versions and advisories from Canonical Ubuntu, Debian, Red Hat Enterprise Linux, and other affected downstream distributions. Restart sshd after patching and confirm active processes are running the updated binary. Where immediate patching is not possible, disable GSSAPI key exchange and GSSAPI authentication if they are not operationally required, commonly by setting GSSAPIAuthentication no and disabling any distribution-specific GSSAPIKeyExchange option in sshd_config, then validating configuration and reloading or restarting sshd. Reduce exposure by restricting SSH access to trusted administrative networks, VPNs, bastion hosts, or allowlisted source ranges. For organizations maintaining custom OpenSSH builds, replace the non-terminating sshpkt_disconnect() use in this error path with ssh_packet_disconnect() or otherwise ensure the error path terminates safely, and build with strong compiler hardening such as stack protection, PIE, RELRO, fortified source, and automatic variable initialization where supported.

How to confirm the fix worked

Confirm whether installed OpenSSH packages come from an affected downstream distribution build that includes GSSAPI patches rather than relying only on the SSH banner. Inventory package names and versions with the native package manager, review vendor changelogs for this vulnerability, and verify that the running sshd binary was restarted after upgrade. Check effective SSH daemon configuration with sshd -T and confirm GSSAPI key-exchange or authentication features are disabled if used as a mitigation. Validate that network exposure to SSH is limited to intended administrative sources. Review system logs after patching or mitigation for new sshd crashes, GSSAPI-related pre-authentication errors, or systemd-coredump entries to ensure the vulnerable behavior is no longer reproducible.

Typical attack path

1. Scan for internet-facing or internally reachable SSH services on TCP port 22 or other configured SSH ports.
2. Fingerprint systems likely to be affected by distribution OpenSSH packages with GSSAPI patches, especially Linux distributions that ship the vulnerable delta.
3. Initiate an SSH handshake and negotiate or attempt the GSSAPI key-exchange path.
4. Send an unexpected GSSAPI message type during GSSAPI key exchange instead of the expected protocol message.
5. Trigger continuation after a non-terminating disconnect call, leaving connection variables uninitialized.
6. Cause sshd to access uninitialized memory, leading to a child-process crash or other undefined behavior depending on build hardening.
7. Repeat against multiple connections or hosts to create service instability or to probe for more severe behavior on less-hardened builds.

How to detect it

To assess prior exploitation, review SSH authentication logs, system journals, kernel logs, crash reports, and core-dump repositories for sshd crashes or abnormal disconnects during GSSAPI negotiation. Focus on events before authentication, repeated short-lived SSH sessions, systemd-coredump records for sshd, kernel segfault lines referencing sshd, and GSSAPI-related errors clustered from the same source addresses. Useful sources include /var/log/auth.log, /var/log/secure, /var/log/messages, journalctl logs for sshd and systemd-coredump, auditd process-exit records, EDR telemetry for sshd crashes, and network telemetry showing repeated SSH handshakes that terminate during key exchange. Because the issue can manifest as generic memory corruption or a crash, absence of a unique log message does not prove non-exploitation; correlate sshd crash timing with inbound SSH connection attempts and GSSAPI-related log entries.

• /var/log/auth.log
• /var/log/secure
• /var/log/messages
• /var/lib/systemd/coredump/core.sshd
• systemd-coredump
• sshd: segfault
• kernel: sshd segfault
• kernel:.*sshd.*segfault
• sshd.*GSSAPI
• sshd.*gssapi
• sshd.*gssapi-keyex
• sshd.*gssapi-with-mic
• sshd.*fatal:.*GSSAPI
• sshd.*error:.*GSSAPI
• unexpected GSSAPI message
• GSSAPI key exchange
• sshd

What your security team should do

• Prioritize patching internet-facing SSH servers, bastion hosts, jump boxes, automation gateways, and systems where SSH availability is critical.
• Use vendor advisories for Ubuntu, Debian, Red Hat Enterprise Linux, and derived distributions to identify exact affected and fixed OpenSSH package versions.
• If patching is delayed, disable GSSAPI SSH features that are not required and restrict SSH access to trusted networks or VPN paths.
• Search recent logs for sshd crashes, systemd-coredump events, kernel segfault messages, and GSSAPI-related pre-authentication failures, especially from repeated external source IPs.
• Confirm monitoring alerts on repeated sshd child crashes, abnormal SSH disconnect rates, and spikes in pre-authentication failures.
• Do not treat a generic OpenSSH version string as definitive; this issue is tied to downstream GSSAPI patches and distribution packaging.
• Track threat intelligence for any change in exploit maturity, EPSS movement, or KEV status because SSH-facing bugs can become high-priority quickly if reliable exploitation appears.