Alpine Linux rolls out four simultaneous security releases, tightening OpenSSL, musl, zlib, and a critical PHP flaw
Alpine Linux just pushed four stable point releases at once: 3.21.9, 3.22.7, 3.23.7, and 3.24.3. They went out today, and cover security fixes spanning five different components. The announcement itself was about as terse as the project gets.
"Those releases include security fixes across core components. The full list of changes can be found in the git log."
Beneath that brevity sits one of the more substantial coordinated updates of the year, and here's the unusual part: all four currently supported branches got patched in lockstep. That's not something that happens often.
Why all four branches at once
Most security sweeps touch a version or two. This one hit Alpine's entire active footprint simultaneously, from the oldest still-supported branch (3.21) up through the newest (3.24). That only makes sense if the underlying upstream flaws hit every Linux distribution on the same day, and that's exactly what happened.
The eMudhra CA compromise and OpenSSL's late-September advisory both struck the whole ecosystem at once. Alpine's model is to backport fixes to every supported branch, so it had to move on all four in parallel.
The new images are already live across every channel. ISOs, the official alpine Docker Hub image (docker pull alpine:3.24.3, for example), and the package repositories all carry them.
What actually got patched
The component list is long, so let's walk through the pieces that matter.
musl libc got the CVE-2026-107891 fix across all four branches, an integer overflow in regcomp() that can produce out-of-bounds heap writes. The catch: it's triggered by the regex itself, not the data being matched. So you're only in trouble if you compile untrusted regular expressions with the libc. At minimum it's a crash; depending on heap layout, arbitrary code execution is possible. Tenable rated the Alpine impact as High.
zlib was patched for CVE-2026-85091, a heap overflow in gz_vacate() during stalled non-blocking gzip writes. That one's a clean CVSS 8.3 (High). Alpine shipped zlib 1.3.2-r1, and interestingly there was some upstream hand-wringing over whether the older v1.3.1 even falls in scope. It doesn't matter much: the patched release removes the problem regardless.
ca-certificates addresses the eMudhra incident. On October 19, Cloudflare reported that private keys of eight eMudhra intermediate CAs had been compromised, and eMudhra revoked them all the following day. That's a big deal, because a leaked intermediate key lets someone mint certificates at will, fake TLS certs, forged code signatures, the whole trust chain compromised. Alpine's ca-certificates 20261020-r0 pulls the bad intermediates out of the Mozilla trust store. If you're keeping score, virtually every trust store on Earth got the same treatment: Firefox, NSS, Go, Python's certifi, and the Debian/Ubuntu/Fedora/Arch/Gentoo lineups all moved in parallel.
The OpenSSL detail worth your attention
This is where the release gets technically interesting. OpenSSL's September 29, 2026 advisory shipped alongside 3.5.9 and fixed ten CVEs common to all branches, plus two QUIC-only ones on every branch except 3.21.9.
Those two missing CVEs aren't an oversight. CVE-2026-42772 and CVE-2026-54873 are QUIC-specific, and OpenSSL only added a native QUIC stack in 3.5.0. Alpine 3.21 still ships the older 3.3.3.x series (libssl3/libcrypto3 3.3.7), which predates QUIC entirely. No QUIC code path, no vulnerability to exploit. Alpine simply didn't backport fixes for a code path that doesn't exist on that branch. It's a clean call, and a good reminder that "update everything" is rarely one-size-fits-all.
The upshot: the OpenSSL fixes are overwhelmingly denial-of-service and resource-exhaustion bugs, memory pressure, CPU blowups, flow-control abuse. One High (CVE-2026-84782, a DTLS retransmit issue) tops the list; the rest are Low. No mass RCE here. It's consistent with OpenSSL's recent pattern of fuzzers hunting DoS conditions in the growing QUIC/DTLS code.
The one you should actually worry about
The 3.23 and 3.24 branches carried an extra payload that 3.21 and 3.22 did not: fixes for PHP 8.3 through 8.5. This is the real headline.
The pair, colloquially "php2shell", is CVE-2026-109618 and CVE-2026-109619, both scored 9.2 (Critical). They exploit how PHP handles an out-of-memory bailout. When a request blows past memory_limit, PHP uses longjmp() to abort. Some code paths make request memory reachable before it's fully initialized. If an allocation fails right then, the jump skips setup and leaves corrupted memory behind, which an attacker can drive deliberately through multipart-form parsing.
The result is unauthenticated remote code execution as the web-server worker. CISA issued a dedicated alert directing organizations to patch immediately, prioritizing internet-facing systems. The advisory's affected range is enormous, and it even includes end-of-life lines like PHP 7.4, 8.0, and 8.1 that get no community updates at all.
That's why the RCE ships only on 3.23 and 3.24. Older branches pin an older PHP that falls outside the advisory's range, while 3.23/3.24 carry the 8.3–8.5 series the fix targets. If you're running PHP on 3.21 or 3.22, check your version carefully, you may still be exposed.
The clock is already ticking on 3.21
Here's something worth sitting with: 3.21.9 lands just weeks before v3.21 reaches end-of-support on November 1, 2026. Roughly five weeks. For teams still on that branch, this is effectively a near-final security update. Migration should be a priority, not something to park on a backlog.
v3.24, meanwhile, is the only branch still pulling community-repository fixes alongside main, making it the most future-proof choice for anything new. And for what it's worth, the container images stay tiny: 3.21.9 sits at about 3.46 MB, with 3.22.7, 3.23.7, and 3.24.3 all hovering around 3.6 to 3.7 MB. That's the lightweight design doing its job.
It's arguably a bit unfortunate that these are also the exact branches you're most likely to want to be on, but that's a scheduling quirk, not a flaw in the release.
What you should do
- Update everything to the matching point release. For containers, rebuild from the patched base image rather than relying on a running container, baked-in package versions don't change at runtime.
- Prioritize PHP. Any internet-facing system on PHP before 8.2.35, 8.3.36, 8.4.27, or 8.5.12 needs patching now. Until then, interim mitigations include enforcing memory_limit=-1 via php_admin_value, disabling session.upload_progress.enabled, keeping post_max_size conservative, and limiting multipart form data at the WAF.
- Rebuild transitive dependencies. zlib and OpenSSL are shared libraries, so services built on them (compression stacks, TLS consumers) need rebuilding to pick up the patched code.
- Plan the 3.21 migration. With support ending November 1, that branch is on its last legs.
The full change list is in the Alpine git log, and the security tracker at security.alpinelinux.org has the individual CVE pages for musl, zlib, and OpenSSL.
Head there to the release announcement.
