OpenSSH *sshole: How a 2016 Patch Created a 2026 Cloud Root Takeover Risk
Executive Summary
Executive Summary A newly disclosed authentication bypass vulnerability, dubbed sshole, affects OpenSSH servers running on musl-based Linux distributions such as Alpine Linux, OpenWrt, Buildroot, and Yocto. Discovered by security researcher Ozgun Kultekin and disclosed in November 2026, the flaw exploits a logic error introduced in a 2016 OpenSSH patch for CVE-2016-6210. When an attacker submits an oversized password exceeding musl's 256-byte crypt() limit, the library returns an asterisk (), which OpenSSH then incorrectly matches against accounts whose password field is also set to * to disable logins—granting unauthorized access. Alpine Linux's official AWS and Azure cloud images are particularly exposed, as the default 'alpine' account carries passwordless doas privileges, enabling full root escalation.
This vulnerability is especially urgent for cloud-native and container-centric organizations that rely heavily on Alpine Linux as a minimal base image. The flaw has silently existed since 2016, underscoring how legacy patch decisions in foundational infrastructure components can create long-lived, high-impact attack surfaces. With cloud workloads proliferating across hybrid environments, SSH authentication integrity is a critical zero trust dependency.
Why This Matters Now
Why This Matters NowAlpine Linux is one of the most widely used base images in containerized and cloud-native environments, including Kubernetes clusters and serverless platforms. With SSH password authentication enabled by default and the default 'alpine' account carrying root-equivalent privileges on AWS and Azure images, this flaw presents an immediate, low-complexity path to full cloud workload compromise—demanding urgent patching and SSH hardening across all musl-based deployments.
Attack Path Analysis
Attack Path AnalysisAn attacker targeting musl-based Linux systems (e.g., Alpine Linux) exploits CVE *sshole by submitting an oversized password over SSH, causing OpenSSH's password comparison logic to match a stored asterisk hash and granting unauthorized access to a locked account. Once initial access is achieved on the default 'alpine' account with passwordless doas privileges, the attacker escalates to root, then pivots laterally across internal workloads, establishes command-and-control channels, and ultimately exfiltrates sensitive data or deploys destructive payloads.
Kill Chain Progression
Kill Chain ProgressionThis analysis maps confirmed threat intelligence to the full cloud kill chain to show where defensive gaps would emerge as an attack progresses.
Initial Compromise
Description
DescriptionThe attacker identifies an internet-exposed SSH service running on a musl-based Linux system (Alpine Linux AWS/Azure cloud image) with password authentication enabled and the default 'alpine' account configured with an asterisk (*) password hash. By submitting a password exceeding 256 bytes, musl's crypt() returns '*', which OpenSSH's patched 2016 logic incorrectly matches against the stored '*', granting unauthenticated SSH access without a valid credential. The attack requires no prior credentials and exploits a logic flaw in OpenSSH on musl-based systems with PAM disabled.
Related CVEs
Related CVEsCVE-2025-26465
CVSS 6.8A logic flaw in OpenSSH's password verification on musl-based Linux systems allows an attacker to authenticate to accounts with password authentication disabled (asterisk in /etc/shadow) by submitting an oversized password, because musl's crypt() returns '*' on failure, matching the stored '*' hash.
Affected Products:
OpenBSD OpenSSH – < 10.6p2
Alpine Linux openssh-server – < 10.6p2-r0
Exploit Status:
proof of conceptCVE-2016-6210
CVSS 5.9OpenSSH before 7.3 allows remote attackers to obtain sensitive information via a timing side-channel attack, disclosing valid usernames through differences in authentication response times for existing versus non-existing accounts.
Affected Products:
OpenBSD OpenSSH – < 7.3
Exploit Status:
no public exploit
MITRE ATT&CK® Techniques
MITRE ATT&CK® TechniquesValid Accounts
Brute Force
Brute Force: Password Guessing
Remote Services: SSH
Abuse Elevation Control Mechanism
Modify Authentication Process
Exploit Public-Facing Application
Account Discovery
Potential Compliance Exposure
Potential Compliance ExposureMapping incident impact across multiple compliance frameworks.
PCI DSS 4.0 – User Identification and Authentication Management
Control ID: Requirement 8.2 / 8.6
NYDFS 23 NYCRR 500 – Access Privileges and Multi-Factor Authentication
Control ID: Section 500.7 / 500.12
DORA (Digital Operational Resilience Act) – ICT Security — Access Control and Vulnerability Management
Control ID: Article 9 / Article 10
CISA Zero Trust Maturity Model 2.0 – Least Privilege Access and Continuous Authentication Validation
Control ID: Identity Pillar — Authentication / Device Pillar — Configuration Management
NIS2 Directive – Vulnerability Handling, Patch Management, and Access Control
Control ID: Article 21 — Security of Network and Information Systems
ISO/IEC 27001:2022 – Privileged Access Rights, Secure Authentication, and Management of Technical Vulnerabilities
Control ID: Annex A 8.2 / 8.5 / 8.8
Sector Implications
Sector ImplicationsIndustry-specific impact of the vulnerabilities, including operational, regulatory, and cloud security risks.
Information Technology/IT
Authentication bypass via OpenSSH on musl-based Linux directly threatens IT infrastructure; Zero Trust Segmentation and Privilege Escalation controls are critical to contain lateral movement after unauthorized root access.
Computer/Network Security
The CVE-2016-6210-rooted *sshole flaw exposes security operations running Alpine Linux on AWS/Azure; validated East-West Traffic Security and anomaly detection capabilities are essential to identify unauthorized SSH password logins.
Cloud Computing
Alpine Linux default AWS and Azure cloud images carry a vulnerable 'alpine' account with passwordless doas privileges, enabling root escalation; Multicloud Visibility and Egress Security controls per NIST.800-53.SC-7 are urgently needed.
Financial Services
Financial platforms leveraging musl-based Linux containers face authentication bypass risk; PCI.4.0.7.2.4 and HIPAA.164.308(a)(3) compliance gaps emerge when privilege escalation bypasses password-disabled account controls via oversized password injection.
Sources
Sources- OpenSSH flaw lets attackers log into password-disabled Linux accountshttps://www.bleepingcomputer.com/news/security/openssh-flaw-lets-attackers-log-into-password-disabled-linux-accounts/Verified
- OpenSSH 10.6p2 Release Noteshttps://www.openssh.com/txt/release-10.6p2Verified
- SSHole Vulnerability Research by Ozgun Kultekinhttps://sshhole.com/Verified
- NVD Detail: CVE-2025-26465https://nvd.nist.gov/vuln/detail/CVE-2025-26465Verified
- NVD Detail: CVE-2016-6210https://nvd.nist.gov/vuln/detail/CVE-2016-6210Verified
- Full Disclosure: OpenSSH Username Enumeration (CVE-2016-6210)https://seclists.org/fulldisclosure/2016/Jul/51Verified
Frequently Asked Questions
Frequently Asked QuestionsCloud Native Security Fabric Mitigations and ControlsCNSF
Based on the attack progression modeled above, these are the defensive controls that would constrain each stage.
Aviatrix Zero Trust CNSF is directly relevant here because the attacker's progression — from exploiting an exposed SSH service on Alpine Linux through lateral movement and exfiltration — depended entirely on unrestricted network reachability and absent east-west controls. Enforcing Zero Trust segmentation and controlled egress policies would likely have reduced the attacker's blast radius and constrained their ability to pivot across internal workloads and establish outbound channels.
Control: Cloud Native Security Fabric (CNSF)
Mitigation: Distributed inline enforcement at the network perimeter could likely reduce the reachability of the exposed SSH service by constraining which external sources are permitted to initiate connections to cloud-hosted Alpine Linux workloads, making opportunistic exploitation of this flaw considerably harder to achieve at scale.
Control: Zero Trust Segmentation
Mitigation: Identity-aware segmentation policies enforcing least-privilege access scopes could likely constrain what the compromised 'alpine' account is permitted to reach within the environment, reducing the practical value of root escalation even if the privilege elevation itself occurs on the host.
Control: East-West Traffic Security
Mitigation: East-west traffic enforcement between internal workloads could likely constrain the attacker's ability to reach adjacent hosts and services by segmenting VPC-internal flows, reducing the number of reachable pivot targets even when the attacker holds valid credentials or tokens obtained from the initial host.
Control: Multicloud Visibility & Control
Mitigation: Multicloud network visibility could likely surface anomalous outbound connection patterns originating from the compromised Alpine Linux host, giving security teams the observability needed to identify C2 channel establishment early and reduce the window during which the attacker maintains undetected persistent access.
Control: Egress Security & Policy Enforcement
Mitigation: Controlled egress enforcement with FQDN-based policy could likely reduce the attacker's ability to transfer data to unauthorized external destinations by restricting outbound connections from cloud workloads to explicitly approved endpoints, narrowing the viable exfiltration paths even when the attacker holds root-level access.
If prior CNSF controls constrained lateral movement and egress paths, the attacker's remaining impact would likely be scoped to the initially compromised host rather than propagating across the broader cloud environment, reducing the risk of ransomware spreading to adjacent workloads or build pipeline artifacts being systematically compromised at scale.
Impact at a Glance
Affected Business Functions
- Remote Server Administration and SSH Access Management
- Cloud Infrastructure Operations (AWS/Azure Alpine Images)
- Privileged Access and Identity Management
- Container and Embedded Device Security (OpenWrt, Buildroot, Yocto)
Estimated downtime: 1 days
Estimated loss: N/A
Accounts with password authentication disabled on musl-based Linux systems are subject to unauthorized remote login. The Alpine Linux default 'alpine' account in official AWS and Azure cloud images carries passwordless 'doas' (sudo-equivalent) privileges, meaning successful exploitation grants root-level access. This exposes all data hosted on affected cloud instances, including application secrets, credentials, configuration files, and any customer or business data stored on those systems. Scope is broad across DevOps, IoT, and cloud-native environments using Alpine Linux.
Recommended Actions
Key Takeaways & Next Steps
- • Apply Zero Trust Segmentation (ZTMM.Network, NIST.800-53.AC-6) to enforce least-privilege identity-based access policies that remove passwordless doas/sudo privileges from default accounts and isolate SSH-accessible workloads from sensitive internal resources.
- • Deploy East-West Traffic Security controls to inspect and restrict workload-to-workload communication within cloud VPCs and container environments, preventing lateral movement from a compromised Alpine Linux host to adjacent services or build pipelines.
- • Enforce Egress Security & Policy Enforcement with FQDN filtering and outbound traffic controls (ZTMM.Data, NIST.CSF.PR.DS-5) to detect and block unauthorized data transfers and reverse-shell C2 channels originating from cloud-hosted musl-based Linux systems.
- • Enable Multicloud Visibility & Control (ZTMM.CrossCutting.Visibility, NIST.800-53.AU-6) to baseline SSH authentication patterns and generate alerts on anomalous successful password logins for accounts configured with asterisk (*) password hashes, mapping to the log inspection guidance in the advisory.
- • Deploy Inline IPS (Suricata) with SSH exploit signatures and oversized-payload detection rules (NIST.800-53.SI-4, PCI.4.0.6.4.1) at network ingress points to identify and block exploitation attempts targeting the *sshole authentication bypass pattern before they reach vulnerable OpenSSH instances.
