PHP vulnerability: which versions are safe and how to patch

If your website runs on PHP, update it now. On October 21, 2026, the PHP project released PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 to fix two critical flaws, CVE-2026-109618 and CVE-2026-109619, that can let an attacker run code on a web server without logging in. Every earlier release in the supported 8.2, 8.3, 8.4 and 8.5 branches is unsafe, and PHP 8.1 and older get no fix from the PHP project at all.

The two bugs, nicknamed PHP2Shell, sit in the PHP engine itself rather than in WordPress or any plugin, so they reach almost every PHP website: WordPress, WooCommerce, Drupal, Joomla, Laravel and custom applications alike. The Canadian Centre for Cyber Security issued Alert AL26-026 the same day and warned that internet-facing PHP servers are at heightened risk. It also said some websites might be temporarily unavailable while security patches were applied.

This guide covers the news first, then works from the basics to the advanced: what a CVE is, which PHP versions are safe, how to check yours, and how to keep WordPress, Apache or LiteSpeed, the Linux kernel, plugins and themes patched after this week. Facts are current as of October 24, 2026.

What happened with PHP this week

The PHP security team gave advance notice on October 20, 2026 of a critical release, both flaws rated 9.2 out of 10 on version 4.0 of the Common Vulnerability Scoring System. The fixed versions shipped on October 21. Linux distributions and extended-support vendors received the patches before the public release so their packages could follow quickly.

The official PHP advisory describes the two bugs this way:

• CVE-2026-109618, remote code execution through out-of-memory corruption. When PHP runs out of memory at the wrong moment, it can abort a request while internal request data is only partly set up. The cleanup step that runs afterwards may then treat that half-built data as valid. Several ways of sending oversized or malformed form uploads can trigger the condition.
• CVE-2026-109619, remote code execution through stale global state. Some internal state that belongs to one request can survive after its memory has been freed. A later request handled by the same PHP worker may use that stale state before it is reset.

Both are classed as use-after-free weaknesses (CWE-416), a family of memory bugs that attackers have turned into working exploits many times in other software. The PHP project says the risk is highest for Apache with mod_php, where it demonstrated an exploit in which an unauthenticated request triggers the attack before any application code runs. PHP-FPM, php-cgi, FrankenPHP and LiteSpeed are also listed as at risk.

Disclosure did not go smoothly. The PHP Foundation’s post on the release explains that the CVE numbers leaked on October 20 with a wrong release time and an incorrect score of 10.0, and that a researcher’s video showing a proof of concept was posted by mistake, deleted and copied widely. The foundation also wrote that the out-of-memory fix had stalled inside the security team for months, calling the delay a structural failure, and listed changes to how hard fixes will be handled.

As of October 23, 2026, neither the Cyber Centre nor the United States Cybersecurity and Infrastructure Security Agency (CISA) had confirmed active exploitation. The Cyber Centre wrote that this “can change quickly” and noted that a proof of concept is publicly available. CISA’s alert goes further than most advisories: it tells organizations to take PHP systems offline if they cannot be updated right away, or if they run unsupported PHP 8.1 or earlier.

Who is affected

Anyone running PHP that answers web requests on a version older than the fixed releases. That covers:

• business websites on shared, managed, VPS or dedicated hosting, whatever the content management system;
• online stores built on PHP platforms;
• intranets, client portals, booking systems and internal tools written in PHP;
• appliances, control panels and commercial products that bundle their own copy of PHP, which the Cyber Centre singles out as easy to miss;
• container images with an old PHP base image baked in.

Static websites with no PHP are not affected by these CVEs. Sites on fully managed platforms may already be patched, but confirm it with the provider rather than assume it.

What to do today

1. Inventory. List every website, application and server you own that runs PHP, including old staging copies and forgotten subdomains.
2. Check the running version on each one (the steps are below). The version the server package list shows and the version actually answering web requests can differ.
3. Update to a fixed release: 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or a vendor package that backports the fix. On managed hosting, ask your provider in writing which build each site runs.
4. Restart every PHP worker. The fix only takes effect once the old processes are gone. That means PHP-FPM pools, Apache (for mod_php) or the LiteSpeed PHP processes.
5. Move off PHP 8.1 and older. If you cannot, isolate those sites from the public internet until you can.
6. Watch your logs for PHP or web server processes starting shells, downloading files or making outbound connections they never made before.
7. Apply the interim setting for the third flaw (CVE-2026-115560, below) if your applications might be exposed.

