OpenSSH Patches Critical Flaw Allowing Long Passwords to Bypass SSH Authentication on Alpine Linux

OpenSSH has released an emergency update, version 10.6p2, to address a critical vulnerability that allows attackers to bypass SSH authentication on certain Alpine Linux systems. The flaw, which OpenSSH itself rates as critical, enables unauthenticated access to accounts that have no password set — including accounts configured for SSH key-only logins.

Who Is Affected

The vulnerability is not universal across all Linux distributions. According to the source report, the issue affects some Alpine Linux servers running the standard openssh-server package. Administrators running OpenSSH on other platforms should still track vendor guidance, but Alpine deployments are the confirmed exposure path described in the advisory.

How the Bypass Works

The attack requires a relatively modest set of preconditions:

  • Network access to the targeted SSH server.
  • Knowledge of a valid account name on the system.
  • A password between 257 and 1,024 bytes in length.

When these conditions are met, an attacker can authenticate to an account that has no password — such as an account provisioned exclusively for public-key authentication — without possessing the corresponding private key. In other words, the very accounts organizations treat as the most locked-down (key-only, passwordless) can become reachable through this flaw.

The length window is notable. Passwords of 256 bytes or fewer, and of more than 1,024 bytes, do not appear to trigger the bypass based on the published details. This suggests the defect is tied to how overly long password inputs are handled during the authentication exchange rather than a simple credential-guessing weakness.

The Fix

OpenSSH published version 10.6p2 to block the attack. Alpine, meanwhile, has shipped fixed packages across its supported branches, so the fastest remediation path for Alpine operators is a standard package upgrade rather than a source build.

Recommended Actions

  1. Patch immediately. Upgrade openssh-server to the fixed Alpine packages (or move to OpenSSH 10.6p2 upstream) on every internet-facing and internal SSH host.
  2. Inventory your Alpine footprint. Because the flaw is tied to the Alpine build of OpenSSH, prioritize identifying Alpine-based servers, containers, and appliances in your estate — including those baked into VM images and CI runners that may not appear in a traditional server inventory.
  3. Restrict SSH exposure. Limit inbound SSH to known management networks or via a bastion/jump host. Reducing reachable attack surface buys time for hosts that cannot be patched instantly.
  4. Audit passwordless accounts. Review which accounts have empty password fields and confirm whether each genuinely needs to exist. Where possible, disable password authentication entirely in sshd_config to shrink the relevant code path.
  5. Hunt for indicators. Review SSH authentication logs for unusually long password submissions or successful logins to key-only accounts from unexpected sources. Because the technique abuses a legitimate authentication flow, detection may depend on anomaly-based monitoring rather than signature matching.
  6. Rotate and review keys. If you have reason to believe a host was exposed before patching, treat credentials and keys stored or trusted on that system as potentially compromised.

Why This Matters

Passwordless, key-only SSH access is a widely recommended hardening baseline — it removes the risk of password guessing and credential stuffing entirely. A flaw that turns that configuration into an authentication bypass inverts a core security assumption. It is a reminder that the authentication stack itself deserves the same patch urgency as the applications it protects, and that distribution-specific packaging can create exposure windows that generic upstream advisories do not fully capture.

Organizations should treat this as a high-priority patch cycle, verify package versions after upgrading, and confirm that no passwordless accounts remain reachable from untrusted networks.

Source

Read the original report at The Hacker News.