0x539ae122539a…539ae11f

ConfirmedSecurity626 vB154 sat/vB3 min decode

Alpine Linux SSH Flaw Under Active Exploitation, Vendors Report

Previdian logged 20 exploitation attempts from 13 IPs between Nov. 6 and 8 against an Alpine SSH password-bypass flaw patched in OpenSSH 10.6p2 on Nov. 5.

Attackers Exploit Alpine SSH Password-Bypass Flaw
WitnessAttackers Exploit Alpine SSH Password-Bypass FlawJESHOOTS-com / pixabay

Outputs

  1. Previdian recorded 20 exploitation attempts from 13 distinct IP addresses across four sensors between Nov. 6 and Nov. 8.

  2. OpenSSH 10.6p2, released Nov. 5, introduced a workaround for the musl/PAM-disabled flaw.

  3. watchTowr reported exploitation on Nov. 6 involving 'botnets and crypto miners.'

  4. Unpatched tiny-cloud images 3.18.11 through 3.24.3 become exploitable once a SHA-512 password hash is added.

  5. Patching requires restarting sshd; package update alone leaves the running process vulnerable.

Attackers are actively exploiting an Alpine Linux SSH password-bypass flaw, with Previdian counting 20 exploitation attempts from 13 distinct IP addresses across four sensors between Nov. 6 and Nov. 8. Previdian cautions that its sensor observations cannot establish whether the targeted hosts were vulnerable or whether any attempt succeeded.

The security firm watchTowr separately reported exploitation on Nov. 6, describing the observed activity as involving “botnets and crypto miners.” The campaign began within a day of the Nov. 5 release of OpenSSH 10.6p2, which shipped a workaround for the underlying flaw on Linux systems using the musl C library with PAM authentication disabled.

The vulnerability is narrow but consequential. Exploitation requires three conditions: a reachable SSH server, password authentication enabled, and PAM — the pluggable authentication framework — disabled. Alpine's standard openssh-server package ships without PAM, so default installations are exposed to the risk pattern. The PAM-enabled alternative package is unaffected when configured with UsePAM yes.

How does the bypass work?

The flaw targets a specific account configuration. The host must carry a login-eligible account whose stored password field is an asterisk, plus at least one other account holding a SHA-256 or SHA-512 password hash. When musl's hashing function receives an oversized password, it returns an asterisk as an error marker — which then matches the key-only account's stored field.

The result is that accounts deliberately configured for key-only access can be entered by password. For infrastructure operators, this inverts a common hardening assumption: disabling password logins per account is not sufficient on an affected host.

Alpine's advisory instructs operators to install the patched OpenSSH package for their Alpine branch and restart the SSH server, sshd. Updating the package alone leaves the running server process unchanged, a detail that makes partial remediation easy to mistake for full remediation. Operators who cannot patch immediately should set PasswordAuthentication no and restart the service instead. Before doing so, Alpine advises confirming that SSH-key login works and keeping the existing session open while testing a new login — otherwise operators risk locking themselves out.

What does this change for crypto operators?

For crypto node, validator and exchange operators running Alpine, the relevant check is the host's SSH service and authentication settings, not whether an application runs inside an Alpine-based container. Alpine states plainly that containers not running sshd are unaffected. The exposure surface is the host, not the workload.

One cloud deployment path deserves specific attention. Alpine warns that unpatched tiny-cloud images from version 3.18.11 through 3.24.3 are safe on first boot but become exploitable the moment a SHA-512 password hash is added — for example, by setting a console password. At that point an attacker can enter as the alpine user and escalate to root through that account's passwordless administrative access.

The timeline sharpens the picture. Previdian's sensors logged attempts on Nov. 6–8, watchTowr confirmed botnet and miner activity on Nov. 6, and the fix landed on Nov. 5. That is a same-day turnaround from patch to in-the-wild exploitation — a tempo practitioners should assume for any remotely reachable authentication flaw.

For exposed machines, Alpine recommends reviewing logs for accepted password logins to accounts that have no password, along with administrative activity, newly created users, files and authorized keys. If a successful login cannot be ruled out, the guidance is unambiguous: treat the machine as compromised. For validators and exchange nodes, that means assuming key material on the host is at risk, not merely patching forward.

Operators running Alpine-based infrastructure with reachable SSH should treat the restart of sshd after patching as the effective remediation deadline, since a patched package without a restarted daemon remains exposed.

via cryptonews.net (Source)

More from Nathan Brooks

Nathan Brooks

Show full bio

Market editor covering money, funding and market shifts around crypto and web3 industry at Mempool Brief.

772 articles