Which PHP versions are safe and which are not

The table combines the fixed versions in the advisory with the support dates on php.net’s supported versions page and its end-of-life list, as of October 24, 2026.

A few points the table cannot show:

• PHP 8.2 is a short-term answer. Its security support ends on December 31, 2026, about ten weeks from now. Patch to 8.2.35 today, then plan the move to 8.3 or 8.4 before year end.
• Old branches are affected too. The NVD record for CVE-2026-109619 lists versions back to PHP 5.4 as vulnerable, and the record for CVE-2026-109618 goes back to PHP 7.3. Because of the severity, the PHP security team published minimal source patches for 7.4, 8.0 and 8.1 for people who build PHP themselves, but there are no official 8.1, 8.0 or 7.4 releases.
• Backported vendor packages count. Enterprise Linux distributions, hosting control panels and extended-support vendors often keep an older version number and patch it. In that case the vendor’s security notice, not the version string, tells you whether the build is fixed.
• Development releases. PHP 8.6 is still a release candidate. RC4, published October 21, includes the fixes, but release candidates are for testing, not production.

The third flaw that is still open: CVE-2026-115560

On October 23, 2026, the PHP project published an informational advisory about a separate remote code execution issue, CVE-2026-115560, which the October 21 releases do not fix. It only appears under an unusual combination: an application sets session.serialize_handler to php_binary or php_serialize, switches it to php at runtime with ini_set() before starting the session, and leaves session upload progress turned on.

The interim protection is one setting, applied in php.ini or the PHP-FPM pool, followed by a restart of every worker:

session.upload_progress.enabled = 0

If you already applied this setting for CVE-2026-109619, keep it. The PHP project plans a full advisory and fix with the next regular release. The Cyber Centre added the issue to its alert in Update 1 on October 23.

What a CVE is, in plain words

Security news is full of acronyms. Here is what each one means and how they fit together.

CVE: the name tag

CVE stands for Common Vulnerabilities and Exposures. A CVE ID such as CVE-2026-109618 is a unique label for one publicly known security flaw, so that a vendor, a hosting company, a scanner and a government alert all mean the same bug. The year in the ID is the year the number was assigned, not always the year the bug was found. The CVE program hands out IDs through CVE Numbering Authorities; the PHP project is one, and it issued both PHP2Shell IDs. A CVE ID by itself tells you nothing about severity.

CVSS: the severity score

The Common Vulnerability Scoring System rates a flaw from 0 to 10 based on how it can be attacked and what an attacker gains. Scores of 9.0 and up are “critical”. The score describes the flaw in general, not your risk: a 9.2 bug in a feature you have turned off may matter less to you than a 6.5 bug in your login page.

Two scores often appear for the same CVE. The PHP project scored both flaws 9.2 under CVSS version 4.0. The National Vulnerability Database analysts scored them under version 3.1, at 9.8 for CVE-2026-109618 and 8.1 for CVE-2026-109619. The versions use different formulas, and the analysts made different judgments about attack complexity. All of the scores land in high or critical territory, which is what matters for your patching order.

CWE: the type of mistake

The Common Weakness Enumeration names the kind of programming error behind a flaw. CWE-416 is “use after free”: a program keeps using a piece of memory after giving it back. SQL injection (CWE-89) and cross-site scripting (CWE-79) are other common entries. CWE helps developers fix whole classes of bugs instead of one bug at a time.

NVD: the reference library

The National Vulnerability Database, run by the United States National Institute of Standards and Technology, enriches each CVE with scores, weakness types and lists of affected products. It is the most common place scanners and security tools look up a CVE.

KEV: the “being exploited” list

CISA’s Known Exploited Vulnerabilities catalog lists flaws with reliable evidence of exploitation in real attacks. A CVE on that list moves to the top of any patch queue. As of the catalog update on October 23, 2026, the two PHP2Shell CVEs were not on it. Several older PHP flaws are, including CVE-2024-4577, an argument-injection bug in php-cgi on Windows. Absence from the list is not a reason to wait; it only means evidence had not been confirmed yet.

Advisories: the instructions

An advisory is the document that tells you what to do: affected versions, fixed versions and interim protections. Vendors publish their own (php.net, wordpress.org, LiteSpeed, Apache), and national agencies publish summaries. In Canada, that is the Cyber Centre’s alerts and advisories page, which carried both the PHP alert AL26-026 and advisory AV26-1070 this week.

