CVE-2026-123158 'sshole': OpenSSH Root Bypass on Alpine Linux Already Under Attack

CVE-2026-123158, nicknamed sshole, is an OpenSSH authentication bypass on Alpine Linux that lets an attacker log in as root on accounts with no password set, simply by submitting an extremely long password string. Disclosed in early November 2026, it was being exploited in the wild within hours, affecting any Alpine-based system using musl libc for SSH authentication.

Key takeaways

• CVE-2026-123158 (sshole) lets attackers bypass OpenSSH password authentication on Alpine Linux systems built on musl libc, gaining root on accounts configured with no password.
• The bypass is triggered by submitting an oversized password. BigGo reports a 257-byte string is enough to crack an affected server.
• OpenSSH shipped an emergency fix in version 10.6p2, but any Alpine container or VM image built before the patch stays exposed until it is rebuilt and redeployed, not just patched in place.
• Exploitation began within hours of public disclosure, which is faster than most scan-and-patch cycles can move.

What is CVE-2026-123158, the sshole vulnerability?

OpenSSH is the software that handles secure remote login on the vast majority of Linux and Unix systems. Alpine Linux is a minimal distribution widely used as the base image for containers, and it relies on musl libc instead of the more common glibc for its core C library functions.

Cycode's research and Orca Security's analysis both describe the same core problem: on musl-based OpenSSH builds, submitting an oversized password string during authentication causes the password check to fail in a way that grants access instead of denying it. On an account with no password configured, that means an unauthenticated attacker walks straight in as root.

Which systems are actually affected?

The vulnerability is specific to the combination of OpenSSH, musl libc, and password authentication on no-password accounts, which makes Alpine-based container images the primary exposure. Ethiack's writeup and SecurityCipher's advisory both flag that this condition is common in minimal container builds, where root accounts are frequently left without a password because interactive login was never expected to happen.

BleepingComputer's coverage makes the point bluntly: accounts that were deliberately configured with no password, assuming that meant login was disabled, are exactly the accounts this bug turns into an open door.

Why patching alone loses this race

Patching alone loses this race because the gap between disclosure and exploitation was measured in hours, not days. Help Net Security reported that attackers were actively exploiting CVE-2026-123158 in the wild shortly after it became public, long before most organizations had finished identifying which of their assets were even Alpine-based.

This isn't unusual behavior for internet-facing SSH services. Long-term honeynet research has documented that SSH endpoints face continuous, automated scanning traffic around the clock, which means a working exploit gets tested against exposed hosts almost immediately after it is published, with no window for a leisurely patch cycle.

For MSPs managing dozens or hundreds of client environments, the practical problem compounds. Alpine is everywhere in containerized infrastructure precisely because it's small and fast to deploy, which also means it's easy to lose track of. An image pulled six months ago, still running in a client's Kubernetes cluster, doesn't show up on a routine OS inventory the way a named Linux distribution would.

What should MSSPs do right now?

MSSPs should treat CVE-2026-123158 as an inventory problem first and a patch problem second, because you cannot patch what you haven't found. Concrete steps:

• Inventory Alpine-based assets. Search container registries, base images, and running workloads for Alpine Linux, not just named OS installs.
• Upgrade to OpenSSH 10.6p2 or later on every affected host, and rebuild container images rather than patching binaries inside running containers.
• Audit accounts for empty passwords. Any account with password authentication enabled and no password set should either get a password, get disabled, or move to key-based authentication.
• Disable password authentication where possible in favor of SSH keys or certificate-based auth, which removes the attack surface entirely regardless of patch status.
• Monitor authentication telemetry for anomalous root logins on affected hosts while the patch rollout catches up across the fleet.

Vijilan Security's approach to this kind of disclosure starts with the assumption that some fraction of the client base will still be exposed after the patch is announced, because that's what the exploitation timeline actually looks like.

Where a SOC catches what the patch cycle misses

A SOC catches what the patch cycle misses by watching authentication behavior instead of waiting for a scan to confirm a version number. With exploitation beginning hours after disclosure, patching is a race MSPs will sometimes lose, no matter how disciplined the maintenance window. The control that actually holds the line is continuous monitoring of authentication telemetry, flagging an unauthenticated root session the moment it appears and isolating that host automatically, rather than waiting for the next vulnerability scan to flag the unpatched version.

This is the gap between tooling and a Global SOC that acts on it. ThreatRespond™ delivers managed XDR across a client's existing stack, correlating authentication anomalies across identity, endpoint, and network signals rather than treating SSH logs in isolation. For environments running CrowdStrike Falcon, ThreatDefend™ and Falcon Guardian coverage extend that visibility into the container and workload layer where Alpine images actually live. Managed identity threat detection and response is built specifically to catch the pattern this vulnerability produces: a root session with no prior authentication history, appearing on a host that should not have one.

For partners running their own tooling, co-managed SIEM and 24/7 SOC monitoring mean that anomaly detection doesn't depend on every client finishing their patch rollout on the same day. And for MSPs and MSSPs building this into a client offering, we never compete with our partners for their clients, the detection and containment work happens under your relationship, white-labeled where it needs to be.

Next step

If your client base includes Alpine-based containers and you need authentication anomalies caught in real time rather than discovered on the next scan, see 24/7 SOC monitoring or talk to us about a SOC built for MSPs.