This PHP security checklist helps website owners respond to two critical vulnerabilities patched on October 21, 2026 — and check whether their running website actually received the fixes.
The PHP project disclosed CVE-2026-109618 and CVE-2026-109619, two critical vulnerabilities that can allow unauthenticated remote code execution.
That means a vulnerable PHP runtime may be exposed to attacks before a visitor even logs in. A successful update closes the known flaws; it does not establish whether an earlier compromise occurred.
Update · October 31, 2026: On October 27, the Canadian Centre for Cyber Security updated its alert to report open-source indications that both vulnerabilities are being exploited in the wild. It also notes that CISA added both CVEs to its Known Exploited Vulnerabilities catalog on October 26. This raises the urgency of patching exposed PHP runtimes; it does not prove that any particular website was compromised. See the Canadian Centre alert.
WordPress published its own security notice urging website owners to update the PHP runtime used by their hosting environment.
The question is no longer simply whether you updated WordPress. It is whether the PHP software processing your website’s requests is fixed.
The October vulnerabilities affect the PHP runtime, not just a particular WordPress plugin.
Conceptual architecture, not an exploit demonstration or live vulnerability scan.
- Which PHP Versions Received the Emergency Fixes?
- The 12-Point PHP Security Checklist
- Identify Every Website and Service Using PHP
- Check the PHP Version Serving Real Web Requests
- Compare the Runtime Against the Fixed Releases
- Identify PHP-FPM, Apache Modules and Other Handlers
- Verify Backups and Prepare a Recovery Plan
- Confirm That Your Hosting Vendor Has Released the Fix
- Install the Correct PHP Security Updates
- Restart Affected Workers and Verify the Running Runtime
- Test the Website After the PHP Update
- Review Logs and Investigate Signs of Compromise
- Review the Session Advisory and Updated Windows Builds
- Record the Outcome and Plan Future Security Checks
- What If You Cannot Patch PHP Immediately?
- Frequently Asked Questions
- Official Sources
Which PHP Versions Received the Emergency Fixes?
On October 21, 2026, the PHP project released these fixed upstream versions:
| PHP branch | Fixed upstream release |
|---|---|
| PHP 8.5 | 8.5.12 |
| PHP 8.4 | 8.4.27 |
| PHP 8.3 | 8.3.36 |
| PHP 8.2 | 8.2.35 |
These are upstream PHP release versions. Linux distributions and hosting vendors may backport security patches into packages that keep an older upstream version number. Check the package revision and vendor advisory as well as the displayed PHP version. PHP 8.1 and earlier no longer receive updates from the PHP project’s normal security-release process; some vendors may still provide backports. PHP 8.2 is scheduled to reach end of life on December 31, 2026, so plan a move to a supported branch.
The 12-Point PHP Security Checklist
These commands are primarily read-only checks. Install updates and restart services only through an authorized administrator and a tested recovery plan. Mark a step complete after you have verified and recorded its result.
Start with the website inventory. Completion is a manual review, not a security scan.
Identify Every Website and Service Using PHP
An overlooked application, staging site or secondary domain can remain vulnerable after the main website is updated.
View explanation and checks
List production sites, staging domains, administrative panels, internal tools, containers and separately installed PHP applications. Do not assume all sites use the same PHP installation; a single server can run several versions side by side.
Check the PHP Version Serving Real Web Requests
The command-line PHP version may differ from the runtime powering your public website.
View explanation and commands
In WordPress, open Tools → Site Health → Info → Server and inspect the PHP version. You can also run php -v, but that only identifies the PHP executable reached by your shell; it does not prove which PHP-FPM pool, Apache module or hosting runtime handles web requests.
On managed hosting, check the provider’s site or PHP management panel.
Compare the Runtime Against the Fixed Releases
Establish whether the active runtime contains fixes for both critical CVEs.
View explanation and checks
Compare the upstream version against the table above. If the displayed release is older, check whether the Linux distribution or hosting vendor has supplied a patched package with an older upstream version string.
The October 21 flaws are CVE-2026-109618 and CVE-2026-109619. Do not mark a runtime patched solely because a hosting dashboard says “up to date”; look for explicit security coverage from the package supplier.
Identify PHP-FPM, Apache Modules and Other Handlers
Updating one PHP executable does not automatically update every runtime or worker process.
View explanation and commands
On Linux, these commands can help discover PHP-related processes and services:
ps -eo pid,comm,args | grep '[p]hp-fpm'
systemctl list-units --type=service --all | grep -Ei 'php|apache|httpd|litespeed'Depending on the deployment, you may have multiple FPM pools, containers, Apache modules or other handlers. These commands are discovery aids, not a complete map of every hosting stack.
Verify Backups and Prepare a Recovery Plan
An emergency update should not turn a failed deployment into permanent data loss.
View recovery checks
Confirm you have a recent backup of application files, databases, configuration and relevant credentials. Check whether it can actually be restored; a backup file existing somewhere does not prove recoverability.
For a self-managed server, establish a maintenance window and confirm independent administrative access. See our Linux Server Backup & Restore Checklist.
Confirm That Your Hosting Vendor Has Released the Fix
Different hosting platforms distribute PHP security updates through different channels.
View explanation and commands
Determine whether PHP comes from your OS vendor, a third-party repository, a hosting panel, a container image or an upstream installation.
On Debian or Ubuntu, inspect installed packages with:
dpkg-query -W 'php*' 2>/dev/nullOn RPM-based systems:
rpm -qa | grep -E '^php|^ea-php'Match the package supplier’s security notice to the installed package revision. For managed hosting, request confirmation that both October 21 CVEs are fixed in the active web runtime.
Install the Correct PHP Security Updates
Apply patches to every affected PHP installation, not just WordPress core or plugins.
View update guidance
On self-managed servers, follow the package vendor’s security update instructions. Include the relevant PHP packages, modules, extensions and service handlers. Review which packages will change and whether the update could interrupt production traffic.
On managed hosting, use the supported dashboard or request immediate remediation from the provider. Do not replace vendor packages with an unrelated binary just to obtain a higher version number; this can break dependencies and complicate future updates.
Our Linux Server Change Checklist covers safer preparation and rollback.
Restart Affected Workers and Verify the Running Runtime
Installing corrected files does not necessarily replace vulnerable PHP code already loaded into worker processes.
View explanation and commands
Find the actual service handling requests. For example, a Debian installation might use a versioned service such as php8.3-fpm. Inspect its status:
systemctl status php8.3-fpm --no-pagerAfter an approved update, use your service manager or hosting platform’s supported restart procedure. The service name varies by environment. Restarts may briefly interrupt active requests, so coordinate them with your availability plan.
Verify the version used by new web requests, not just by the CLI.
Test the Website After the PHP Update
A successful service restart does not prove the application is functioning correctly.
View explanation and commands
Test critical workflows: page loading, login, forms, file uploads, checkout, scheduled jobs and database access.
You can inspect HTTP response headers with:
curl -I https://example.comReplace the example address with your domain. An HTTP 200 response confirms only that one request succeeded; it does not validate every feature or prove that PHP is patched. Check the runtime version again after the service has restarted.
Review Logs and Investigate Signs of Compromise
Applying a patch prevents future exploitation of the fixed flaws, but does not undo a previous compromise.
View explanation and commands
Review web access logs, PHP errors, unexpected processes, newly created files, unfamiliar scheduled tasks and unusual outbound connections.
For a systemd-managed PHP-FPM service, inspect recent events:
journalctl -u php8.3-fpm -n 100 --no-pagerReplace the service name as appropriate. Missing logs or suspicious requests do not by themselves prove an intrusion; clean-looking logs cannot guarantee that no compromise occurred.
If evidence suggests unauthorized access, preserve relevant records, follow an incident-response process and consider specialist help. Our Linux Server Security Audit Checklist offers a broader VPS security review.
Review the Session Advisory and Updated Windows Builds
Security guidance continued to change after the initial October 21 releases.
View important additional details
October 23 · CVE-2026-115560: PHP published an informational advisory for an unlikely remote-code-execution path involving session upload progress. PHP recommends setting session.upload_progress.enabled=0 until the next regular bug-fix release to protect against this vector.
The PHP advisory says this path requires all three conditions: the configuration sets session.serialize_handler to php_binary or php_serialize; application code switches it to php at runtime with ini_set() before session_start(); and session upload progress remains enabled. If an application does not switch the serializer at runtime, PHP says this feature can remain enabled.
To apply the mitigation, set it in php.ini, an FPM pool, or server configuration that takes effect before request parsing. Do not rely on ini_set() or FPM .user.ini for this setting, and restart every affected PHP worker. PHP says this blocks the confirmed session paths, not every possible variant.
You can query the CLI configuration with:
php -i | grep \
'session.upload_progress.enabled'This reports the CLI setting only; it does not prove what PHP-FPM, Apache or another web runtime uses. Verify the active web configuration through the hosting panel or the configuration for the serving handler. Assess compatibility before changing the setting.
October 26 · Windows packages: PHP published Windows rebuilds 8.5.12-1, 8.4.27-1, 8.3.36-1 and 8.2.35-1 with Brotli 1.2.1, which fixes CVE-2026-111497. This is a dependency rebuild, not a new PHP source version. PHP says the affected decoder path through cURL requires automatic HTTP response decompression to be enabled; cURL disables it by default, though an application or HTTP client library can enable it. Check these rebuilt packages if you run the affected Windows builds.
Record the Outcome and Plan Future Security Checks
A patching task is not finished until someone can show what changed, where it changed and whether the result was verified.
View verification requirements
Document affected websites and environments, installed package revisions, vendor security references and verification performed afterward.
Record sites that remain exposed because their hosting provider has not supplied a fix. Assign an owner and escalation plan to each outstanding risk.
Schedule routine checks for future PHP advisories, application updates and end-of-support dates.
What If You Cannot Patch PHP Immediately?
PHP says there is no complete configuration-only mitigation for the October 21 vulnerabilities. Updating to a fixed release or applying a trusted vendor backport is the required long-term fix.
If you cannot update promptly, restrict access to the application or isolate it from public networks while you coordinate remediation. WAF rules and runtime settings may reduce exposure to specific paths, but they do not establish that an installation is safe.
Identify exposure
Restrict access
Patch and verify
The appropriate operational response depends on exposure, business impact and recovery options. Follow your provider’s guidance and preserve relevant logs if you suspect a compromise.
Frequently Asked Questions
Does updating WordPress fix these PHP vulnerabilities?
No. These vulnerabilities affect the PHP runtime. WordPress updates remain important, but the October 21 fixes must come from your PHP supplier or hosting provider.
Is PHP-FPM affected, or only Apache mod_php?
The PHP advisory includes PHP-FPM, mod_php, php-cgi, FrankenPHP and LiteSpeed environments. Exposure and attack conditions vary by handler. PHP considered mod_php particularly high risk for the demonstrated attack.
Can an older PHP version still be patched?
Sometimes. Enterprise Linux vendors may backport security fixes while retaining an older upstream version. Verify the exact package and vendor advisory. PHP 8.1 and earlier are unsupported by the PHP project’s normal security process, although some vendors provide backports.
Can I publish a phpinfo() page to check the version?
Avoid exposing a public diagnostic page; it may reveal detailed server configuration. Use your hosting panel, WordPress Site Health or authorized internal diagnostics.
Does a WAF guarantee protection?
No. A WAF may reduce exposure to known traffic patterns, but cannot guarantee protection against every exploitation path. Apply the PHP security updates and verify the active runtime.
Official Sources
The vulnerability and mitigation information in this article was checked against official advisories on October 31, 2026. PHP releases and vendor backports can change; confirm the current package guidance before updating a production system.
Your website can look completely normal while its PHP runtime still needs an urgent security update.
A successful WordPress update, a clean-looking homepage or an apparently current CLI PHP version cannot independently establish that the production web runtime is patched.
The reliable process is to identify the real runtime, verify the vendor fix, update every affected environment and confirm that corrected workers are processing requests.
Do not stop at “the update installed.” Verify that protection is actually in effect.
