SSHole break-ins confirmed on Alpine: patch OpenSSH, restart sshd, then check for planted SSH keys

We flagged the OpenSSH “SSHole” bug on Monday as a one-connection login on Alpine Linux. Since then, several security firms have confirmed real break-ins, and CISA added it to its exploited list on November 9 with a Thursday, November 12 deadline. Our Monday story has the full background.

The new part is what intruders do once inside. They try to add their own SSH keys, which survive the patch.

Patching SSHole closes the door. It does not remove an SSH key an attacker already added. Check authorized_keys on every Alpine host.

The 5-Minute Cyber Brief

Don’t Miss the Policy Changes That Affect Security Decisions

Get the key CISA actions, new regulations, guidance, and risk shifts in a quick daily brief.

Email addressSend me tomorrow’s brief

By subscribing you agree to our Privacy Policy.

Free. Weekday mornings. 5 minutes or less.

Attackers are now logging in through SSHole

GreyNoise recorded the first successful exploitation on November 7 at 00:46 UTC, about 40 hours after OpenSSH 10.6p2 shipped, according to BleepingComputer. It logged 16 successful exploitation chains from six source addresses. The intruders ran system and container reconnaissance, queried cloud metadata services, tried to read password hashes and root SSH keys, and tried to edit authorized_keys files.

One attacker got root and installed TAC Agent, a Python remote-control implant, which then failed to reach its server. Ars Technica reports that GreyNoise tracks the group as GT10. watchTowr has seen botnet and cryptomining activity, and Previdian counted 20 attempts from 13 addresses in nine countries.

• SANS ISC honeypots logged the first all-“A” exploit passwords on November 5 and 713 long-password attempts on November 6.
• CISA KEV: CVE-2026-123158 added November 9, 2026, due November 12, forensic triage flagged.
• Fix: OpenSSH 10.6p2 or your distribution’s package. Alpine shipped fixed openssh packages for every branch back to 3.16.

Alpine and other musl hosts that still accept SSH passwords

Alpine sits in container base images, small cloud VMs, routers and appliances, so it is easy to miss when someone asks “do we run Alpine?” Any of those that runs sshd with password logins on and has an account whose password field is an asterisk is in scope.

A key planted in authorized_keys keeps working after the upgrade and the restart. Hosts that were reachable from the internet between November 5 and your patch need a check, not just a version bump.

Patch, restart sshd, then look for planted keys

• On Alpine, run apk upgrade -U -a, then restart sshd (rc-service sshd restart). Upgrading the package does not replace the daemon already running.
• If you cannot patch today, set PasswordAuthentication no (including inside Match blocks), run sshd -t, restart, and confirm with sshd -T.
• Check every authorized_keys file, including root’s, for keys you did not add.
• Search the auth log for “Accepted password” lines on accounts that should never accept a password, such as root, alpine or service users.
• If you find a login or a key you cannot explain, rebuild the host from a known-good image and rotate the SSH keys, cloud credentials and secrets it could reach.

Details

• CVE-2026-123158 (SSHole): OpenSSH sshd before 10.6p2 on musl libc without PAM; an oversized password makes the hash check return “*”, which matches accounts with a disabled password. CVSS 8.1.
• KEV: added November 9, 2026; federal due date November 12, 2026; forensic triage flagged.
• Observed post-exploitation (GreyNoise via BleepingComputer): container and cloud-metadata reconnaissance, attempts to read /etc/shadow and root keys, authorized_keys changes, TAC Agent implant with a startup service; C2 tac.vpnla[.]org.
• Fixed: OpenSSH 10.6p2; Alpine openssh packages for 3.16 and later (version strings may not show 10.6p2, so check the package against Alpine’s advisory).

Hunt / verify

• grep “Accepted password” in /var/log/messages or your log pipeline for accounts with “*” in /etc/shadow.
• List authorized_keys files on each host and compare them with your key inventory or config management.
• Look for new startup services, Python installed on hosts that never had it, and processes talking to tac.vpnla[.]org.
• Review cloud audit logs for metadata-credential use from these hosts since November 5.

Source: BleepingComputer: SSHole exploitation; Alpine advisory

Sources

• BleepingComputer: Hackers exploit SSHole OpenSSH flaw to breach Linux systems
• Ars Technica: Vulnerability that lets hackers SSH into Linux devices is under active exploitation
• SANS ISC: Scans for Sshole Vulnerability (CVE-2026-123158)
• CISA: CISA Adds Four Known Exploited Vulnerabilities to Catalog (November 9, 2026)
• Alpine Linux: OpenSSH password authentication bypass
• OpenSSH release notes (10.6p2)
• NVD: CVE-2026-123158

George Bailey

George Bailey is the byline of the CyberExperts editorial desk, the team behind the CyberExperts Daily Brief. The desk covers vulnerabilities, breaches and security news from vendor advisories, CISA alerts and other primary sources, and links those sources in every story. Questions or corrections: [email protected].