alpinelinux.org

Alpine Linux Security Advisory: OpenSSH-server password authentication bypass

pantalaimon — Thu, 5 Nov 2026 14:44:20 +0000

If you run sshd on Alpine Linux, update openssh now and restart sshd. Upgrading the package alone does not replace the running daemon.

If you cannot update yet, at least disable password logins: set PasswordAuthentication no in your sshd configuration and restart sshd. Either one closes the hole.

What is the problem?

An attacker who can reach your SSH port can log in without knowing any password. It takes one connection, works every time, and needs no retries.

The attacker needs the name of an account whose password field is * (an account with no password set, which is normal for key-only accounts), and needs the machine to have at least one other account with a $5$ or $6$ password hash. The attacker then sends a very long password (257 to 1024 bytes). One user with a password is enough: it makes every account without one reachable.

Details are in the OpenSSH 10.6p2 release notes. No CVE identifier had been assigned at the time of writing.

Who is affected?

You are affected if all of the following are true:

You run the Alpine openssh-server package, which is built without PAM, or you run openssh-server-pam with UsePAM no. (openssh-server-pam with UsePAM yes is not affected.)
PasswordAuthentication is yes (the OpenSSH default, unless you changed it).
The machine has an account whose password field is *. This includes:
- root, which ships as root:* in the base image since about Alpine 3.16. OpenSSH’s default PermitRootLogin prohibit-password protects root, so root is only reachable if PermitRootLogin yes is set. That does not help if another account that can log in is able to become root, for example through doas.
- Any key-only user created with adduser without a password, or with usermod -p '*'.
- Users coming from a directory service through musl-nscd (nslcd, winbind, sssd), since they have no shadow entry.
- The alpine user in the official tiny-cloud images (see below).
At least one local account has a $5$ or $6$ password hash.

Affected releases: every Alpine release we checked, 3.21 through 3.24 and edge, and the older releases that no longer receive regular updates (3.16 to 3.20).

Who is not affected?

Docker and other container users that do not run sshd in the container.
Systems with PasswordAuthentication no.
Systems using openssh-server-pam with UsePAM yes (with UsePAM no you are affected).
Locked accounts: those with ! as the password field in /etc/shadow (a line starting user:!:). They cannot log in with a password or a key.
Systems where no account has a $-style password hash.
Cloud images configured through cloud-init, which writes PasswordAuthentication no.

How can I fix it?

1. Update

apk upgrade -U -a

Alpine 3.21.10, 3.22.8, 3.23.8 and 3.24.4 contain the fixed package (see the release announcement). The fixed package versions are:

Branch	Fixed `openssh` version
edge	10.6_p2-r0
3.24	10.3_p1-r2
3.23	10.2_p1-r1
3.22	10.0_p1-r11
3.21	9.9_p2-r1
3.20	9.7_p1-r6
3.19	9.6_p1-r3
3.18	9.3_p2-r4
3.17	9.1_p1-r7
3.16	9.0_p1-r6

Restart sshd after upgrading (rc-service sshd restart). Upgrading the package does not restart a running sshd, so you must do it after.

2. If you cannot update: disable password authentication

Before you start, make sure your SSH key login works, and keep your current session open until you have tested a new login.

Run these as root. The first two commands create a drop-in file. Alpine’s default sshd_config reads that directory from 3.19 onward; older releases ignore it. The sed command changes yes to no on every PasswordAuthentication line in /etc/ssh/sshd_config, whatever the spacing, including lines inside a Match block. It also adds PasswordAuthentication no at the top of the file, for the case where there was no such line, and saves the original as /etc/ssh/sshd_config.bak. The last two commands check the configuration, restart the daemon, and show the result:

mkdir -p /etc/ssh/sshd_config.d
echo 'PasswordAuthentication no' > /etc/ssh/sshd_config.d/00-no-passwords.conf
sed -i.bak -e '1i PasswordAuthentication no' \
  -e 's/^\(\s*PasswordAuthentication[^y#]*\)yes/\1no/i' \
  /etc/ssh/sshd_config
sshd -t && rc-service sshd restart
sshd -T | grep -i passwordauthentication

