CISA added an OpenSSH flaw nicknamed "SSHole," CVE-2026-123158, to its Known Exploited Vulnerabilities catalog on November 9, 2026. It lets an attacker log in over SSH to certain accounts that are supposed to have no password at all, including root, by sending a very long password. It only affects some Linux systems, but those are exactly the small, forgotten boxes that production companies, exhibit builders, manufacturers and engineering firms tend to have: routers, gateways, appliances and containers. Here's how to tell whether you're exposed and what to ask your IT provider.
What OpenSSH, CISA and researchers have said
OpenSSH released version 10.6p2 on November 5, 2026. Its release notes describe "a critical security workaround that affects Linux systems that use the musl libc and PAM disabled," fixing a "password authentication bypass that is exploitable through sshd." The OpenSSH team says it considers the root cause to be outside sshd, but that it is exploitable through sshd and can be avoided there.
According to SecurityWeek and Help Net Security, the problem shows up on musl-based Linux systems without PAM, such as Alpine Linux, and the researcher who found it lists OpenWrt, Buildroot and Yocto as other systems worth checking. Accounts that have only "*" in their password field, like root on Alpine or key-only users created without a password, can be logged into by sending a password longer than 256 bytes.
Exploitation started fast. Help Net Security reported that Previdian saw its first attempt less than nine hours after the CVE was published and confirmed root access on one of its own test systems. BleepingComputer reported that GreyNoise recorded 16 successful exploitation chains against its sensors, with attackers running reconnaissance, trying to read password hashes and SSH keys, and trying to add their own keys for persistent access. CISA added the flaw to the KEV catalog on November 9.
What we are not claiming: We don't know of any specific company, industry or Brotherly client that has been breached through this flaw. The attack counts above come from security firms' own sensors and test systems, not from real victims, and SecurityWeek reported that WatchTowr had seen only botnets and crypto miners using it so far. Most Windows PCs and most mainstream Linux servers are not affected. Whether any particular router, gateway or appliance is affected depends on how its maker built it, so check with the vendor rather than assuming.
Why this matters for production, exhibit and manufacturing shops
Many shops run small Linux devices nobody thinks of as "servers": a router or VPN box, an industrial gateway on a machine, a network storage box, a media or show-control appliance, a Docker container someone set up for a project. Many of these run lightweight Linux builds, and several of the build systems named in this flaw (OpenWrt, Buildroot, Yocto, Alpine) are common in exactly that kind of equipment. They often have SSH left on for the vendor or an installer, and they rarely get updates. If one of them is reachable from the internet with password logins on, it is the kind of target this flaw was made for.
What to do this week
- List what answers on SSH. Ask your IT provider to scan your office and shop networks, and your public IP addresses, for anything listening on SSH (usually port 22). Include routers, firewalls, NAS boxes, machine gateways, media servers and cloud containers.
- Take SSH off the internet. Nothing in a small business usually needs SSH open to the whole internet. Put it behind your VPN or limit it to known addresses.
- Update OpenSSH and restart it. For Alpine and other Linux systems you manage, install the patched OpenSSH package (10.6p2 or your distribution's fixed build) and restart the SSH service; the old process stays vulnerable until it restarts.
- Ask device vendors directly. For routers, gateways and appliances, ask the maker whether their firmware is affected by CVE-2026-123158 and when a fix is coming. Write down the answer.
- Turn off password logins where you can. If a system can't be updated yet, OpenSSH developer Damien Miller urged admins of affected systems to set
PasswordAuthentication noor disable SSH, as Help Net Security reported. Key-only logins avoid this attack. - Check the logs for the tell-tale sign. Look for "Accepted password" entries for root or other accounts that should never use a password, and for new entries in
authorized_keysfiles. If you find either and can't explain it, treat the device as compromised.
The takeaway for IT decision-makers
This flaw doesn't touch most of your PCs, but it targets the small Linux boxes that tend to sit unwatched at the edge of a shop network. Find what answers on SSH, take it off the internet, patch or switch to key-only logins, and get a written answer from each device vendor. If nobody can tell you what's running SSH on your network, that's the first thing to fix.
Sources
- OpenSSH: Release notes for OpenSSH 10.6p2 (Nov 5, 2026) (checked Nov 12, 2026)
- CISA: CISA Adds Four Known Exploited Vulnerabilities to Catalog (Nov 9, 2026)
- SecurityWeek: Hackers Exploiting 'SSHole' Authentication Bypass in OpenSSH
- Help Net Security: OpenSSH flaw exploited in the wild just hours after disclosure (Nov 6, 2026)
- BleepingComputer: Hackers exploit SSHole OpenSSH flaw to breach Linux systems