Vulnerability advisoryFri, 6 Nov 2026
OpenSSH authentication bypass: from Alpine bastions to network and IoT gateways
CVE-2026-123158 affects specific OpenSSH servers using musl, without PAM, when password authentication is allowed. Inventory bastions, network firmware and IoT gateways, update the applicable branch and restart sshd.
Article
MITRE published CVE-2026-123158 (*sshole) on 5 November 2026 with a CVSS v3.1 base score of 8.1. An attacker who can reach an OpenSSH server meeting the conditions may log in to an existing account without knowing its password. OpenSSH Portable 10.6p2 was released the same day; Alpine provides patched packages for its branches. The CISA CVE enrichment record identifies public proof-of-concept code; exploitation in the wild has not been confirmed.
Where is Alpine Linux deployed?
Alpine uses musl libc and BusyBox. Its small footprint makes it suitable for container bases and cloud virtual machines, and it can be embedded in switches and enterprise routers. Inventory branch networking equipment, industrial and IoT gateways, and remote maintenance devices. Check two distinct layers: management SSH in device firmware or the host OS, and separately started SSH services inside Alpine-based maintenance containers. Versions, network reachability and update paths may differ.
Network equipment: Start with management interfaces and remote-maintenance features on routers, switches and gateways. Standard OpenWrt uses Dropbear by default; assess this specific vulnerability only when OpenSSH Server is installed separately or integrated by a vendor.
IoT and industrial devices: Identify remotely accessible embedded Linux gateways and controllers. Check model, firmware, vendor security advisories and software bill of materials (SBOM). If component details are unavailable, ask the vendor to confirm the SSH implementation, version, PAM configuration and patched release. Do not install a generic package directly on an appliance.
Cloud and containers: Inventory bastions, Alpine tiny-cloud images, remote build hosts and containers that actually run SSH. An Alpine-based container without sshd cannot itself expose this path; assess its host separately. Alpine says some tiny-cloud images permit the alpine account to elevate with doas. If later configuration creates a qualifying password hash, access through that account could extend to root.
When can the flaw be exploited?
Upstream OpenSSH Portable releases before 10.6p2 without a backported fix are affected when Linux uses musl libc, sshd does not use PAM and the connection permits password authentication. Alpine also requires SSH reachability, knowledge of a target account whose password field is an asterisk, and at least one other local account using a SHA-256 crypt ($5$) or SHA-512 crypt ($6$) hash. The described path does not apply to a properly PAM-enabled configuration, a connection with password authentication disabled, or a different SSH server implementation. Disabling direct root password login does not prevent escalation through another account with sudo or doas privileges.
- 01
Management SSH is reachable
The management service is reachable from the Internet, maintenance networks or outsourced connections
- 02
Authentication bypass
An sshd not using PAM misinterprets a musl error return as a matching result
- 03
Sign in as an existing account
Access to devices, data or connected systems depends on the account’s privileges
Recommended actions: from the external perimeter to core systems
- 01
Inventory
Trace public addresses, VPNs, management networks and outsourced connections to devices and containers. Check listening processes, firmware and package versions, C library, PAM, effective SSH configuration and account status. Do not export password hashes to tickets or logs.
See what to doResources: 1
TWISA member solutions
Inventory
Trace public addresses, VPNs, management networks and outsourced connections to devices and containers. Check listening processes, firmware and package versions, C library, PAM, effective SSH configuration and account status. Do not export password hashes to tickets or logs.
- 02
Restrict access first
Confirm key-based login and a backup management path work; keep the current session open. If patching is delayed, set PasswordAuthentication no as directed by the vendor, check Match overrides, validate the configuration, restart sshd and retest from a separate session. Restrict management access to trusted sources through a VPN or management network.
See what to doResources: 3
TWISA member solutions
Restrict access first
Applicable offer: 眾至資訊’s 新世代防火牆NU-6000 can be deployed on the relevant network path to restrict sources and segment networks. Configure and verify it for the environment, and still update the affected product. The TWISA offer runs through 2026/12/31: code TWISA2026_ShareTech, 5% discount, one year of AI IPS and AI Sandstorm protection, and a 30-month hardware warranty.
- 03
Patch each branch
Update upstream to 10.6p2 or use the distribution backport. Alpine fixes include edge 10.6_p2-r0, 3.24 10.3_p1-r2, 3.23 10.2_p1-r1, 3.22 10.0_p1-r11 and 3.21 9.9_p2-r1. Backports are also available for 3.16–3.20; consult Alpine and plan to retire unsupported branches. Restart sshd after updating, rebuild and replace containers, and use the vendor firmware process for appliances.
View guidanceResources: 1
Response guidance
Patch each branch
Update upstream to 10.6p2 or use the distribution backport. Alpine fixes include edge 10.6_p2-r0, 3.24 10.3_p1-r2, 3.23 10.2_p1-r1, 3.22 10.0_p1-r11 and 3.21 9.9_p2-r1. Backports are also available for 3.16–3.20; consult Alpine and plan to retire unsupported branches. Restart sshd after updating, rebuild and replace containers, and use the vendor firmware process for appliances.
- 04
Investigate and retest
Review Accepted password records for accounts intended to use keys only, as well as new accounts, authorized_keys, sudo or doas activity and management changes. If login is suspicious, preserve records, isolate affected systems, review reachable accounts and systems, rotate credentials as appropriate and recover from a trusted image. After updating, verify the running version, management reachability and legitimate key login.
See what to doResources: 1
TWISA member solutions
Investigate and retest
Review Accepted password records for accounts intended to use keys only, as well as new accounts, authorized_keys, sudo or doas activity and management changes. If login is suspicious, preserve records, isolate affected systems, review reachable accounts and systems, rotate credentials as appropriate and recover from a trusted image. After updating, verify the running version, management reachability and legitimate key login.
Inventory management SSH separately in firmware, hosts and containers
Allow authorized traffic and apply controls at each layer.
- 01
Management entry
SSH and outsourced maintenance channels
Restrict sourcesUse a VPN or dedicated management network
- 02
Devices and containers
Running sshd
Patch through the vendorUpdate firmware, restart the service or replace containers
- 03
Accounts and permissions
Maintenance accounts and reachable systems
Limit downstream impactVerify key login and least privilege for administrative accounts
Feed logs and traffic data from each layer into monitoring and response.
- Monitor and recoverCentralize SSH logs, investigate unexpected logins and validate trusted recovery
Authorized testing and verification
Within the asset owner’s authorized scope, combine asset discovery, vulnerability scanning, penetration tests, API testing and attack simulation as appropriate, then retest after remediation. Verify SSH exposure separately from web requests. Where a WAF is used for a related website, check the actual request, alert, blocking and backend result; a WAF cannot replace an sshd update or validate internal-network and local privilege-escalation paths.
- MITRE CVE and CISA enrichment record
- OpenSSH 10.6p2 release notes
- Alpine fixed versions, configuration and investigation guidance
- Alpine official overview
- OpenWrt SSH server documentation
TWISA member solutions
Supports: Inventory
Trace public addresses, VPNs, management networks and outsourced connections to devices and containers. Check listening processes, firmware and package versions, C library, PAM, effective SSH configuration and account status. Do not export password hashes to tickets or logs.
Supports: Restrict access first
Applicable offer: 眾至資訊’s 新世代防火牆NU-6000 can be deployed on the relevant network path to restrict sources and segment networks. Configure and verify it for the environment, and still update the affected product. The TWISA offer runs through 2026/12/31: code TWISA2026_ShareTech, 5% discount, one year of AI IPS and AI Sandstorm protection, and a 30-month hardware warranty.
Confirm key-based login and a backup management path work; keep the current session open. If patching is delayed, set PasswordAuthentication no as directed by the vendor, check Match overrides, validate the configuration, restart sshd and retest from a separate session. Restrict management access to trusted sources through a VPN or management network.
Supports: Investigate and retest
Review Accepted password records for accounts intended to use keys only, as well as new accounts, authorized_keys, sudo or doas activity and management changes. If login is suspicious, preserve records, isolate affected systems, review reachable accounts and systems, rotate credentials as appropriate and recover from a trusted image. After updating, verify the running version, management reachability and legitimate key login.
Please contact TWISA members for further information about their products and services.
Advisory updated: 2026/11/11. Consult the vendor’s latest information for product support and patch status.