CVE-2026-123158 (SSHole): OpenSSH Exploitation — Detection, Hunting, and Remediation Guide

Threat actors are actively exploiting a critical OpenSSH vulnerability — dubbed "SSHole" and tracked as CVE-2026-123158 — to breach Linux systems at scale. According to reporting by BleepingComputer, successful exploitation allows attackers to execute arbitrary commands on exposed servers, harvest SSH credentials in transit, and establish persistent access that survives reboots and password resets.

This is not a theoretical exercise. Exploitation is confirmed in the wild, and given OpenSSH's ubiquity — it runs on the overwhelming majority of internet-facing Linux servers, cloud instances, network appliances, and container base images — the attack surface is enormous. If you operate Linux infrastructure with SSH exposed to any untrusted network, you should treat this as an urgent patching event and assume that unpatched, internet-reachable systems may already be compromised.

From an IR perspective, the combination of capabilities in play here is what makes SSHole particularly dangerous: remote code execution plus credential theft plus persistence means the initial compromise is only the beginning. Every interactive login, every automated deployment key, and every ssh agent forwarded to a compromised host is potential follow-on material for lateral movement.

Technical Analysis

Affected Component

The vulnerability resides in OpenSSH, the de facto standard SSH implementation shipped with virtually every Linux distribution (Ubuntu, Debian, RHEL, Rocky, Alma, SUSE), BSD variants, and embedded in countless network devices and appliances. Organizations should inventory not just servers but also network gear, storage arrays, backup appliances, and CI/CD runners — anywhere sshd or the OpenSSH client libraries are present.

Vulnerability Overview — CVE-2026-123158

Based on the reported attack behavior, SSHole enables remote attackers to:

1. Execute arbitrary commands on the target system — meaning the flaw is reachable pre- or post-authentication in a way that yields command execution in the context of the SSH daemon or the authenticating user.
2. Steal credentials — indicating the exploit path allows attackers to intercept, log, or extract authentication material (passwords, private keys, or session tokens) processed by the daemon.
3. Establish persistence — attackers are implanting backdoors on compromised hosts, commonly via modified authorized_keys files, rogue SSH configuration directives, systemd units, or replaced/malicious SSH binaries.

