Why musl vs glibc Security Differences Affect Patching

Musl vs glibc security differences decide whether a bug reaches your host, because the same program can behave differently on each C library. The November 2026 OpenSSH password bypass affected only Linux systems using musl without PAM. Teams that track libc per asset could scope that incident in minutes. Teams that do not had to log in and look. Add libc and auth path to your inventory before the next one.

Why do musl and glibc differences affect security?

They affect security because programs depend on how the C library behaves in edge cases, and the two libraries handle those cases differently. Code that is safe on one can be unsafe on the other, even when the source is identical.

OpenSSH is the clear example. Musl's crypt() returns the string * on failure, while glibc does not behave that way. That single detail, combined with how sshd compares strings, made logins succeed on musl and fail everywhere else. Damien Miller of OpenSSH said the project considers the root cause to be outside OpenSSH, which is the point: neither component looked wrong in isolation.

The differences are documented and go well beyond password hashing. The musl project's list of functional differences from glibc covers regular expressions, printf format specifiers, end-of-file handling, lazy binding and library unloading. dlclose is a no-op on musl, for one. Most of these are harmless. You cannot tell which ones matter until a bug shows you.

Why do test results not carry across libraries?

Upstream testing often skips the less common combination. The researcher who found the bypass said that OpenSSH tests on OpenBSD and glibc, that musl does not test sshd, and that most distributions go through PAM, which never calls crypt() for an asterisk account. Each project was reasonable. The gap sat between them for about a decade.

Test coverage is therefore a risk input. If your production stack runs on a less tested combination, assume your own acceptance tests are the only ones exercising it, and budget for that.

Where musl hides in a typical estate

Most teams can name their Alpine servers. These are the places that get missed:

• Container images. Alpine is a common base, but exposure depends on what runs inside. Alpine states that containers without sshd are not affected by this bug, so scope by process, not just by image name.
• Cloud images. Alpine's tiny-cloud images from 3.18.11 through 3.24.3 ship an alpine account with passwordless doas, while images configured through cloud-init disable password logins. Two instances of the same distribution can have different exposure.
• Network and embedded devices. The researcher names OpenWrt, Buildroot and Yocto as musl-based. Routers, gateways, cameras and industrial boxes may run these, and you depend on the vendor to ship a fix.
• Jump hosts and small utility VMs. These were often built small on purpose, by someone who has since left.

What to add to your asset inventory

Software composition data usually stops at package names and versions. For incidents like this one, add these fields per host or image:

• C library: musl or glibc, and version.
• Authentication path: PAM or not, for each exposed service.
• Exposed services: which listeners run on the system, and whether they face the internet.
• Build source: distribution, image version and who owns the rebuild.
• Patch channel: distribution packages, vendor firmware or an internal build.

With those fields, the OpenSSH scope query becomes a filter, not a project. You can also retire work fast: glibc hosts, PAM setups, Dropbear and OpenBSD were out of scope, and proving that in a query frees people for the hosts that matter.

Why can version numbers mislead patch checks?

Version checks mislead because distributions backport fixes without changing the upstream version number. A scanner that looks only for a version at or above the upstream fix will flag patched systems as vulnerable.

This incident shows it well. The upstream fix is OpenSSH 10.6p2, but Alpine's fixed package on the 3.24 branch is 10.3_p1-r2, and on 3.22 it is 10.0_p1-r11. Compare against the distribution's fixed list. The reverse problem exists too: a correct package on disk means nothing until the service restarts, because upgrading does not replace a running sshd. Your patch evidence should show the running process, not just the installed package.

How to change patch priority when libc matters

When an advisory names a libc or auth path, rank work in this order:

1. Internet-facing hosts that meet every stated condition.
2. Internal hosts that meet them, starting with jump hosts and anything holding credentials.
3. Hosts where you cannot confirm the conditions. Treat unknown as exposed until checked.
4. Appliances waiting on a vendor. Apply a configuration mitigation now, such as disabling SSH password authentication, and track the vendor's date.

Vendor-dependent systems deserve a standing question in procurement: which C library does the firmware use, and how fast do you ship fixes for a flaw specific to it?

Should you drop musl?

No. Moving libraries to avoid one bug trades known risk for migration risk, and glibc has its own history of serious flaws. The goal is to know where each library runs and to test what you actually deploy.

Do keep the variant count down, though. Every extra combination of libc, auth path and init system is another row in your incident scoping table. If a team picked Alpine only to save disk space on a VM, ask whether that still justifies a separate patch track. Standardize where you can, then make the exceptions visible. Knowing how account markers in the shadow password field behave on each platform belongs in the same exception record.

Questions to take to your next review

• Can we list every host running musl within an hour?
• Does our scanner compare against distribution fixed versions, or only upstream ones?
• Does patch evidence confirm that services restarted?
• Which appliances run musl, and who owns the vendor follow-up?
• Do we run acceptance tests on the same libc and auth path as production?