PHP2Shell on Nginx: Which PHP-FPM Versions Need Updating?
Most PHP2Shell write-ups focus on Apache mod_php, but your app runs on PHP-FPM behind nginx. Is your server in scope, and is the patch alone enough?
- PHP-FPM behind nginx is included in the update scope.
- The first fixes for the October 21 pair are 8.2.35, 8.3.36, 8.4.27, and 8.5.12.
- A separate October 23 advisory adds a session-configuration check after patching.
Using nginx does not remove PHP-FPM from the patch list
Yes, update PHP-FPM. The PHP project’s October 21 advisory covers PHP installations serving web requests, including FPM, mod_php, php-cgi, FrankenPHP, and LiteSpeed. The front-end web server’s name is not a reliable way to decide whether the PHP runtime needs attention.
Apache mod_php receives particular emphasis because an attack can occur before application code runs. FPM handles failed request startup differently, but that does not establish immunity during application execution. The out-of-memory advisory describes that distinction; the stale-state advisory also identifies an FPM path dependent on suitable application behavior.
Match the fix to your PHP branch
These are the first fixed releases for CVE-2026-109618 and CVE-2026-109619, also listed in AWS’s bulletin.
| Branch | First fixed release for the October 21 pair |
|---|---|
| 8.2 | 8.2.35 |
| 8.3 | 8.3.36 |
| 8.4 | 8.4.27 |
| 8.5 | 8.5.12 |
A distribution or LTS vendor may backport the fixes into an older package version. Use its security notice to identify the fixed build. PHP 8.1 and older no longer receive regular upstream updates, although PHP supplied exceptional minimal source backports for 7.4, 8.0, and 8.1. That does not restore routine support.
Verify the PHP installation that actually serves the site
For deployment checks, identify the FPM service, container, or hosted runtime attached to the application. A host’s command-line PHP can be a different installation; php -v there is not sufficient evidence that the website uses the same build.
- Identify the application’s web runtime.
- Replace its package or image with a fixed upstream or vendor build.
- Restart or replace PHP workers through the deployment procedure, then verify the serving runtime.
With managed hosting, ask the provider for the affected site’s PHP branch and confirmation that both CVEs have been addressed. This makes the request more useful than a general question about whether the server was updated.
The October 23 notice needs a separate configuration check
The follow-up advisory concerns CVE-2026-115560 and an unusual combination: configuration selects php_binary or php_serialize, application code changes it to php with ini_set() before session_start(), and session upload progress remains enabled. PHP plans to address it in a regular release.
The project recommends the following temporary setting. Keep it if already applied. The notice also says applications that never switch the serializer at runtime can leave the feature enabled.
session.upload_progress.enabled = 0Apply it in startup configuration and restart every PHP worker. Red Hat’s guidance excludes application-level ini_set() and FPM .user.ini files for this mitigation. The upload-progress feature tracks file-transfer progress through session data; disabling it affects interfaces relying on that tracking, rather than banning all uploads.
Complete the October 21 update first, then evaluate the follow-up configuration. Disabling upload progress is not a substitute for patching the original pair.