PHP Security Patches: Is Your Site on an Unpatched Version?

A PHP security update is a new point release of the PHP version your site runs, and on 21 October 2026 the PHP project shipped one that fixes two critical flaws. If your sites run PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 or newer, or an end-of-life version your host or vendor has patched, you have the fix. If you can't say which version each site runs, that is the first job, and this guide takes about 30 minutes. It extends our website maintenance checklist, and everything below reflects what was public on 6 November 2026.

What happened, and why owners panicked

PHP's own security advisory of 21 October 2026 says the fixed releases close two critical vulnerabilities that can allow unauthenticated remote code execution, meaning a stranger's web request could run code on the server. The identifiers are CVE-2026-109618 and CVE-2026-109619, and the PHP project's advisories rate both 9.2 on the CVSS v4 scale. PHP says the risk applies to all PHP installations serving web requests, highest on Apache's mod_php, and urged everyone to update immediately. Researchers and press nicknamed the pair "PHP2Shell", an unofficial name.

The panic had a simple cause: many owners found they couldn't answer "which PHP version is my site on?" Take a hypothetical clinic site built in 2019 by a freelancer, on a hosting plan nobody has opened since. Nobody knows its version or who can change it, and that gap is the real problem.

On 26 October 2026 the US agency CISA added both CVEs to its Known Exploited Vulnerabilities catalog. Its alert advised organisations to inventory systems running any version of PHP, patch internet-facing systems first, and take PHP-based systems offline if they can't update immediately or still run PHP 8.1 or earlier. I'm leaving out forum claims about who found the flaws or how many sites were hit; I couldn't confirm them at a primary source.

Find out what you're running

You can't update PHP on a website until you know which version it runs. You can find out without touching code; write every answer in one list.

From your hosting panel or WordPress dashboard

On cPanel hosting, MultiPHP Manager lists each domain with the PHP version it currently uses, and shows an "Inherited" label if it follows the server default. Other panels have a similar screen, and your host's support can read it out. In WordPress, an admin can open Tools, then Site Health, then Info, then Server to see the PHP version.

By asking your developer or agency

Ask in writing for each site's PHP version, framework or CMS version, host, login holder, last update date, and whether anyone restarts background workers after a PHP change. Patching has two layers. On 19 October 2026 Laravel published a critical advisory (rated 9.2) for its token-based API guard on MySQL or MariaDB, fixed in Laravel 13.29.0 and 12.68.0. That is separate from PHP's fix, so a patched PHP does not cover an old Laravel.

One trap: for PHP 8.1 and older, patched builds keep the same version number. Forge's guidance says to check the package revision rather than php -v, and cPanel records its backports in the package changelog. A bare 8.1.34 proves nothing about the fix.

Supported versus end-of-life PHP

PHP supports each branch for two years of active fixes and two more of critical security fixes, then it reaches end of life. The table shows where each branch stood on 6 November 2026, per php.net.

Look at the 8.2 row: its security support ends on 31 December 2026, so an 8.2 site can be patched today and still need an upgrade plan. Re-check php.net's supported-versions page before relying on this table.

Key figures from the public record

• 9.2 out of 10 (CVSS v4): the severity rating of each of the two PHP flaws, published 21 October 2026 in the PHP project's advisories for CVE-2026-109618 and CVE-2026-109619.
• 26 October 2026: the date CISA added both CVEs to its Known Exploited Vulnerabilities catalog, per the CISA KEV catalog (catalog version 2026.11.04).
• 31 December 2025: the date PHP 8.1 reached end of life, per php.net's end-of-life page, read on 6 November 2026.
• Roughly 10 times normal volume: the PHP upgrade jobs Laravel Forge says it received after the release, per Laravel's post-mortem of 4 November 2026.

Why your host may have patched you (and why that is not guaranteed)

On shared hosting the host controls the PHP build, so it may well have patched you already. WordPress.org's notice says as much: hosts may already be updating PHP and adding firewall rules, and owners should still check with their host.

Assuming goes wrong in a few ways. A cPanel PHP update comes in two parts. The release notes show EasyApache 4 builds 25.91 and 25.92, dated 21 October 2026, fixing both CVEs in ea-php74 through ea-php85. They also show cPanel's own internal PHP, which runs the control panel and webmail, being updated separately through a cPanel and WHM security update. One does not imply the other. A VPS is different again. A Laravel Forge PHP patch is manual: Forge's documentation states that its automatic security updates do not patch PHP, so you must update each server yourself.

Ask your host which PHP versions on your account are patched, and keep the written answer. Custom applications need one more step. A package upgrade restarts PHP-FPM, but queue workers, Horizon, Octane and other long-running CLI processes keep running the old PHP until someone restarts them, as the Forge guidance spells out. If your app sends email or processes orders through a queue, our guide to Laravel queue design, retries and observability covers why workers need a restart routine.

Forgotten sites: the one nobody can log into

The riskiest site is often the one you forgot you own: an old campaign site, a previous agency's microsite, a staging copy left running. Nobody patches it because nobody knows it exists.

Build the list from the outside in. Your domain registrar shows every domain you pay for, your card statements show hosting bills, and your DNS records show where each domain points. Add one row per site: domain, host, login holder, PHP version, and whether it earns anything.

For a site you can't log into, contact the host and be ready to prove you own the domain, because hosts usually ask. If nobody can regain access and the site does no work for you, taking it offline is a legitimate answer; CISA and WordPress.org both name it as an option when patching isn't possible. Our website hosting service exists partly for this: several sites under one account with one owner.

Not sure how many PHP sites you own, or whether each one is patched? We will list them, check each version and tell you what needs attention first.

Lessons from a platform's own post-mortem

Laravel's post-mortem of 4 November 2026 shows a well-resourced team stumbling on basics you also face. Three lessons carry over.

1. Know what you run. Laravel wrote that it had no reliable record of which software versions every application was running, and that some systems ran end-of-life software that had to be rebuilt instead of patched. Keep an inventory.
2. Everyone patches at once. Forge saw roughly ten times its normal PHP upgrade volume, and deployments shared a queue with those jobs and were starved. By Laravel's timeline about 48,000 jobs were queued at 16:43 UTC and about 4,800 deployments were cancelled for waiting too long. Deployments now run on their own queue. If your host or agency patches every client at once, expect delays.
3. An early all-clear can be wrong. At about 17:45 UTC on 21 October Forge told customers the queue was processed. Laravel calls that message premature, because the queue climbed again, and it is adding a soak period before announcing recovery. For you, "done" means you checked the version and tested the site afterwards.

Watch: Emergency Livestream - PHP Vulnerabilities: What You Need to Know Today and Do Right Now

A security briefing from the SANS Institute channel. Treat the PHP project's advisory as the reference for details.

Watch on YouTube: Emergency Livestream - PHP Vulnerabilities: What You Need to Know Today and Do Right Now

If you can't apply the PHP security update today: mitigations and their limits

The only complete fix is the update. The PHP advisory says its measures reduce exposure to specific attack paths but do not make an installation safe, so treat them as a short bridge.

For the first flaw, the advisory suggests setting memory_limit=-1 where applications can't override it, keeping post_max_size low (8M if you don't need uploads, 32M if you do), and enforcing request-size limits at the web server or proxy. For the second, it suggests setting session.upload_progress.enabled=0 in php.ini or the FPM pool configuration and restarting every worker, and on PHP 8.5 setting fatal_error_backtraces=0. It says plainly that these block only the confirmed paths.

Two more points. CISA says a web application firewall "may provide some protection", which is not the same as being patched. And PHP 8.1 and older still need an upgrade: Forge's guidance calls vendor backports "a stopgap rather than a long-term fix".

Make these changes only with someone who can test afterwards, because they apply server-wide and can interrupt uploads.

What not to copy from forum stopgaps

In the first week, forums and social posts were full of quick fixes. Some match the official list above. Others are unofficial and can break uploads, so I wouldn't copy them onto a live business site.

• Blocking all multipart requests. A suggestion to drop every multipart/form-data request at the firewall would also block contact forms with attachments, résumé uploads and media uploads.
• Switching off uploads site-wide. A blunt switch can break checkout, booking forms and admin screens that handle files.

My rule: the PHP advisory is the source of truth, a stopgap is temporary, and every change gets a named owner, a test and a removal date.

A PHP security update cadence template

If you have no routine, copy and adjust this one. It is a template, not a service level.

• Same day, on a critical PHP notice: open the inventory, message the host, record the answers.
• Within days: test on a staging copy, apply the update and restart workers.
• Monthly: compare each site's PHP, framework, CMS and plugin versions with the latest releases and log the check.
• Quarterly: check each PHP branch against php.net's supported-versions page and date any upgrade due within a year.
• After every update: confirm the version with php -v and php-fpm -v (or the package revision for older builds), test forms, checkout and logins, and write the date in a patch log.

Keep a rollback path before you change anything: our Laravel backup strategy guide covers setting up and testing restores.

What a maintenance plan should cover

Read any maintenance plan against this list; one that never mentions PHP covers plugins only. Our overview of website maintenance plans in India explains how to read a quote.

• A living inventory of every site, host, PHP version, framework and dependency.
• Named ownership of PHP and framework updates, and a way of hearing about advisories.
• Staging tests, restorable backups and a rollback plan.
• Worker restarts and re-tests of key journeys after each patch.
• Monitoring, a dated patch log, and a calendar for upgrading before a branch ends.

Moving old bespoke code off an end-of-life PHP version is development work, not routine maintenance, and belongs in custom web application development.

Seven questions: do I know what I'm running?

Answer yes or no. There is no score, only a colour.

1. Can you name every PHP site you own and its host?
2. Did you check each site's PHP version in the last month, from the panel or server rather than memory?
3. Is each version supported on php.net, with a security end date more than a few months away?
4. Is it written down who updates PHP and the framework: you, your developer or your host?
5. Do you hold written confirmation that the October patch was applied?
6. Do you have a pre-change backup you have actually restored?
7. After an update, does someone restart workers, test forms and checkout, and log the date?

Red: a "no" on question 1, 2 or 3. Start with the inventory and the host. Amber: yes to 1 to 3, but a "no" on 4 to 7. Fix the ownership and the routine. Green: all yes. Check again next month; versions and end dates move.

Running a Laravel or custom PHP application? We can list your PHP and framework versions, dependencies and background workers in one inventory.

Reference reading

• PHP news archive for 2026, including the 21 October security advisory
• Laravel Forge guide to patching PHP after the October 2026 release
• WordPress.org notice: Critical PHP Security Release
• cPanel release notes for EasyApache 4 and cPanel and WHM security updates

Frequently Asked Questions

Is my website affected by the October 2026 PHP vulnerabilities?

If your server runs PHP and you haven't confirmed a patched build, treat it as affected until you've checked. The PHP project says the risk applies to all PHP installations serving web requests, and WordPress.org notes no WordPress update is needed because the flaws sit in PHP. Ask your host or developer for the patch confirmation in writing.

How do I check my PHP version on shared hosting?

On cPanel, open MultiPHP Manager, which lists the PHP version each domain currently uses. In WordPress, go to Tools, Site Health, Info, Server. For PHP 8.1 or older, a matching number doesn't prove a backported fix, so ask the host to confirm the patched package.

Is PHP 8.1 safe if my host says it is patched?

It is only as safe as the vendor's backport, and PHP 8.1 reached end of life on 31 December 2025. Forge and cPanel shipped backports for the October flaws, but Forge calls them a stopgap. Plan an upgrade.

Do I need to restart anything after updating PHP?

Yes, if your app runs long-lived processes. Updating PHP restarts PHP-FPM, but queue workers, Horizon and Octane keep using the old PHP until restarted. Restart them, confirm the version, then test forms and checkout.

How often should I apply a PHP security update?

Apply security releases within days of a critical notice, review versions monthly and check end dates quarterly. Start the next-branch upgrade well before support ends; PHP 8.2's ends on 31 December 2026.