The last command should print passwordauthentication no. To undo, delete /etc/ssh/sshd_config.d/00-no-passwords.conf and copy /etc/ssh/sshd_config.bak back over /etc/ssh/sshd_config.

Cloud images (tiny-cloud)

The official tiny-cloud images (the qcow2, VHD and AMI artifacts) from 3.18.11 through 3.24.3 ship an alpine user with a * password field and passwordless doas. They are safe on first boot. They become exploitable as soon as any $6$ hash exists on the machine, for example when an admin sets a console password, or user-data adds a user with hashed_passwd. An attacker then gets a shell as alpine and can use doas to become root.

Images built from 3.21.10, 3.22.8, 3.23.8, 3.24.4 and later include the fixed package. Images from earlier point releases do not, so on every running instance, update openssh or disable password authentication.

Releases that are no longer supported (3.21 and older)

These releases have the same bug. 3.21 reached its end of support on 2026-11-01, but we have published fixed packages for each release all the way back to 3.16.

How do I know if I was attacked?

Look in /var/log/messages for sshd lines reading Accepted password for an account that has no password (alpine, root, or any key-only user). Review doas use and recently created users, files and authorized keys on exposed machines. If you cannot rule out a login, treat the machine as compromised.

How could this happen?

When sshd is built without PAM, it checks a password by hashing the attempt with crypt() (the C library function that turns a password into its stored hash) and comparing the result to the stored password field. For an account whose stored field is too short to contain a salt (the random prefix of a hash), sshd borrows the salt of another account.

musl’s crypt() returns the string * as an error indicator when the key is over 256 bytes long. * is also exactly what the stored field contains for every account with no password, so the “hash” matches and the login succeeds.

OpenSSH 10.6p2 avoids the problem in sshd. The stable-branch packages above carry a patch for the same problem.

Credits

Reported by Özgün Kültekin of Wakefield. Thanks to Damien Miller and Darren Tucker of the OpenSSH project for the fix and the 10.6p2 release, to Timo Teräs for help analyzing the issue, and to Natanael Copa, who built and uploaded the updated packages.

GitLab Security Incident: Attempted Exploitation of CVE-2026-97229

sashk — Wed, 28 Oct 2026 23:45:46 +0000

On October 20 and 21, an attacker tried to exploit a GitLab vulnerability (CVE-2026-97229) on our instance, a week after the fix was released. The attack came close to working. We have found no evidence that it succeeded, but we cannot rule it out, so we treated the instance as compromised and rebuilt it from scratch. Our checks show that the aports repository, packages, and the October 21 releases were not tampered with.

GitLab is being tested before we open it to the public again. All passwords have been reset, so when it is back you will need to set a new one with “Forgot your password?” on the sign-in page. We will post exactly what you need to do when it reopens. In the meantime: if you used the same password for your gitlab.alpinelinux.org account anywhere else, change it there. We have seen automated login attempts against our GitLab with passwords leaked from other sites.

If you have questions or concerns please reach out to us at infra@alpinelinux.org.

What happened

The vulnerability: CVE-2026-97229 is a critical (CVSS 10.0) vulnerability in how GitLab evaluates regular expressions in CI configuration. The underlying bug is in Onigmo, the regular expression engine built into Ruby. GitLab published fixed releases on October 12, but the fix itself is a set of patches to the Ruby that GitLab bundles in its own packages and container images. Upstream Ruby shipped the fix on October 23, in Ruby 3.3.13, 3.4.12 and 4.0.9.

The attack: On October 20 and 21, a newly registered account sent crafted CI configurations to our GitLab instance, which was still running 19.3.4 and did not have the October 12 fix. This crashed GitLab worker processes 8 times. In 4 of those crashes the attacker got partway through the exploit and failed at the next step. The attacker also downloaded our GitLab container image, which suggests they were tuning the exploit to our exact build. We have found no evidence that the attacker ran code on the server, but we cannot rule it out.

Our upgrade didn’t fix the vulnerability: Upgrading to GitLab 19.3.6 on October 22 didn’t fix the vulnerability. The fix isn’t in GitLab’s own code but in a patch to Ruby, which GitLab applies only in its official packages. Our image used standard Ruby, so it didn’t get the patch.

