The PHP project published a critical security advisory on 21 October 2026. It covers two flaws that can allow unauthenticated remote code execution on web-facing PHP installations. The project released fixed versions for supported branches and urged users to update. This PHP security update guide explains how to find affected sites, apply the update, verify the running version, and handle the separate session upload progress note published on 23 October.
What did the PHP project announce?
The PHP project announced fixes for two critical remote code execution vulnerabilities on 21 October 2026. Its official advisory identifies CVE-2026-109618 and CVE-2026-109619. It says web-serving PHP installations are in scope, including PHP-FPM, Apache mod_php, php-cgi, FrankenPHP, and LiteSpeed.
Remote code execution means an attacker may make a server run code it should not run. “Unauthenticated” means the attacker does not need a normal user login in the described attack paths. That is why the update is urgent even when a site has few accounts or no public form.
The official advisory says the first flaw involves out-of-memory handling and partially initialized request data. The second involves stale internal state surviving after memory was freed. A site owner does not need to reproduce those bugs to respond. The useful action is to identify every PHP runtime that receives web requests and install a fixed release.
Do not confuse a vulnerability in PHP itself with a defect in one website theme. Updating a WordPress plugin or changing a site password does not replace the PHP runtime patch. Those may be useful for other reasons, but this PHP security update requires a runtime patch.
Which PHP versions contain the fix?
The PHP project lists 8.5.12, 8.4.27, 8.3.36, and 8.2.35 as fixed releases for their branches. Check the 2026 PHP news archive or the current advisory for the exact version information. A distribution vendor may also ship a backported fix with a different displayed version number.
| PHP branch | PHP project fixed release |
|---|---|
| 8.5 | 8.5.12 |
| 8.4 | 8.4.27 |
| 8.3 | 8.3.36 |
| 8.2 | 8.2.35 |
Do not assume a site uses the version shown by your laptop. The web server may run a different binary, a container image, or several PHP-FPM pools. A hosting dashboard may display a branch while the actual patch level is older. For the PHP security update, ask the provider for the deployed package version and security patch record.
The advisory notes that PHP 8.1 and older no longer receive normal updates from the PHP project. Some operating system vendors offer backported fixes, and the PHP security team provided minimal source backports for certain older branches. If you rely on a vendor package, obtain confirmation from that vendor rather than comparing only the upstream version string.
PHP 8.2 was scheduled to reach end of life at the end of 2026, according to the PHP release announcement. Even after applying 8.2.35, plan a move to a supported branch.
How do you find every PHP site you operate?
Make an inventory of all web-facing PHP runtimes, including staging, admin, and forgotten subdomains. A patch is incomplete if one old pool continues to serve requests. Start with hosting accounts and deployment records, then confirm each runtime on the server.
List domains, server or container names, PHP branches, package sources, and owners. Check web server configuration to see which PHP-FPM socket or executable each site uses. A command-line php -v may show the CLI binary, not the runtime that handles web traffic. Verify both and record the difference.
If a managed host controls PHP, open its dashboard or ask support which fixed package is running. If a container image controls it, inspect the image tag and digest in the deployed service. A tag such as “8.4” can change over time and may not show which build is currently running.
Do not leave a public phpinfo() page online as a permanent check. It can reveal configuration details. Use a controlled diagnostic process and remove temporary pages immediately after the PHP security update check.
- Record each domain and environment.
- Record the web server's actual PHP runtime.
- Record the package source or container image.
- Record the responsible operator.
- Record the patch date and verification result.
What is the safest update sequence?
Install a fixed PHP release from the PHP project or a vendor-confirmed backport, restart the workers, and test the affected sites. The official PHP advisory says updating is the only complete solution. Temporary settings can reduce some attack paths but do not make a vulnerable installation safe.
Prepare backups and a rollback plan before a production change. Confirm that the application and its dependencies support the target PHP branch. Apply the security release in staging if that can be done quickly, but do not let a long test cycle delay an urgent fix without a clear risk decision.
Update the runtime package or image. Restart the web-serving processes so old workers stop handling requests. A new package on disk does not prove an already running worker has been replaced. Complete the PHP security update by checking the active version after the restart and verifying each pool or container replica.
Test the main user journeys: homepage, login, content editing, forms, file uploads, checkout, and scheduled tasks. Watch server error logs for new warnings or fatal errors. If one feature fails, investigate it without rolling back to a vulnerable runtime as the final answer. A temporary rollback may be needed for availability, but it must lead to another secure patch path.
What if your host uses a backported package?
Ask the host or distribution vendor to confirm that the package contains fixes for both CVEs. A vendor may keep an older-looking PHP version while adding the security patch. Comparing the displayed version to the upstream table can produce a false alarm or false confidence.
Request the package release number, security notice, and installation time. Verify that the running process uses that updated package. If the provider cannot identify the fix, escalate the request. A vague statement that the host is “secure” is weaker than a package advisory naming the vulnerabilities.
For self-managed servers, read the distribution's security bulletin. Apply its approved package update. Avoid replacing a distribution-managed PHP build with an unrelated binary in a hurry, because that can break module compatibility and future update tracking.
Record the vendor evidence in your incident notes. This helps another administrator understand why a lower visible version may still be patched. The goal of the PHP security update is a demonstrably fixed running runtime.
Are configuration changes enough?
No configuration change is a complete substitute for updating PHP. The PHP security team listed temporary measures for operators who cannot patch immediately, but explicitly said they reduce exposure to specific paths rather than make the installation safe.
Some measures in the advisory affect memory limits, request sizes, session upload progress, and worker behavior. They have operational tradeoffs. For example, changing a memory limit can affect how a busy site behaves under load. Apply any temporary measure only after reading the official guidance for the relevant flaw and testing the effect on your application.
Do not copy a setting from a social post without context. A value that helps one server mode may not address another path. Do not assume a web application firewall or hidden admin route blocks attacks against PHP request processing. The project warned that the highest risk includes a demonstrated mod_php path before normal application code runs.
Put a deadline on temporary measures. Record the owner and planned patch time. When the fixed runtime is deployed, review whether each temporary setting should remain for other reasons.
What changed in the 23 October note?
The PHP project published a separate informational note about a narrow session upload progress condition on 23 October 2026. The PHP news archive suggests setting session.upload_progress.enabled=0 until a later regular bugfix release for full protection from that unlikely path.
The note describes an unusual combination. An application must start with session.serialize_handler set to php_binary or php_serialize, then switch it to php at runtime before session_start(), while session upload progress remains enabled. The project says applications that never change the serialize handler at runtime can keep the feature enabled.
This is not a reason to delay the 21 October fixed releases. The main advisory and the later note concern related but distinct response details. Apply the critical update first, then review whether the unusual configuration applies to your application.
If you disable session upload progress, check any upload feature that uses it. Restart the appropriate workers when required by your configuration process. Keep a note of why the setting changed so a future administrator does not turn it back on without reviewing the newer PHP guidance.
How do you know the fix is actually live?
Verify the PHP version or vendor patch in the web-serving process after restart, then test real requests. A package manager message saying “installed” is only one part of the proof. Multiple pools or replicas may update at different times.
Check the active service process and deployment record. Confirm every container or server behind a load balancer has the patched runtime. If a platform uses blue-green deployment, verify traffic has moved away from the old group. If a cache hides the origin, use an authorized diagnostic route or provider report to confirm the runtime.
Review application logs after representative traffic. A security patch can reveal code that relied on undefined behavior or an old extension. Test file upload and session behavior because those paths are relevant to the advisory and common in PHP applications. Keep the PHP security update record with these test results.
Keep a short change record with date, old and new versions, vendor evidence if used, services restarted, and tests passed. The record helps answer a later question about whether a particular site was protected on a particular date.
Should you investigate for compromise?
Review relevant logs and signs of unusual activity, but do not claim compromise or safety without evidence. A vulnerability announcement says a system could be exposed; it does not prove someone attacked your site. At the same time, a patched runtime does not undo an earlier intrusion.
Preserve web server, PHP, authentication, and application logs according to your incident process. Look for unexplained admin changes, new files, unexpected outbound connections, or unusual request patterns. The exact investigation should fit your environment and data. If you find credible evidence, involve the people responsible for incident response and notification duties.
Rotate credentials when exposure is plausible or your policy requires it. Do so through a controlled process so the site does not lose access to databases or payment services unexpectedly. Avoid emailing secret values to colleagues during a rushed update.
Tell nontechnical site owners what was patched and what remains under review. Separate a confirmed version fix from an unconfirmed security investigation. Clear, dated facts are more useful than an absolute “all safe” claim.
How do you reduce delay next time?
Keep an accurate runtime inventory and a tested update path. The October 2026 advisory shows why a small unmaintained PHP installation can become an urgent problem. If you know every domain, host, version, and owner, you can patch faster.
Use supported PHP branches and track their end of life dates. Keep application dependencies compatible with newer releases so security updates are not blocked by years of deferred maintenance. Automate staging checks for login, forms, uploads, and checkout where those functions matter.
Make vendor communication part of the plan. A managed host should be able to state which security release it deployed. A self-managed team should know who can restart workers and verify active binaries. Record the process before the next advisory arrives.
Watch the PHP project's official news for updates. Security posts can be revised or followed by new information. An article is a guide to action; the project advisory remains the source for current technical details.
The React Server Components security guide applies the same inventory, patch, and verification habit to a different stack.
Frequently asked questions
Does updating a PHP plugin fix this advisory?
No. The named vulnerabilities are in PHP itself. Update the web-serving PHP runtime.
Is PHP 8.4.27 a fixed release?
Yes, according to the PHP project's 21 October 2026 announcement. Verify the running build or a vendor-confirmed backport.
Can a firewall replace the update?
No. The PHP project says updating is the only complete solution.
Does the 23 October session note affect every application?
No. It describes a narrow configuration and runtime change. Read the official note and check whether your application uses that pattern.