Critical PHP Security Updates: How to Protect Your Website
Reviewed
Update the software that runs your website
PHP runs many websites, including WordPress. Two critical flaws, CVE-2026-109618 and CVE-2026-109619, can let an attacker run code remotely without signing in. That can put website files, stored information, and the affected hosting account at risk. PHP advisory: memory handling; PHP advisory: stale state.
In plain language, one flaw involves memory left in an unsafe state after an allocation fails. The other involves a PHP worker reusing state from an earlier request. Treat web-serving PHP installations as needing review; the exact attack path depends on the runtime, application, and configuration.
Use a supported, patched release
The initial PHP releases fixing both flaws were:
| PHP branch | Initial fixed release |
|---|---|
| 8.2 | 8.2.35 |
| 8.3 | 8.3.36 |
| 8.4 | 8.4.27 |
| 8.5 | 8.5.12 |
Choose the latest supported patched release compatible with your website, or obtain your operating-system or hosting vendor’s explicit confirmation of a security backport. A backport puts a fix into an older package, so its displayed PHP version may not match this table. Check the vendor’s advisory and exact package build; a version label alone is not proof. The table records the initial fixes, not a promise that these versions will always be the newest.
A practical update checklist
- Inventory every PHP installation. Include each website and PHP worker pool, command-line and scheduled-job runtimes, containers, bundled applications, staging environments, and separate hosting accounts. Different sites on one server can use different PHP builds.
- Back up and prepare recovery. Protect website files, databases, and necessary configuration. Check that recovery works and test application compatibility where possible. If an update fails, seek a safe recovery path rather than quietly leaving a vulnerable runtime online.
- Install trusted vendor updates. Use your host’s supported update process or the official operating-system/PHP distribution source. Updating WordPress, themes, or plugins alone does not patch the server’s PHP runtime. Keep those components current too. WordPress explains the distinction.
- Restart affected workers and services. Follow your vendor’s procedure so old PHP processes stop serving requests. Updating files on disk is not enough if workers are still running the old code.
- Verify the web runtime. Confirm the build serving each website after the restart, using an authenticated hosting panel or a controlled runtime check. A command-line version check may inspect a different installation. For backports, retain the vendor’s patch confirmation. Recheck essential site functions; remove any temporary diagnostic page instead of leaving server information exposed. PHP runtime version documentation.
On shared hosting? Ask your host to confirm the exact patched build or backport serving your site, completion of worker restarts, and whether the follow-ups below apply. Do not assume a WordPress update or a hosting-panel version selector completed the server patch.
Firewalls, filtering rules, and temporary configuration changes can reduce particular attack paths, but they do not replace patching. Have a qualified administrator assess temporary measures and their operational impact.
SEPARATE UPDATE · OCTOBER 23, 2026
Session-upload-progress follow-up
This follow-up applies when upload progress is enabled and an application configures session.serialize_handler as php_binary or php_serialize, then uses ini_set() to switch it to php before session_start(). PHP recommends session.upload_progress.enabled=0 pending the next regular bugfix release; keep it disabled if already mitigated. Applications that never change the handler at runtime may leave the feature enabled. This additional vector is tracked as CVE-2026-115560. For affected applications, an administrator should apply the setting before request parsing and restart PHP workers; changing it inside a PHP page is too late. The initial fixes above do not remove this additional review. PHP’s October 23 notice.
SEPARATE UPDATE · OCTOBER 26, 2026
Windows packages rebuilt for Brotli
PHP’s rebuilt Windows packages are 8.2.35-1, 8.3.36-1, 8.4.27-1, and 8.5.12-1. They bundle Brotli 1.2.1 for CVE-2026-111497, a decoder out-of-bounds write. The Windows cURL extension can reach the decoder when an application enables automatic HTTP-response decompression; cURL leaves that off by default. The -1 marks a dependency rebuild, not a new PHP runtime version. Windows package users should check the package revision; other vendors must confirm their own dependency fixes. PHP’s October 26 notice.
If you suspect compromise
Isolate the affected system from further exposure, preserve logs and other evidence, and obtain qualified incident-response help. Avoid wiping or rebuilding it before evidence is preserved. Patching prevents vulnerable code from remaining in service; it does not establish that an attacker has been removed.
Official sources
This article provides general guidance. It does not report an audit, patch deployment, or security verification of WGS systems or any customer website.