How to check your PHP version

Pick the method that matches your access. Check each site separately: one server can run several PHP versions at once, one per site.

In the WordPress dashboard

Go to Tools, then Site Health, then the Info tab, and open the Server section. The PHP version shown there is the one actually running the site, which makes it the most reliable check for most owners. The Status tab also warns when a site runs an outdated PHP version.

In your hosting control panel

Most panels have a “PHP version”, “MultiPHP Manager” or “Select PHP version” screen that shows the version assigned to each domain. It shows the branch (8.3, for example) but often not the patch level (8.3.36). Ask your host for the patch level if the panel does not show it.

On the command line

With shell access, these commands help:

php -v
php -r 'echo PHP_VERSION, PHP_EOL;'
ps aux | grep -E 'php-fpm|lsphp|httpd' | head

The first two show the command-line PHP, which can differ from the PHP serving your website. The third shows which PHP processes are running, so you can confirm that old workers were restarted after an update.

From the outside

Some servers announce their PHP version in an HTTP header:

curl -sI https://example.com | grep -i x-powered-by

If this prints a version, your server is advertising it to every scanner on the internet. Turning off expose_php (covered below) removes the header. Its absence does not prove you are patched.

If you create a phpinfo() page to check, give it a random name and delete it straight after. A forgotten phpinfo page hands attackers a detailed map of your server.

Updating PHP without breaking your site

A patch-level update, such as 8.3.35 to 8.3.36, fixes bugs within a branch and rarely breaks anything. Apply it now. A branch upgrade, such as 8.1 to 8.3, can break older themes and plugins that use removed functions, so it deserves a short test cycle:

1. Take a full backup of files and database, and confirm you can open it.
2. Clone the site to a staging copy and switch the staging copy to the new branch.
3. Turn on error logging (not on-screen errors) and click through the pages that matter: home, contact forms, checkout, member login, search.
4. Update or replace any plugin or theme that throws deprecation warnings or fatal errors.
5. Switch production during a quiet period, then watch the error log for a day.

WordPress recommends PHP 8.3 or greater on its requirements page, along with MariaDB 10.11 or MySQL 8.0 or newer. WordPress still runs on PHP 7.4, but the same page warns that end-of-life versions may expose a site to security vulnerabilities, and this week showed what that means in practice.

If an urgent branch upgrade is blocked by one old plugin, that plugin is the real problem. A site held on PHP 8.1 by an unmaintained component cannot be patched against PHP2Shell through official releases.

Updating WordPress core, plugins and themes safely

PHP2Shell is an engine flaw, but most break-ins on WordPress sites still come through plugins and themes. A sound update routine covers all of them.

WordPress core

As of October 2026, the current release is WordPress 7.1.3, a maintenance and security release published on October 6, 2026; 7.2 is in beta. WordPress installs minor releases (7.1.2 to 7.1.3, for example) automatically by default. Leave that on. Major releases (7.1 to 7.2) deserve a staging test, but not a long delay: security fixes are aimed at current releases, and every month spent on an old major version adds risk.

Plugins and themes

• Turn on automatic updates for plugins with a good track record and for security-critical ones (forms, login, ecommerce). Since WordPress 5.5 you can do this per plugin from the Plugins screen.
• Review the rest weekly. Read the changelog. “Security fix” in a changelog means update today.
• Delete what you do not use. A deactivated plugin’s files are still on the server and can still be reached directly. Remove inactive themes too, keeping one default theme as a fallback.
• Only install from trusted sources: the WordPress.org directory or the developer’s own site. “Nulled” (pirated) premium plugins and themes are a common way malware arrives.
• Watch for abandonment. A plugin with no update in a year, or one marked “closed” in the WordPress.org directory, needs a replacement plan.

The safe order of operations

1. Back up files and database.
2. Update on staging first when the site is complex or sells online.
3. Update plugins, then themes, then core, one group at a time, so you know which change caused a problem.
4. Clear every cache layer (plugin cache, server cache, content delivery network).
5. Test the forms, the checkout and the login.

For the full WordPress hardening checklist, from logins and administrator accounts to HTTPS and file editing, see our guide on how to secure a WordPress website.

Apache and LiteSpeed: updates and hardening

