SSHole (CVE-2026-123158): Blue Team Detection & Response

Executive Summary on SSHole

SSHole is a logic flaw in OpenSSH when built against musl libc and run without PAM. An unauthenticated attacker can obtain a shell on a key-only account by submitting any password between 257 and 1024 bytes.

The activity is difficult to detect because a successful exploit produces an ordinary password authentication success. There is no malware, no unusual network behaviour, and no distinctive artefact left by the authentication itself.

SSHole Affected and Fixed Versions

Alpine can update the package while the old sshd process continues to run. Checking the package version alone is not enough; the service must be restarted for the fix to take effect.

Vulnerability Characteristics of SSHole

Detection Challenges on SSHole

• Successful exploitation looks identical to a legitimate password login in the logs.
• No unusual protocol patterns or payloads are present.
• The useful signals are contextual rather than signature-based.
• A package update without a service restart can leave the system exposed while appearing patched.

What to Monitor

Technical Detection Guidance on SSHole

Logging

LogLevel VERBOSE

LogLevel VERBOSE

Send authentication logs to a central system. Local logs alone cannot support reliable detection or investigation.

Typical entries:

Failed password for <user> from <source> port <port> ssh2
Accepted password for <user> from <source> port <port> ssh2

Failed password for <user> from <source> port <port> ssh2
Accepted password for <user> from <source> port <port> ssh2

Primary Detection

Raise an alert on any successful password authentication for an account whose shadow field is * or !.

This is the highest-confidence detection, provided the organisation knows which accounts are key-only.

Supporting Detection

Failed password for <user> from <source>
Accepted password for <user> from <source>
(within 15–30 seconds)

Failed password for <user> from <source>
Accepted password for <user> from <source>
(within 15–30 seconds)

Simple Hunting Command

grep -E 'sshd\[[0-9]+\]' /var/log/messages | \
  grep -E 'Failed password for|Accepted password for'

grep -E 'sshd\[[0-9]+\]' /var/log/messages | \
  grep -E 'Failed password for|Accepted password for'

Indicators and Hunting Evidence

Classic IOCs (hashes, domains, network signatures) have little value here.

Hunting focus

• Password logins on Alpine systems that normally only allow public-key authentication
• Accounts that have never used password authentication before
• Privilege escalation or persistence actions following such logins

How SOC Teams Handle This Activity in Practice

SOC / MSSP Prioritisation

In a SOC or managed detection environment, treat successful password authentication on a key-only account as a high-priority alert. The authentication method contradicts the account’s intended security configuration.

Analysts typically examine:

• The source address
• Whether a failed password attempt occurred shortly beforehand
• Recent authentication history for the account
• Any subsequent activity on the host (new SSH keys, privilege escalation, new accounts, etc.)

When reliable account configuration data is available, SOC teams escalate these events promptly. Without that context, they may classify the activity as a lower-priority authentication anomaly or detect it only during threat hunting.

Information Normally Included in an Escalation

A typical escalation or internal ticket for this activity would contain:

• Timestamp of the successful password authentication
• Username and affected host
• Source IP address
• Confirmation (where available) that the account is configured as key-only
• Note of any preceding failed password attempt from the same source
• Request to review the host for post-authentication activity

The emphasis is on the contextual mismatch rather than on any unusual characteristic of the authentication event itself.

Appearance in Common Tools

Splunk
Usually implemented with a lookup against a list of key-only accounts. Without that lookup, only broader searches for password authentication events are practical, and these tend to be noisy.

Elastic / Kibana
Requires enrichment or a maintained list of key-only accounts to achieve useful precision. Simple searches for “Accepted password” generate high volume and limited signal.

Microsoft Sentinel
Same dependency on account metadata. Once the core condition is met, entity mapping (Account, Host, IP) supports investigation, but the quality of the alert still rests on knowing which accounts should not accept passwords.

In all cases the limiting factor is the same: the detection is only as strong as the organisation’s knowledge of intended authentication methods for each account.

Hardening and Response

Preferred controls

1. Disable password authentication (PasswordAuthentication no).
2. If password authentication is required, use the PAM-enabled OpenSSH package.
3. Restart sshd after any OpenSSH package update.
4. Keep an accurate list of key-only accounts and treat password success against them as high priority.
5. Restrict root login and remove unused accounts.

If exploitation is suspected

• Preserve authentication logs immediately.
• Check authorized_keys, account files, privilege escalation configuration, scheduled tasks, and temporary directories.
• Rebuild containers from known-good images rather than cleaning them in place.
• Rotate any credentials that were accessible from the host.

Defensive Priorities

The useful signal is not that the authentication looks malicious, but that it occurred on an account that should not accept passwords. Without accurate knowledge of account configuration, detection capability is significantly reduced.