Attack Chain (Defender's View)

From the incidents described, the observed intrusion sequence follows a recognizable pattern:

1. Reconnaissance: Mass scanning for hosts with TCP/22 (or alternate SSH ports) exposed, fingerprinting OpenSSH banner versions to identify vulnerable builds.
2. Exploitation: Delivery of the SSHole exploit against vulnerable sshd instances, yielding command execution.
3. Credential harvesting: Collection of SSH credentials — from memory, keystroke capture of inbound logins, ~/.ssh/ directories, or SSH agent sockets.
4. Persistence: Writing attacker-controlled public keys into /root/.ssh/authorized_keys and user key files, creating new local accounts, or installing systemd services/cron jobs that re-establish access.
5. Lateral movement: Using stolen credentials and harvested keys to pivot to adjacent systems — a classic pattern where one compromised jump host cascades into a fleet-wide incident.

Exploitation Status

• Confirmed active exploitation in the wild — this is not a PoC-only situation.
• Treat any internet-facing, unpatched OpenSSH instance as potentially compromised, not merely "at risk."
• Check CISA's Known Exploited Vulnerabilities (KEV) catalog for CVE-2026-123158; if listed, federal civilian agencies face a binding remediation deadline under BOD 22-01, and the deadline serves as a useful forcing function for private-sector prioritization as well.

Detection & Response

The detections below target the behaviors reported in this campaign: anomalous SSH daemon activity, tampering with SSH authentication material, persistence via authorized_keys and systemd, and the command execution that follows exploitation. They are designed to be high-fidelity — but baseline them against your environment's legitimate automation (Ansible, Terraform provisioning, configuration management all touch SSH files legitimately).

Sigma Rules

---
title: SSH Authorized Keys Modification Outside Configuration Management
description: Detects writes to SSH authorized_keys files, a common persistence technique observed in the CVE-2026-123158 (SSHole) campaign where attackers implant attacker-controlled public keys.
references:
  - https://www.bleepingcomputer.com/news/security/hackers-exploit-sshole-openssh-flaw-to-breach-linux-systems/
  - https://attack.mitre.org/techniques/T1098/004/
author: Security Arsenal
id: 3f8a1c2e-7b4d-4e91-a6c3-9d2e5f8b1a07
status: experimental
date: 2026/04/06
tags:
  - attack.persistence
  - attack.t1098.004
logsource:
  product: linux
  category: file_event
detection:
  selection:
    TargetFilename|contains:
      - '/.ssh/authorized_keys'
      - '/.ssh/authorized_keys2'
  filter_authorized_deploy:
    Image|endswith:
      - '/ansible-playbook'
      - '/sshd'
  condition: selection and not 1 of filter_authorized_deploy*
falsepositives:
  - Legitimate key rotation by administrators or configuration management tooling
  - Cloud-init provisioning on first boot
level: high
---
title: SSHD Spawning Unexpected Child Processes
description: Detects the OpenSSH daemon spawning shells or command interpreters consistent with post-exploitation command execution via CVE-2026-123158 (SSHole).
references:
  - https://www.bleepingcomputer.com/news/security/hackers-exploit-sshole-openssh-flaw-to-breach-linux-systems/
  - https://attack.mitre.org/techniques/T1059/004/
author: Security Arsenal
id: 8c2e5b91-4d6a-4f3c-b1e7-2a9d4c6f0e53
status: experimental
date: 2026/04/06
tags:
  - attack.execution
  - attack.t1059.004
logsource:
  product: linux
  category: process_creation
detection:
  selection_parent:
    ParentImage|endswith:
      - '/sshd'
  selection_suspicious_child:
    Image|endswith:
      - '/curl'
      - '/wget'
      - '/base64'
      - '/python'
      - '/python3'
      - '/perl'
      - '/nc'
      - '/ncat'
      - '/socat'
      - '/crontab'
      - '/useradd'
      - '/adduser'
  condition: all of selection_*
falsepositives:
  - Rare; some deployment pipelines trigger downloads over SSH sessions, but useradd/crontab from an SSH session warrants review
level: high
---
title: Persistence via New SSH-Related Systemd Service or Cron Modification
description: Detects creation of systemd unit files or cron entries shortly associated with SSH compromise persistence, as observed in SSHole intrusions.
references:
  - https://www.bleepingcomputer.com/news/security/hackers-exploit-sshole-openssh-flaw-to-breach-linux-systems/
  - https://attack.mitre.org/techniques/T1053/003/
  - https://attack.mitre.org/techniques/T1543/002/
author: Security Arsenal
id: 5b1d9e47-2c8f-4a6d-93e1-7f4a2b8c5d09
status: experimental
date: 2026/04/06
tags:
  - attack.persistence
  - attack.t1053.003
  - attack.t1543.002
logsource:
  product: linux
  category: file_event
detection:
  selection_systemd:
    TargetFilename|startswith:
      - '/etc/systemd/system/'
      - '/usr/lib/systemd/system/'
      - '/run/systemd/system/'
    TargetFilename|endswith: '.service'
  selection_cron:
    TargetFilename|startswith:
      - '/etc/cron.d/'
      - '/etc/cron.daily/'
      - '/etc/cron.hourly/'
      - '/var/spool/cron/'
  condition: 1 of selection_*
falsepositives:
  - Package installations and legitimate service deployments; correlate with change windows and package manager logs
level: medium

KQL (Microsoft Sentinel)

This query hunts Syslog data (ingested via the AMA/agent from Linux hosts) for the post-exploitation pattern reported in SSHole intrusions: sshd spawning downloaders, interpreters, or account-creation commands, plus modifications to SSH key material.

// Hunt for SSHole (CVE-2026-123158) post-exploitation: suspicious children of sshd
let SuspiciousChildren = dynamic(["curl", "wget", "base64", "python", "python3", "perl", "nc", "ncat", "socat", "crontab", "useradd", "adduser"]);
Syslog
| where TimeGenerated > ago(7d)
| where ProcessName =~ "sshd" or SyslogMessage has "sshd"
| where SyslogMessage has_any (SuspiciousChildren)
| extend SuspiciousCmd = extract(@"((curl|wget|base64|python3?|perl|nc|ncat|socat|crontab|useradd|adduser)\s+[^\";]{0,200})", 1, SyslogMessage)
| project TimeGenerated, Computer, HostIP, ProcessName, SuspiciousCmd, SyslogMessage
| order by TimeGenerated desc;
// Hunt for authentication-key tampering and anomalous SSH logins from rare source IPs
let KnownSSHSourceIPs =
    Syslog
    | where TimeGenerated between (ago(30d) .. ago(7d))
    | where SyslogMessage has "Accepted" and ProcessName =~ "sshd"
    | extend SrcIP = extract(@"from ([0-9]{1,3}(\.[0-9]{1,3}){3})", 1, SyslogMessage)
    | distinct SrcIP;
Syslog
| where TimeGenerated > ago(7d)
| where ProcessName =~ "sshd"
| where SyslogMessage has "Accepted"
| extend SrcIP = extract(@"from ([0-9]{1,3}(\.[0-9]{1,3}){3})", 1, SyslogMessage)
| where SrcIP !in (KnownSSHSourceIPs)
| summarize LoginCount = count(), DistinctUsers = dcount(extract(@"for (\S+) from", 1, SyslogMessage)) by SrcIP, Computer, bin(TimeGenerated, 1h)
| order by TimeGenerated desc;

Tune the lookback windows and the baseline period to your environment. The second query surfaces first-time-seen source IPs authenticating successfully over SSH — high value for catching attackers using credentials stolen via SSHole.

Velociraptor VQL

Use this artifact across your Linux fleet (deployed via Velociraptor's Linux clients or offline collection) to identify the persistence artifacts most commonly observed in this campaign: recently modified authorized_keys files and SSH-related network listeners with unexpected process paths.

-- SSHole (CVE-2026-123158) host hunt: authorized_keys tampering and suspicious sshd listeners
-- Part 1: Recently modified authorized_keys files across all users
SELECT FullPath, Mtime, Size,
       read_file(filename=FullPath, length=4096) AS KeyContentPreview
FROM glob(globs=['/root/.ssh/authorized_keys',
                 '/home/*/.ssh/authorized_keys',
                 '/home/*/.ssh/authorized_keys2'])
WHERE Mtime > now() - 604800
ORDER BY Mtime DESC

-- Part 2: Identify processes listening on SSH ports from unexpected binary paths
SELECT Pid, Name, Path, Address, Port, Status
FROM netstat()
WHERE Port in (22, 2222, 22222, 222, 2200)
  AND Status = 'LISTEN'
  AND NOT Path =~ '/usr/sbin/sshd'

-- Part 3: Enumerate sshd processes and flag those whose executable was recently replaced
SELECT Pid, Name, Exe, CommandLine, Username, CreateTime
FROM pslist()
WHERE Name =~ 'sshd'

Review Part 1 output against your key inventory — any key you don't recognize is a critical finding. Part 2 catches attacker-deployed SSH backdoors (a common SSHole persistence move is standing up a second listener on an alternate port from a dropped binary). Part 3 supports validation that the running sshd binary is the legitimate, vendor-supplied one.

Remediation and Verification Script (Bash)

Run this across your fleet (via your automation platform of choice) to determine exposure, apply vendor updates, and surface indicators of the persistence mechanisms reported in this campaign.

#!/usr/bin/env bash
# SSHole (CVE-2026-123158) - Exposure check, patch, and persistence sweep
# Test in a staging environment first. Requires root.

set -u
echo "=== [1/5] Current OpenSSH version ==="
ssh -V 2>&1
sshd -V 2>&1 | head -n 1 || true
dpkg -l openssh-server 2>/dev/null | tail -n 1 || rpm -q openssh-server 2>/dev/null || true

echo "=== [2/5] Applying vendor security updates ==="
if command -v apt-get >/dev/null 2>&1; then
  apt-get update -y && apt-get install --only-upgrade -y openssh-server openssh-client openssh-sftp-server
elif command -v dnf >/dev/null 2>&1; then
  dnf update -y openssh openssh-server openssh-clients
elif command -v yum >/dev/null 2>&1; then
  yum update -y openssh openssh-server openssh-clients
elif command -v zypper >/dev/null 2>&1; then
  zypper --non-interactive update openssh
else
  echo "[!] Unsupported package manager — patch manually per your vendor advisory."
fi

echo "=== [3/5] Restarting sshd ==="
systemctl restart sshd 2>/dev/null || systemctl restart ssh 2>/dev/null || service sshd restart
systemctl is-active sshd 2>/dev/null || systemctl is-active ssh 2>/dev/null

echo "=== [4/5] Verifying patched version post-update ==="
ssh -V 2>&1
dpkg -l openssh-server 2>/dev/null | tail -n 1 || rpm -q openssh-server 2>/dev/null || true

echo "=== [5/5] Persistence sweep (review output manually) ==="
echo "--- authorized_keys modified in last 14 days ---"
find /root/.ssh /home/*/.ssh -maxdepth 1 -name 'authorized_keys*' -mtime -14 -exec ls -la {} \; 2>/dev/null
echo "--- Unexpected listeners on common SSH ports ---"
ss -tlnp 2>/dev/null | awk 'NR==1 || /:22 |:222 |:2222 |:2200 |:22222 /'
echo "--- Non-package-owned sshd binary check ---"
SSHD_BIN=$(command -v sshd)
if command -v dpkg >/dev/null 2>&1; then dpkg -S "$SSHD_BIN" 2>/dev/null || echo "[!] sshd binary NOT owned by any package: $SSHD_BIN"; fi
if command -v rpm  >/dev/null 2>&1; then rpm -Vf "$SSHD_BIN" 2>/dev/null | grep -E 'sshd|ssh' || echo "rpm verify: no anomalies (or not rpm-managed)"; fi
echo "--- Recently created local accounts ---"
awk -F: '$3 >= 1000 {print $1}' /etc/passwd | while read -r u; do
  echo "$u: $(chage -l "$u" 2>/dev/null | grep 'Last password change')"
done
echo "=== Done. Treat any unexpected key, listener, or unsigned binary as a compromise indicator. ==="

Important: patching closes the vulnerability but does not evict an attacker who has already implanted keys or backdoors. Any host that was internet-exposed and unpatched before remediation requires a compromise assessment — key audits, listener review, and credential rotation at minimum.

Remediation

1. Patch immediately. Update OpenSSH to the fixed release published by your distribution for CVE-2026-123158. Pull the exact patched version number from your vendor's advisory (Debian Security Tracker, Ubuntu Security Notices, Red Hat Errata, SUSE security announcements) and the upstream OpenSSH release notes — verify the installed package version against the fixed version listed there, not just "latest."
2. Consult the official sources:
   • OpenSSH release notes: https://www.openssh.com/
   • The BleepingComputer report: https://www.bleepingcomputer.com/news/security/hackers-exploit-sshole-openssh-flaw-to-breach-linux-systems/
   • Your distribution's CVE-2026-123158 advisory page for exact fixed package versions.
3. Reduce exposure while patching: Restrict TCP/22 (and alternate SSH ports) to known management networks via host firewall (nftables/firewalld) and security groups. Where possible, place SSH behind a VPN, bastion host, or identity-aware proxy.
4. Assume compromise on exposed hosts. For any system that was internet-reachable before patching: audit all authorized_keys files, review authentication logs (/var/log/auth.log, /var/log/secure) for anomalous source IPs, check for rogue listeners, and verify the integrity of the sshd binary.
5. Rotate credentials and keys. Given the credential-theft component of this campaign: rotate passwords, SSH private keys (especially any used for automation or stored on compromised hosts), and any secrets that transited SSH sessions to affected systems. Revoke and reissue deploy keys in CI/CD systems.
6. Enforce key-based, MFA-backed access. Disable password authentication (PasswordAuthentication no) and root login (PermitRootLogin no) in sshd_config, and require hardware-backed or certificate-based authentication where feasible. This doesn't mitigate the RCE itself, but it sharply limits the value of stolen password material.
7. Hunt retroactively. Run the detection content above over at least the last 30 days of telemetry — exploitation predates public disclosure in nearly every campaign of this profile.
8. Track CISA KEV. If CVE-2026-123158 is added to the KEV catalog, treat the published remediation due date as your internal deadline regardless of sector.

The Bottom Line

SSH is the front door to your Linux estate, and SSHole hands attackers a master key. The response sequence matters: patch, then assume breach on anything that was exposed, then hunt and rotate. Organizations that only patch will close the vulnerability while leaving implanted keys and stolen credentials in play — and in this campaign, persistence is part of the standard playbook. Move now, and validate your work with evidence, not assumptions.

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub