Published October 30, 2026. Security details checked against the primary advisories linked below.
On October 21, 2026, PHP released emergency fixes for two critical vulnerabilities that can permit unauthenticated remote code execution. Update the PHP runtime and verify the deployed version. The warning covers PHP-FPM, Apache mod_php, php-cgi, FrankenPHP, and LiteSpeed serving web requests. PHP security announcement.
For AppJet users: AppJet automatically selects the latest PHP version when building your app. Existing apps must be rebuilt and redeployed to pick up that runtime. A previous deployment does not receive a newer runtime just because a fixed version has become available. After rebuilding, verify the PHP version running in the deployed app.
What was disclosed last week?
The two October 21 disclosures are commonly called PHP2Shell:
- CVE-2026-109618: an out-of-memory error can leave internal request data partially initialized. Cleanup can then use that invalid state, creating a path to remote code execution. PHP's advisory identifies updating to a patched release as the only complete mitigation. PHP's out-of-memory advisory.
- CVE-2026-109619: a worker can retain references to memory from an earlier request after that memory has been freed. A later request may access the stale state. The exact exposure depends on configuration, extensions, and application behavior; hiding warnings does not fix the underlying issue. PHP's stale-state advisory.
These are runtime vulnerabilities. Reviewing your own PHP source remains useful, but an application-code review cannot replace installing the fixed interpreter.
The situation also changed after the initial disclosure. Canada's Cyber Centre reported on October 27 that the two vulnerabilities were being exploited in the wild, and that CISA had added both to its Known Exploited Vulnerabilities catalog on October 26. Prioritize exposed systems rather than treating this as a future maintenance task. Canadian Cyber Centre alert, Update 2.
Which PHP versions contain the fixes?
These are the first upstream stable releases containing the fixes for the October 21 pair:
| PHP branch | First fixed release |
|---|---|
| PHP 8.2 | 8.2.35 |
| PHP 8.3 | 8.3.36 |
| PHP 8.4 | 8.4.27 |
| PHP 8.5 | 8.5.12 |
Use a current, supported patched release from your distribution, host, or image provider. The Dutch NCSC's operational guidance lists these releases and notes that distributions and long-term-support vendors may supply backported packages. For those packages, check the vendor advisory and package revision rather than judging by the upstream version string alone. PHP 8.1 and older are no longer supported by the PHP project; a one-off backport is not a long-term support plan. NCSC-NL operational guidance.
Windows installations need an additional package check. On October 26, PHP published 8.5.12-1, 8.4.27-1, 8.3.36-1, and 8.2.35-1 Windows rebuilds for a separate Brotli dependency fix. The PHP runtime version number does not change with that package suffix. Check the package build as well as the interpreter version. PHP Windows rebuild notice.
What about the October 23 session-upload advisory?
A separate issue, CVE-2026-115560, was described on October 23. It involves an unusual combination of session configuration and code that changes the serialization handler at runtime. The October 21 releases do not resolve this separate issue, according to Canada's Cyber Centre. Canadian Cyber Centre alert, Update 1.
As of this article's publication, PHP recommends disabling session upload progress until the relevant regular bugfix release:
session.upload_progress.enabled=0
PHP says applications that never switch the serialization handler at runtime are not exposed to this particular vector. Review the exact conditions before treating every application as equally affected. PHP session-upload advisory.
For configuration changes intended to affect early request processing, apply them through the runtime/server configuration and restart the workers. Do not rely on a change inside application code for a setting needed before that code runs. The main stale-state advisory explains why an upload-related workaround is not a complete replacement for patching the October 21 vulnerabilities. PHP mitigation guidance.
Rebuild existing PHP apps on AppJet
AppJet selects the latest PHP version automatically during a build. That helps new builds pick up current runtime fixes, but existing applications need a rebuild and redeployment. Generated source code and the runtime executing that code are different parts of the deployment.
For an existing AppJet project:
- Open the repository and review its build configuration. Check for a Dockerfile, pinned image, or other project-specific runtime settings that could keep the app on an older release.
- Build and redeploy the application. A successful code edit alone does not replace the running runtime. Use the AppJet deployment workflow.
- Verify the deployed runtime. Record the PHP version and, where relevant, the vendor package or image revision. Check the web-serving runtime, not just a separate local command-line installation.
- Run the application's checks. Exercise login, sessions, file uploads, database operations, and the main user flows. Check build and runtime logs for errors.
- Review the separate session-upload advisory. Updating for the October 21 pair does not automatically settle the October 23 configuration issue.
For example, you can ask AppJet:
Review this PHP project's runtime and build configuration against the linked PHP advisories. Identify any old image or version pin, help me rebuild and redeploy, run the available checks, and report the runtime version you can verify. Flag anything you cannot verify.
AppJet's AI coding tools are included in Free, with enough usage for most coding tasks. You can use them to review your project and prepare the changes without purchasing a separate AI API subscription. See tasks and verification for reviewing the agent's work.
A patched runtime addresses the vulnerabilities covered by its fixes. It does not certify every generated application's authentication, authorization, dependencies, or business logic as vulnerability-free. Keep reviewing application changes and checking the deployed result.
A short checklist for other PHP deployments
If you manage the server or container yourself, identify the package or image serving production requests, obtain the relevant patched build, replace or restart the running workers, and verify the result. Keep a record of the deployed image or package revision so your next rebuild does not silently return to an older dependency.
For WordPress, check Tools → Site Health → Info → Server to identify the site's PHP version, then coordinate the runtime update with your host. WordPress says these vulnerabilities are not specific to WordPress and that a WordPress application update is not the fix for them. WordPress security notice.
If you suspect compromise, investigate as well as patch. Review unexpected processes, files, accounts, outbound connections, and relevant server logs. Canada's Cyber Centre also recommends identifying appliances and third-party products that bundle PHP, rather than limiting your inventory to obvious websites. Cyber Centre recommended actions.
Before you mark the update complete
Confirm that the application is running a patched PHP build, that the rebuild has actually been deployed, and that the core workflows still pass. Record what you verified and any remaining configuration work.
For AppJet projects, start with the rebuild: the latest version selection happens at build time. Then check the running app. Open your AppJet workspace.
Cover: AI-generated editorial illustration for AppJet.