PHP2Shell on Alpine Linux: Fixed php8x Packages

As of 23 October 2026, Alpine Linux has fixed PHP2Shell (CVE-2026-109618 and CVE-2026-109619) in its community repository by moving each PHP package to PHP's own fixed release: php82 8.2.35-r0, php83 8.3.36-r0, php84 8.4.27-r0 and php85 8.5.12-r0. Alpine 3.22, 3.23 and 3.24 are covered, and Alpine's security database lists the fixes for them.

Alpine 3.21 is the exception to watch. Its security database lists the fix only for php82. Its package index, however, also carries php83 8.3.36-r0 and php84 8.4.27-r0, built on 22 October. Those are PHP's fixed releases, but tools that read Alpine's security database will not report them as PHP2Shell fixes. Alpine 3.20 and older are end of life.

To fix an Alpine host, run apk update and apk upgrade, restart PHP-FPM, and check the installed version. Most Alpine PHP runs in containers, though, and there the right fix is usually a rebuilt image, not an apk command inside a running container.

Fixed Alpine PHP Packages by Release

Fixed versions come from Alpine's security database (secdb) for each release and, for 3.21, from the community package index. End-of-life dates for the main repository come from Alpine's release data. All were read on 23 October 2026.

PHP lives in Alpine's community repository, which Alpine supports only "until next stable release." The main-repository dates above are therefore the outer limit for PHP, not a promise. On 3.21, both the community support window and the main repository's end of life (1 November 2026) argue for moving to 3.22 or newer now.

Why the Version Number Means Something on Alpine

On Debian, Ubuntu and RHEL, the PHP version number often stays old after a security fix, because those distributions backport patches. Alpine takes the opposite approach for PHP. Alpine's php83 build recipe sets pkgver=8.3.36 and downloads the source from https://www.php.net/distributions/php-$pkgver.tar.xz. The package is PHP 8.3.36 itself.

So on Alpine, a php83 package at 8.3.36-r0 or later is on the fixed upstream release, and anything below 8.3.36 on that branch is not. The same goes for php82 (8.2.35), php84 (8.4.27) and php85 (8.5.12). Our PHP2Shell fixed versions guide lists every branch, and the PHP2Shell version lookup checks a version string for you.

Two cautions still apply. The PHP command-line binary can differ from the PHP-FPM binary that serves pages, so check the FPM package too. And a version check says nothing about PHP built outside Alpine's packages, which is the normal case in official Docker images.

The Alpine 3.21 Security Database Gap

Alpine's secdb entries mirror the "secfixes" comments in each package's build recipe. On the 3.21 branch, the php83 recipe was bumped to 8.3.36 in a commit titled "community/php83: bump 8.3.36" on 22 October 2026, but its security-fix comments were not updated, and the newest one still points to release 8.3.18-r0. The 3.21 package index contains php83 8.3.36-r0 and php84 8.4.27-r0 all the same.

What this means for you:

• A 3.21 host or image that ran apk upgrade on or after 22 October likely has PHP's fixed release for php83 and php84.
• Scanners and compliance tools that rely on secdb will not show a PHP2Shell fix for those packages. Expect findings you have to explain by version.
• A check based on secdb alone would describe 3.21 php83 as unfixed, even on a host that has 8.3.36-r0 installed.

Either way, 3.21 is weeks from the end of its main-repository support. Plan the move to a newer release rather than relying on late package bumps.

How to Update PHP on an Alpine Host

These commands are from the apk-tools documentation. Package and service names are examples; replace 83 with your branch.

1. Refresh the indexes: apk update
2. Upgrade everything: apk upgrade. To limit it to PHP and its dependencies, name the package: apk upgrade php83. Upgrade the FPM, Apache module and extension packages too.
3. Restart PHP-FPM on OpenRC: rc-service php-fpm83 restart. Alpine's php83 package installs its init script as /etc/init.d/php-fpm83.
4. If PHP runs as an Apache module (the php83-apache2 package), restart Apache as well.
5. Check the result with the steps in the next section.

The apk-tools manual describes apk upgrade as upgrading "installed packages to the latest version available from configured package repositories." It cannot install a fix that is not in your release's repository, which is why the end-of-life releases above stay vulnerable. Our guide to restarting PHP workers explains how to confirm the restart, and our page on PHP2Shell and PHP-FPM covers FPM exposure.

How to Verify

Standard apk commands, labeled as examples:

apk list --installed 'php8*'
apk version php83

The first shows the installed PHP packages and their versions. The second compares installed versions with what the repository offers, so an available upgrade shows up as a difference. Compare the installed version with the table: 8.3.36-r0 or later for php83, and so on.

When these checks do not prove the fix:

• In an official Docker php image. PHP there is compiled from source and is not an apk package. Use php -v inside the container instead; there it shows the real upstream version.
• When a process has not restarted. The package on disk can be fixed while an old PHP-FPM master keeps running.
• For CVE-2026-115560. No Alpine secfix mentions it, and PHP says the fix comes in its next regular release (see below).

Our guide on how to check your PHP version covers finding the PHP that actually serves your site.

Alpine in Containers: Rebuild, Do Not Patch in Place

Much Alpine PHP runs in containers, and there are two different cases:

• The official php:*-alpine images. These are built by Docker's library maintainers from php.net source, not from Alpine's php packages. The fixed tags are 8.5.12, 8.4.27, 8.3.36 and 8.2.35, with Alpine 3.24 and 3.23 variants. A tag-push glitch on 21 October, roughly 15:16 to 16:40 UTC, left some tags out of step for a while (php:8.5-fpm-alpine and php:8.5.12-fpm-alpine pointed at different images), so if you pulled then, pull again and check the digest.
• Your own images built FROM alpine with apk add php83. Rebuild them so the build pulls the fixed packages, then recreate the containers. Running apk upgrade inside a live container is lost when it is recreated.

Our PHP2Shell and Docker guide covers rebuilding and redeploying images in detail.

Who Patches: You or Your Platform?

If you run the Alpine host or build the image, you patch it. If a platform builds and runs the image for you, ask whether it has rebuilt on a fixed base and redeployed. Our guide to the shared responsibility model explains where that line usually sits. Alpine 3.20 and older will not get fixed packages, so the only fix there is a newer release. Our security patching best practices explain how to keep base images and hosts on supported releases. TuxCare lists "Alpine Linux 3.18 ELS" among its affected products, but we could not verify its fixed versions.

After Patching: Keep Upload Progress Off

PHP's 23 October informational advisory for CVE-2026-115560 affects fully patched releases under an unusual configuration. PHP's advice: "We suggest you set session.upload_progress.enabled=0 until the next regular bugfix release." Set session.upload_progress.enabled=0 in php.ini or the FPM pool configuration, not with ini_set() or .user.ini, then restart PHP-FPM.

Conclusion

As of 23 October 2026, Alpine 3.22, 3.23 and 3.24 have PHP's fixed releases for every PHP branch they ship. Alpine 3.21 has them in its package index for php82, php83 and php84, though its security database lists only php82. Upgrade with apk, restart PHP-FPM, and on containers rebuild and redeploy rather than patching in place. If you need help working through a fleet of hosts or images, our emergency PHP patching team can help. Every PHP2Shell guide is in our PHP2Shell Resource Center.

Frequently Asked Questions