Contact

What Business Owners Need to Know About the Critical Flaw Affecting WordPress and PHP Websites

(Intro)

A critical security flaw has been found in PHP, the software that runs WordPress and a large share of business websites, online shops and customer portals. It could let an attacker take control of a website's server without needing a password. PHP released the fix on 21 October 2026 and advises everyone to update immediately, so any business with a PHP-based website needs it applied now. The flaw is being reported under the name PHP2Shell.

WordPress and PHP Websites at Risk ⊹ Blog ⊹ BN Digital
Fig. 0

Last updated 21 October 2026, 14:15 UTC, after PHP published its official security advisory and fixed versions.

What has happened, in plain terms

PHP is the programming language that powers many websites, online shops and customer portals. It runs out of sight, much like an engine under a car's bonnet: few people think about it until something goes wrong.

On 20 October, the team behind PHP announced two serious security flaws, both rated critical (9.2 out of 10). The fix was released on 21 October as PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12, with an official advisory telling everyone to update now.

Details leaked online before the fix was ready, which is why the flaw already has a name, PHP2Shell, taken from a leaked hacking tool. PHP has now confirmed two flaws that can let an attacker run their own commands on a website's server without logging in. Its advisory describes a working attack against one common server setup that can be triggered before the website's own code even runs. Code claiming to exploit the flaws is circulating online. PHP's advisory does not report attacks in the wild, although one security company reports attacks since the morning of 21 October.

What it could mean for a business

An attacker able to run commands on a website's server can do almost anything with it. For a business, that can mean:

  • Stolen data: customer details, orders, enquiries and staff logins taken from the site.
  • Tampered pages: fake payment forms, scam links or malware added to the site, often unnoticed.
  • Downtime: the site taken offline or defaced.
  • Regulatory and reputational exposure: a breach of customer data may have to be reported to the regulator (for example under GDPR) and to the people affected.

Now that the fix and full technical details are public, automated scanning for unprotected sites typically begins within hours, because the fix itself shows attackers where to look. Small and mid-size businesses are targeted as readily as large ones.

Which websites are at risk

PHP's advisory says every PHP installation that serves web pages is at risk, whatever the hosting setup. That includes:

  • WordPress and WooCommerce sites
  • Drupal, Joomla and Magento (Adobe Commerce) sites
  • Sites built with Laravel or other PHP frameworks
  • Many custom-built websites and customer portals

Older websites need the most attention. PHP itself only issues fixed releases for versions 8.2 and newer. For 7.4, 8.0 and 8.1 it has published minimal source fixes that a hosting provider or developer has to build and install, and some Linux distributions and support vendors provide their own. Anything older gets no fix at all and will need an upgrade, extra protection or to be taken offline.

Are WordPress sites at risk?

Potentially, yes. WordPress runs on PHP, so a WordPress site is exposed if the PHP on its server is. The flaw sits in PHP itself rather than in WordPress, a theme or a plugin, so updating WordPress or its plugins from the dashboard does not fix it. The fix has to be applied on the server, usually by the hosting provider or whoever manages the website. The same applies to WooCommerce, Drupal, Joomla, Magento and Laravel sites.

How to check which version of PHP a website uses

  • WordPress: Tools → Site Health → Info, then the Server section, shows the PHP version.
  • Hosting control panels: cPanel and similar panels show it on a PHP version or MultiPHP Manager page.
  • Managed hosting: the provider's dashboard or support team can confirm both the version and when the fix will be applied.

A site is protected once it runs PHP 8.2.35, 8.3.36, 8.4.27, 8.5.12 or later. Anything below those numbers is vulnerable. A site on 8.1 or older is running software that PHP no longer updates, and 8.2 itself stops receiving fixes at the end of 2026, so sites on 8.2 should plan a move to a newer version.

What business owners should do today

Business owners whose website is managed by someone else should put these questions to their web provider or developer today:

  1. Does the website run on PHP, and which version?
  2. Has the 21 October PHP security update (8.2.35, 8.3.36, 8.4.27 or 8.5.12) been applied, and if not, by when?
  3. Until the fix is applied, has the recommended temporary safeguard been put in place?
  4. Is the PHP version still supported? If not, what is the upgrade plan?
  5. Is there a recent backup of the website and its database?
  6. After the update, will the site be checked for signs of tampering, with written confirmation?

For BN Digital clients

For websites BN Digital looks after, the team is applying the fix following its release, using the temporary safeguards where it is safe to do so, and checking each site afterwards. Each client will receive written confirmation once their site is patched. Clients on older PHP versions will be contacted directly with options. Questions can go to the usual BN Digital account manager, or through the contact form.

Technical details for IT teams

  • Official severity: two vulnerabilities, each CVSS v4.0 9.2 (Critical).
  • Release: 21 October 2026. Official advisory: Critical remote code execution vulnerabilities, update now.
  • Fixed versions: 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Every earlier release on these branches is affected. PHP 8.1 and older receive no official release; minimal source backports for 7.4, 8.0 and 8.1 are published in php-src branches named CVE-2026-109618-109619, and some distributions and LTS vendors provide their own.
  • CVE IDs: CVE-2026-109618 (GHSA-w8hw-w9fx-j79w, remote code execution via out-of-memory corruption) and CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp, remote code execution via stale global state). Both CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H.
  • Root cause: for CVE-2026-109618, PHP's longjmp()-based out-of-memory handling can abort a request while request data is only partly initialised, and request shutdown then treats that data as valid; oversized multipart requests are a demonstrated trigger. For CVE-2026-109619, request-owned global state (error, session, object and extension state) can outlive its memory, and a later request on the same worker can use it before initialisation resets it (use-after-free).
  • Affected setups: all PHP installations serving web requests, including PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed. PHP rates mod_php highest risk: full remote code execution was demonstrated with an unauthenticated request before any application code runs, with default input and memory limits. For PHP-FPM, CVE-2026-109619 was validated through session upload progress; CVE-2026-109618 rests on source analysis.
  • Exploitation: PHP's advisory describes a demonstrated exploit but no in-the-wild exploitation. Patchstack reported exploitation since the morning of 21 October; Huntress had seen none as of 20 October. Unverified proof-of-concept code is circulating publicly.

Workarounds (not a substitute for updating)

PHP states that these workarounds do not make an installation safe and that updating is the only complete fix. For hosts that cannot be updated immediately:

  • Session upload progress (CVE-2026-109619): set session.upload_progress.enabled=0 in php.ini, an FPM pool or the server configuration, not with ini_set() or .user.ini, then restart every worker. PHP suggests leaving it off after patching if the feature is not needed.
  • PHP 8.5 only (CVE-2026-109619): also set fatal_error_backtraces=0 and restart all workers.
  • Memory handling (CVE-2026-109618): set memory_limit=-1 administratively, preferably with php_admin_value, and confirm no pool, directory or application setting restores a finite limit. Cap memory with a container or cgroup limit instead; RLIMIT_AS and RLIMIT_DATA trigger the vulnerable path.
  • Request limits: keep post_max_size at 8M (32M if uploads are needed) with upload_max_filesize below it, enforce request size at the web server or proxy, and block multipart requests at the frontend where the application does not use them.
  • Worker recycling (pm.max_requests=1) shortens the window for stale state where performance allows. Hiding diagnostics with error_reporting, display_errors or @ does not help.

The setting should be checked through the web server (a phpinfo() page served by the site and deleted afterwards, or php-fpm -i). The php -v and php -i commands show the command-line PHP, which can differ from the PHP that serves the site.

  1. An inventory of PHP hosts, containers and versions, including forgotten instances.
  2. Fresh backups taken, and the workarounds above applied to any host that cannot be updated today.
  3. The fixed release (8.5.12, 8.4.27, 8.3.36 or 8.2.35) applied from distribution packages, a vendor or the official downloads. Vendors received the patches in advance. The volunteer-run rpms.remirepo.net repository has no updates on release day, so systems relying on it need distribution packages or a source build.
  4. PHP-FPM or Apache reloaded, with the fixed version confirmed through the web server.
  5. For PHP 8.1 and older: an upgrade to a supported branch, a vendor or distribution backport, PHP's minimal source backport for 7.4, 8.0 or 8.1, or isolating the site or taking it offline.
  6. A compromise check after patching: PHP files created or changed since 20 October, unexpected files in upload and cache folders, new admin users and unusual outbound connections. Secrets should be rotated on any host that cannot be shown to have stayed clean.

Frequently Asked Questions

Does updating WordPress protect a site from this flaw?

No. Updates to WordPress, its theme and its plugins do not change the PHP software on the server. The fix has to be applied to PHP itself, which on most hosting plans is done by the hosting provider.

Who is responsible for applying the fix?

Whoever manages the server the website runs on. On shared or managed hosting, that is usually the hosting provider. On a dedicated server or a cloud setup, it is usually the developer, agency or IT team that looks after the website. If it is unclear who that is, it is worth finding out today.

Is the flaw already being used in attacks?

PHP's official advisory reports a working attack demonstrated against one common server setup, but does not report attacks in the wild. One security company reports attacks since the morning of 21 October. Now that the fix and technical details are public, widespread automated attacks are likely, so waiting for confirmed attacks is not a safe strategy.

What happens to older websites that cannot be updated?

PHP no longer updates versions 8.1 and older. For 7.4, 8.0 and 8.1 it has published minimal source fixes that a hosting provider or developer can build and install, and some Linux distributions and support vendors provide their own. The options are an upgrade to a newer version of PHP, one of those backported fixes, extra protection in front of the site, or taking it offline until it can be upgraded. Older websites often need code changes before moving to a newer PHP version, so it is worth planning the upgrade now.

Is there a temporary fix?

PHP has published workarounds but says they do not make a site safe. They include switching off one PHP feature (session upload progress) and changing memory and upload limits on the server. They can reduce risk while an update is arranged, but the update is the only complete fix.

Which PHP versions are affected, and which fix the flaw?

The fixed versions are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, released on 21 October 2026. Every earlier version on those branches is affected, and PHP says every installation that serves web pages is at risk. The technical identifiers are CVE-2026-109618 and CVE-2026-109619.

Sources

Related Articles

[✳]