SSHole OpenSSH Flaw: Check Edge Boxes, Not the Banner
A bug fixed by OpenSSH on 5 November lets an attacker log in to some musl-based Linux systems with one very long password. The fix for servers is a package update, but for gateways and controllers inside smart buildings and city networks the owner’s fastest protection is a setting and a firewall rule, not the vendor’s next firmware
This post argues that the SSHole flaw in OpenSSH is a test of whether a city or building owner knows which Linux boxes on its networks answer SSH and accept passwords, because the owner can close the hole on its own side this week, while version banners, CVE-based scanners and vendor firmware will all lag. CERT-In rated the flaw critical on 6 November.[1] Alpine Linux, the distribution most clearly affected, put it bluntly: anyone who can reach the SSH port can log in without knowing a password, in one connection, every time.[3]
If you run a building management system, an ICCC or a plant-room network, this is not a distant server story. OpenSSH is the remote-login software that lets engineers reach a Linux machine over the network. Data-centre servers will mostly be patched within days. The harder cases are the small Linux devices in an ICCC field cabinet or a building’s plant room, which nobody logs into until something goes wrong.
One password between 257 and 1,024 bytes opens accounts that were never meant to take a password
The OpenSSH team released version 10.6p2 on 5 November with what it called a critical security workaround for Linux systems that use the musl C library with PAM, the usual login framework, switched off.[2] Musl is a small toolkit that Alpine Linux and some embedded systems use to run basic C code; PAM is the login gatekeeper most big Linux servers switch on by default. The bug was reported by Özgün Kültekin of Wakefield, and the team says it shipped the fix the day after it learned of the problem, because AI tools are now rediscovering bugs quickly and long embargoes mostly help attackers.[2][5]
The mechanism is simple. Accounts that should never accept a password, such as root on recent Alpine releases or a user who logs in only with a key, store a single asterisk in the password field. When sshd — the OpenSSH login service — runs without PAM, it hashes each password attempt and compares the result with that field. Musl’s hashing function returns an asterisk as its error signal when the input is longer than 256 bytes, so a long enough password produces a “hash” that matches.[3][6] The attacker also needs one other active account with a real password on the same machine, because sshd borrows that account’s salt.[3][6] The flaw is now tracked as CVE-2026-123158, with a CVSS score of 8.1.[4][5] The researcher’s own write-up says the problem has existed since 2016,[7] and Alpine says every release it checked, 3.16 to 3.24 and edge, was affected.[3]
Five conditions decide exposure, and only two of them can be seen from the network
Most systems running OpenSSH are not affected. Linux systems built on glibc, systems that check passwords through PAM, and the Dropbear SSH server are outside the bug.[6][7] The table below sets out what has to be true, using the conditions published by Alpine and Check Point, and who can actually confirm each one.
| Condition for exposure | Typical example | Visible from the network? | Who can confirm it |
|---|---|---|---|
| sshd runs on musl-based Linux without PAM [3][6] | Alpine’s default openssh-server package [3] | No | The device maker, or whoever administers the system |
| Password login is switched on [3][6] | OpenSSH’s default, unless changed [3] | Yes, from the login methods the server offers [6] | The owner, with a simple network check |
| An account has * as its password field [3] | root on Alpine 3.16 onwards; key-only users; the alpine user on official tiny-cloud images [3] | No | Needs a check on the device itself [6] |
| Another active account has a real SHA-256 or SHA-512 password hash [3][6] | A service or console account with a set password [3] | No | Needs a check on the device itself [6] |
| The SSH port can be reached by the attacker [3] | Port 22 open to the internet or to a flat internal network | Yes | The owner, from its firewall rules and a scan |
The practical point is in the last column. An owner can find out from its own network which devices offer SSH and accept passwords. Whether a vendor’s firmware is built on musl without PAM, and whether it carries the asterisk accounts, is something only the device maker can confirm for certain.
The version number in the banner can mislead in both directions
When you connect to an SSH server, it usually greets you with a short version string — the “banner”. Facility teams and scanners often treat that string as a verdict. On this bug, they shouldn’t. Check Point notes that Alpine’s fixed packages keep older version numbers, such as 10.3_p1-r2 on Alpine 3.24, so a patched host can look vulnerable.[6] The opposite is also true: an OpenSSH version earlier than 10.6p2 on a glibc system with PAM is not exposed to this bug at all, even though CERT-In’s note lists all versions before 10.6p2 and addresses “all organizations and individuals using OpenSSH”.[1][6] And because no CVE number existed on 5 November, the day the details went public, tools that work from CVE lists may not have flagged anything in the first day.[3][6] So a scanner report on this flaw will overcount and undercount at once. The useful question for a device on the network is narrower: does it accept password logins over SSH, and can anyone outside the management network reach it?
Building and city networks hold exactly the kind of small Linux box this bug reaches
The researcher lists OpenWrt, Buildroot and Yocto alongside Alpine as musl-based systems that can be affected.[7] Those are toolkits for building embedded Linux firmware — the software inside many gateways, controllers and edge boxes that sit between a sensor network and the control room. That does not mean any particular product is vulnerable. A product may use Dropbear, PAM or glibc instead, and only the maker can say which.
The exposure worth worrying about is the same one behind the recent attacks on supermarket refrigeration in Europe. Singapore’s Cyber Security Agency, in a 6 November advisory, named building management systems among the OT systems whose remote access, often opened for vendors and service providers, can be abused, and asked owners to keep an inventory of internet-reachable management interfaces and remove the ones that don’t need to be there.[8] Kumar Sokka of Acre Security told Euronews that the same kind of small, internet-connected controller used to warm up those fridges “also runs the doors, the access-control readers, the cameras, the alarms, the lighting and the heating and ventilation in most modern buildings”.[9]
A hypothetical example shows how it could play out. Suppose a smart city’s traffic junctions each have an edge gateway that the system integrator reaches over SSH for support, with a service account that has a password and a vendor account that uses only a key. If that firmware happened to run OpenSSH on musl without PAM, the key-only account would accept a 300-character password from anyone who could reach port 22. Nobody at the ICCC would see a failed-login alarm, because the login would succeed. This is an illustration, not a known case. CERT-In’s own Cyber Security Guidelines for Smart City Infrastructure already ask for most of what is needed here: default factory settings changed before deployment, device access limited to authorised users and devices, and network, security and application logs forwarded to a central server.[10] SSHole is a good week to find out whether those lines were followed.
Owners can close the hole this week by listing SSH boxes, switching off passwords and writing three questions to each vendor
Start with the boxes that answer on the SSH port. List anything reachable from the internet first, then walk the ICCC, BMS and field networks. Note the banner and whether the server offers password login; Check Point says both are visible before login.[6] Close internet exposure first, as Singapore’s CSA recommends.[8] Where you control the configuration — servers and appliances you administer — update OpenSSH or set PasswordAuthentication to no, then restart sshd. Alpine and CERT-FR both stress that upgrading the package does not replace the running daemon, so the restart is part of the fix.[3][4] Turning off password logins is the owner’s quickest move on this flaw, and it does not need a vendor firmware drop.
For the devices you don’t administer yourself, ask each vendor three questions in writing. Does the firmware run OpenSSH on musl with PAM off? Is password login enabled by default? Which firmware release fixes it, and when? This is the same request we suggested for the GoAhead web server flaws, and it fits the CERT-In OEM guidelines turned into contract clauses. Then search the logs for a password login to a key-only account. Alpine and CERT-FR suggest looking for “Accepted password for” against accounts that have no password, such as root or a key-only user.[3][4] If a login can’t be ruled out, Alpine’s advice is to treat the machine as compromised.[3] Finally, write the patch window into the maintenance contract. The OpenSSH team now plans more frequent releases rather than batching fixes,[2] so the question of who patches cameras and BMS will keep coming back. Put the answer, and a time limit, in the AMC.
Planning a command and control centre? Talk to Trisim Global Solutions.
Trisim’s view: for SSHole, the quickest protection is a setting the owner controls, so city and building owners should switch off password logins and close exposed SSH ports now rather than wait for each vendor’s firmware.
Sources
- CERT-In, CERT-In Vulnerability Note CIVN-2026-0542: Authentication Bypass Vulnerability in OpenSSH, 6 November 2026
- OpenSSH, OpenSSH 10.6p2 release notes, 5 November 2026
- Alpine Linux, Security advisory: openssh-server password authentication bypass, 5 November 2026
- CERT-FR, [MàJ] Vulnérabilité dans OpenSSH, CERTFR-2026-ALE-015 (in French), 5 November 2026, updated 6 November 2026
- SecurityWeek, OpenSSH Rushes Patches for ‘SSHole’ Authentication Bypass, 6 November 2026
- Check Point Software, A Critical SSH Password Bypass Hits musl-Based Linux, 5 November 2026
- Özgün Kültekin, Wakefield, *sshole: researcher’s write-up of the flaw, undated, accessed 9 November 2026
- Cyber Security Agency of Singapore, Advisory on Cyberattacks Targeting Remotely Accessible Operational Technology Control Systems (AD-2026-014), 6 November 2026
- Euronews, Hackers probed Europe’s fridge systems weeks before cyberattacks. Who did it and what could they target next?, 7 November 2026
- CERT-In, Cyber Security Guidelines for Smart City Infrastructure (PDF), 2025