The web server sits in front of PHP and decides what reaches it. Keeping it current and tightly configured reduces what any PHP flaw can do.

How the web server talks to PHP matters

The PHP advisory rates the risk highest for Apache with mod_php, where PHP runs inside the Apache process itself. Many hosts moved away from mod_php years ago because every Apache worker carries PHP and runs with the same permissions. If you still use it, this week is a good reason to switch to PHP-FPM, which runs PHP in separate pools, each under its own user. That keeps one site from reading another and lets you restart PHP without restarting the web server.

LiteSpeed runs PHP through its own LSAPI interface and LSPHP builds. The advisory lists LiteSpeed among the at-risk setups, so LiteSpeed servers need the patched PHP build like any other. LiteSpeed can keep PHP processes alive across web server restarts (its detached mode), so check its documentation on docs.litespeedtech.com for how to restart PHP itself, then confirm the running version.

Keep the web server itself patched

• Apache HTTP Server: as of October 2026, the current 2.4 release is 2.4.69, published October 1, 2026, which fixed 20 CVEs rated moderate or low. The project lists every fixed flaw on its Apache 2.4 vulnerabilities page. Most servers get Apache from the operating system or control panel vendor, so apply their packages rather than building from source.
• LiteSpeed Web Server: the stable 6.3.7 release of September 23, 2026 included security fixes, including tighter validation of internal redirects. LiteSpeed publishes them in its release log.

Web server hardening that limits PHP flaws

• Cap request sizes at the web server or proxy: total body size, number of form fields, upload parts and headers. The PHP advisory recommends these limits as a partial defence against the out-of-memory flaw, including for requests with no usable Content-Length header.
• Block PHP execution in upload folders. In WordPress, nothing in wp-content/uploads should ever run as PHP. A deny rule for .php files in that folder stops a common malware pattern.
• Hide version banners. In Apache, ServerTokens Prod and ServerSignature Off stop the server from announcing its exact version.
• Turn off directory listing (Options -Indexes in Apache) so visitors cannot browse folders without an index page.
• Use modern TLS only. Disable old protocol versions and keep certificates renewing automatically.
• Rate-limit login and form endpoints such as wp-login.php and xmlrpc.php, or disable XML-RPC if nothing on the site needs it.

The operating system and the Linux kernel

PHP runs on an operating system, usually Linux, and a flaw in the kernel can turn a small foothold into full control of the server. Patching the kernel follows the same logic as patching PHP, with one difference: a new kernel only takes effect after a reboot or a live patch.

Where kernel fixes come from

The kernel developers publish releases on kernel.org. As of October 24, 2026, the latest stable kernel is 7.2.12, and the longterm branches still receiving fixes are 6.18, 6.12, 6.6, 6.1, 5.15 and 5.10. Hardly anyone running a web server installs those directly. Your distribution (Ubuntu, Debian, Red Hat Enterprise Linux and its rebuilds, CloudLinux and others) takes the upstream fixes, backports them into its own kernel version and publishes security notices. Follow your distribution’s notices, not the kernel.org version numbers.

Patching routine

# Debian and Ubuntu
sudo apt update && sudo apt upgrade
[ -f /var/run/reboot-required ] && echo "Reboot needed"

# Red Hat family
sudo dnf upgrade
sudo dnf needs-restarting -r

# Which kernel is running now
uname -r

Compare the running kernel from uname -r with the newest installed kernel package. If they differ, the server is still running the old, unpatched kernel.

Live patching, in concept

Live patching applies a security fix to the running kernel in memory, without a reboot. Several distributions and commercial services offer it. It is useful for servers that cannot reboot often, but it covers only the fixes the provider chooses to ship as live patches, and it does not replace the full kernel update. Plan a reboot into the current kernel during a maintenance window, even when live patching is in place.

Services need restarts too

Updating a library such as OpenSSL or glibc on disk does not change programs already running. After major updates, restart the services that use those libraries (web server, PHP, database, mail) or reboot. The same tools that report a needed reboot can usually list services still running old code.

Unsupported operating systems

An operating system past its vendor’s end of life gets no kernel or library fixes, whatever PHP version runs on top of it. If your server runs an end-of-life release, the operating system upgrade belongs in the same plan as the PHP upgrade.

PHP hardening settings worth knowing

Hardening does not fix a flaw like PHP2Shell; only the update does. It limits what an attacker can do after finding any weakness, in PHP or in your own code.

Settings in php.ini or the FPM pool

• expose_php = Off removes the X-Powered-By header that announces your version.
• display_errors = Off and log_errors = On keep error details out of the browser and in the log, where you can read them.
• allow_url_include = Off (the default) stops PHP from including code from remote URLs. Never turn it on.
• disable_functions blocks functions an application does not need. Functions that run system commands (exec, shell_exec, system, passthru, proc_open, popen) are the usual candidates. Test first: some backup, image and email tools rely on them. This setting can only be set in php.ini or server configuration, not by the application.
• open_basedir restricts the folders PHP can open, for example to the site’s own directory and a temporary folder. It is a useful guard rail on multi-site servers, not a sandbox: a code execution flaw in the engine can get around it.
• session.cookie_secure = 1, session.cookie_httponly = 1 and session.cookie_samesite = Lax make session cookies harder to steal or misuse.
• upload_max_filesize and post_max_size should be no larger than the site needs.

Interim settings for PHP2Shell, only until you update

The PHP advisory lists measures that reduce exposure if an update is delayed by hours or days. The project is clear that none of them makes an installation safe:

• for CVE-2026-109618, set memory_limit=-1 in a way applications cannot override, such as php_admin_value in the FPM pool or Apache configuration, and set a low post_max_size (8M for sites without uploads, 32M with them), keeping upload_max_filesize below it;
• for CVE-2026-109619, set session.upload_progress.enabled=0, and on PHP 8.5 also fatal_error_backtraces=0, in php.ini or the FPM pool, then restart every worker (an ini_set() call or a .user.ini file is too late);
• contain each PHP worker with a container or cgroup memory limit, and do not use RLIMIT_AS or RLIMIT_DATA, which the advisory warns can cause the very allocation failure the attack relies on.

An unlimited memory limit lets one runaway script use a lot of memory, so remove these interim settings once the fixed version is running, apart from the session upload progress setting, which stays until CVE-2026-115560 is fixed.

One PHP version and one pool per site

On servers that host several sites, give each site its own PHP-FPM pool running as its own system user. One compromised site then cannot read another site’s files or database password. Most hosting panels support a separate PHP version per site, which lets you upgrade sites one at a time instead of waiting for the slowest one.

Web application firewalls and server firewalls

A firewall is a filter between the internet and your site. There are two kinds, and they do different jobs.

Web application firewall

A web application firewall (WAF) inspects each web request and blocks patterns that match known attacks: SQL injection strings, attempts to reach admin files, oversized or malformed uploads, and requests matching signatures for newly published CVEs. It can run on the server, as a plugin inside the application, or at a cloud proxy in front of the site. After PHP2Shell, CISA named a WAF as a way to get some protection until patching is complete.

That protection is partial. A WAF filters known patterns. Attackers vary their requests to slip past rules, and a flaw that triggers before any application code runs is exactly the case where a plugin-level WAF inside WordPress sees nothing. A WAF buys time; the update closes the hole.

Server firewall

A server or network firewall decides which ports and addresses can reach the machine at all. A web server usually needs ports 80 and 443 open to everyone and little else. Administration ports such as SSH, database ports and control panels should be limited to known addresses or reached through a VPN. Brute-force protection that bans addresses after repeated failed logins belongs here too.

What a good setup looks like

• Only the ports the site needs are open to the public.
• Admin access is limited by address, VPN or both, and protected with keys or multi-factor authentication.
• WAF rules update automatically, and someone reviews what they block.
• Outbound connections from the web server are limited where possible, so malware has a harder time calling home or downloading tools.

Backups and recovery

A good backup turns a break-in into a recovery job instead of a rebuild from scratch. It only helps if it lives outside the server, goes back far enough, and actually restores.

• Follow the 3-2-1 idea: three copies, on two kinds of storage, with one off-site. A backup stored only on the same server disappears with the server, or gets encrypted along with it.
• Back up files and database together, on a schedule that matches how often the site changes. An online store that takes orders all day needs more frequent database backups than a brochure site.
• Keep history. Malware often sits quietly for weeks. If you keep only seven days of backups, every copy may already contain it. Keep weekly and monthly copies as well.
• Protect the backups with separate credentials, and where possible with storage that cannot be changed or deleted for a set period.
• Never leave backups in the web root. A ZIP or SQL file in public_html can be downloaded by anyone who guesses the name, with every password and customer record inside.
• Test a restore to a staging location at least every quarter.

Write down how long the business can be offline and how much data it can afford to lose. Those two answers set the backup schedule and tell you whether restoring from yesterday is acceptable.

How to monitor CVEs without drowning in them

Many thousands of CVEs are published every year. You only need the ones that touch the software you run. Start with these official feeds:

• PHP: the news and security announcements on php.net and the php-src security advisories on GitHub.
• WordPress: release posts on wordpress.org/news, which label security releases in the title.
• Your web server: the Apache security page or the LiteSpeed release log linked above.
• Your operating system: your distribution’s security notices mailing list or feed.
• Canada: the Canadian Centre for Cyber Security alerts and advisories. Alerts (AL numbers) flag urgent, widespread issues; advisories (AV numbers) track vendor patches.
• Exploitation: CISA’s Known Exploited Vulnerabilities catalog, which also offers a machine-readable feed.

Then build a short routine:

1. Keep an inventory: every site, its PHP version, its CMS version, its plugins and themes, its server and operating system.
2. Match new advisories against that inventory weekly, and daily when a major alert is out.
3. Decide patch windows by severity: critical and exploited flaws within a day or two, high within a week or two, the rest in the next routine cycle.
4. Record what was patched and when, so you can answer “were we exposed?” later.

Version scanners and dependency checkers can automate the matching, but someone still has to read the advisory and judge whether the vulnerable feature is in use.

Advanced: the risks behind the headlines

The steps above handle this week’s emergency. These are the habits that decide how the next one goes.

Software supply chain

Your site is built from other people’s code: PHP, the CMS, plugins, themes, Composer and npm packages, container base images, the hosting panel. Each one is a link in the chain. PHP2Shell showed how far one link reaches: a flaw in the language engine touched every application built on it. Keep a software bill of materials, even a simple spreadsheet, listing each component and version. Pin dependency versions with a lock file, review updates before deploying them, and rebuild container images when the base image is patched. An image built last month contains last month’s PHP.

Abandoned plugins and themes

A plugin whose developer has walked away will never get a fix, however serious the next flaw. Check the last update date and support activity of every plugin and theme twice a year. Plan replacements before they become urgent. Custom themes and plugins built years ago deserve the same review: if no one maintains the code, no one will update it for a new PHP branch, and it will hold the whole site back.

Least privilege

Every account and process should have only the access it needs:

• separate administrator accounts for each person, never one shared login;
• editors and authors with the Editor or Author role, not Administrator;
• a database user per site with rights to that site’s database only;
• PHP running as an unprivileged user, never as root;
• hosting, domain and DNS accounts owned by the business, with access granted to suppliers individually and removed when the work ends.

File permissions

The WordPress hardening documentation recommends 755 for directories and 644 for files, with wp-config.php readable only by you and the web server, which generally means 400 or 440. Never use 777. Adding define( 'DISALLOW_FILE_EDIT', true ); to wp-config.php turns off the theme and plugin editors in the dashboard, so a stolen admin login cannot be used to paste code into a theme file.

Two-factor authentication everywhere that matters

Turn on two-factor or multi-factor authentication for WordPress administrators, the hosting account, the domain registrar, DNS, email and any code repository. An authenticator app or a hardware security key is stronger than text message codes. With a second factor in place, a stolen password is no longer enough on its own.

Incident response: what to do if you think you were hit

Patching closes the door; it does not remove anyone who came in before. Signs worth investigating include new administrator accounts, unfamiliar PHP files (especially in uploads folders), changed core files, unexpected scheduled tasks, spam pages appearing in search results, and outbound connections from PHP processes.

1. Contain. Take the site offline or into maintenance mode if it is actively serving malware or leaking data. Isolate the server if you can.
2. Preserve evidence. Copy logs (web server, PHP, authentication) and a snapshot of the files and database before you change anything.
3. Find the way in and the scope. Work out when the compromise started, which accounts were used and what was changed or taken.
4. Eradicate. Rebuild from a known-clean backup made before the compromise, or reinstall core, plugins and themes from official sources, then remove unknown files and accounts.
5. Rotate every secret: administrator, hosting, database and FTP or SFTP passwords, API keys, and the WordPress salts in wp-config.php.
6. Patch and harden before going back online, so you do not reopen the same hole.
7. Report and notify. You can report incidents to the Cyber Centre. If personal information was involved, Canada’s federal private-sector privacy law (PIPEDA) requires organizations to report breaches of security safeguards that create a real risk of significant harm to the Office of the Privacy Commissioner of Canada, notify affected individuals, and keep a record of every breach for two years. Provincial laws can add their own duties. This is general information, not legal advice.
8. Review. Write down what happened and what will change, while it is fresh.