If you run GitLab with your own Ruby (from source or in your own container image) rather than GitLab’s packages, upgrading GitLab is not enough: you also need Ruby 3.3.13, 3.4.12, 4.0.9 or later.

If you use our alpinelinux/gitlab container image, pull alpinelinux/gitlab:19.3.6 again. The image published on October 27 contains Ruby 3.3.13. Any 19.3.6 image you pulled before October 27, and all older tags, are vulnerable.

Incident Timeline

Date	Event
Oct 28	GitLab rebuild complete; all passwords reset and GitLab's secret keys replaced
Oct 27	GitLab closed to everyone except developers and build servers; rebuild started
Oct 26	Found the instance still vulnerable after the upgrade
Oct 25 to 26	Attacker returns and tries to get back in; attempts fail
Oct 24	aports, packages and Oct 21 releases verified against outside records
Oct 23	Attacker's account blocked; Ruby releases the fix
Oct 22	Upgraded to GitLab 19.3.6
Oct 21	Main attack; GitLab crashes, 502 errors and failed CI jobs
Oct 20	Attacker registers an account and starts probing
Oct 13	CVE-2026-97229 published; we upgraded to GitLab 19.3.4 instead of 19.3.5 (which had the fix) by mistake
Oct 12	GitLab releases the fix

What we know and what we can’t rule out

What we found

Alpine releases and packages were not modified. The October 21 stable releases (3.21.9, 3.22.7, 3.23.7, 3.24.3), including their ISO images and the minirootfs tarballs the official alpine Docker images are built from, and all packages built from October 20 to 24 came from aports commits we verified against records outside GitLab. See the FAQ below for details.
No signing keys were exposed. The keys that sign Alpine packages and releases are not, and never have been, stored on the GitLab server.
No evidence that the attacker’s code ran: timing probes showed no delays, and we found no unexpected files, keys, hooks or processes.
No private data was returned to the attacker through any web or API request we can see.

Why we can’t be sure

A successful exploit would leave no crash and no trace in the web logs.
Some logs from the attack day are gone (background job logs, the old container’s filesystem).
We had no logging of outbound network connections, and our hosting provider keeps none either.

What could have been exposed if the attack succeeded

Email addresses, names and IP addresses of all users
Password hashes
2FA secrets, CI/CD variables and runner tokens
Webhook, integration and push mirror credentials
Personal access tokens (stored as hashes)
Private repositories, and confidential issues and merge requests

FAQ

Why did we rebuild GitLab if we were able to mitigate the attack?

Because we cannot rule out code execution, and the evidence we would need to confirm it no longer exists, we took the harder route and rebuilt the GitLab instance from scratch. This removes any foothold a possibly successful exploit could have left behind.

While GitLab is closed, our package mirrors, cgit, and mailing lists/IRC are available as normal.

Are Alpine packages and releases affected?

We have found no sign of tampering in aports or the releases.

Every aports commit added October 20 to 22 arrived through a recorded push by a known developer. We checked this against records the attacker could not reach: a developer’s clone and all 45 builders. Every package built from October 20 to 24, on every architecture, came from commits as published on git.alpinelinux.org. The October 21 releases (3.21.9, 3.22.7, 3.23.7, 3.24.3) were built from those same verified commits.

We ran these checks on October 24, covering commits from October 20 to 22 and packages built up to October 24. Our GitLab stayed vulnerable until we closed it on October 27, so we are extending the same checks to that date.

Is Alpine’s ruby package affected?

The bug is in Ruby’s regular expression engine, so any program that compiles regular expressions from untrusted input is exposed, not only GitLab. Alpine 3.22, 3.23, 3.24 and edge ship Ruby 3.4.12, and Alpine 3.21 ships Ruby 3.3.13; both include the fix. Run apk upgrade to get it.

What are we changing in response to this event?

Fixed Ruby: the rebuilt instance runs a Ruby with the fix (3.3.13 or later).
Faster patching: apply critical GitLab security releases within a day, and check each release for Ruby or other component patches our own build must apply.
Better logging: record outbound connections from the GitLab host and database connections, and keep logs longer than 14 days.
Signed release tags, so releases can be verified independently of GitLab.