Disclosure is getting faster

One more lesson from this week: the time between a flaw becoming public and attacks starting keeps shrinking. The CVE IDs leaked a day early, and a proof-of-concept video circulated before most servers were patched. Plan on hours, not weeks, for critical flaws in internet-facing software, and keep the inventory and backup work done in advance so an emergency release is a routine update rather than a scramble.

If you would rather have specialists handle the inventory, patching and hardening across your sites and servers, our cyber security services team can review your setup and send a custom proposal.

PHP security checklist

Today

• List every site, server and product that runs PHP.
• Confirm each one runs PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35 or later, or a vendor build with the fix.
• Restart all PHP workers and confirm the running version.
• Isolate any PHP 8.1 or older site from the internet until it is upgraded.
• Set session.upload_progress.enabled=0 until CVE-2026-115560 is fixed.
• Check logs for PHP processes starting shells or making unexpected outbound connections.

This week

• Update WordPress core, plugins and themes, and delete unused ones.
• Patch the web server and operating system, and reboot into the current kernel.
• Turn off expose_php and on-screen errors, and block PHP execution in upload folders.
• Confirm off-site backups exist and test one restore.
• Turn on two-factor authentication for every administrator, hosting and domain account.

Before December 31, 2026

• Move every PHP 8.2 site to 8.3 or 8.4.
• Replace abandoned plugins and themes.
• Give each site its own PHP pool and system user.
• Subscribe to the PHP, WordPress, web server, operating system and Cyber Centre advisory feeds.
• Write a one-page incident response plan with names and phone numbers.

Frequently asked questions

Which PHP versions are affected by PHP2Shell?

Every PHP release before 8.5.12, 8.4.27, 8.3.36 and 8.2.35 in the supported branches is affected by CVE-2026-109618 and CVE-2026-109619, and so are end-of-life branches such as 8.1, 8.0 and 7.4, which get no official fix. Update to a fixed release, or a vendor package that backports the fix, and restart every PHP worker.

Is PHP 7.4 still safe to use?

No. PHP 7.4 reached end of life on November 28, 2022, gets no official security releases, and is among the versions the October 2026 PHP flaws affect. Move to PHP 8.3 or 8.4 after testing your site on a staging copy.

Is PHP 8.1 outdated?

Yes. PHP 8.1 reached end of life on December 31, 2025, and the PHP project did not release a fixed 8.1 version for PHP2Shell. Some extended-support vendors backport fixes, but the safer path is an upgrade to a supported branch.

How long will PHP 8.3 be supported?

PHP 8.3 receives security fixes until December 31, 2027. PHP 8.4 is supported until December 31, 2028 and PHP 8.5 until December 31, 2029, as listed on php.net.

What is the best PHP version for WordPress in 2026?

WordPress recommends PHP 8.3 or greater. For most sites, PHP 8.3 or 8.4 at the latest patch level (8.3.36 or 8.4.27 as of October 2026) is a sound choice, once your theme and plugins pass a staging test.

Is PHP end of life?

The language is not. PHP 8.4 and 8.5 are in active support and PHP 8.6 is in testing. Individual branches do reach end of life: 8.2 stops getting security fixes on December 31, 2026, and 8.1 and older are already unsupported.

Why are some websites down because of PHP?

Some organizations took PHP sites offline as a precaution while they patched. The Canadian Centre for Cyber Security advised isolating internet-facing PHP applications from public networks where immediate patching is not possible, and some websites were temporarily unavailable while patches were applied.

Who found the PHP vulnerability?

The first signs of the out-of-memory flaw turned up in 2024 while a PHP core developer was fixing an issue from an external security audit of PHP. Independent security researchers then reported the full remote code execution problem in August and September 2026, and the PHP project released fixes on October 21, 2026.

Does a firewall protect my site if I cannot update yet?

Only partly. A web application firewall can block some attack patterns and buy time, but the PHP project says only an update is a complete fix. Patch first, and use a firewall and the interim settings in this guide only to cover the gap. Our cyber security services team can help with patching and hardening.