What happened, in plain words

PHP is the software that runs behind the scenes on a huge number of websites. When a guest opens a booking page, fills in an enquiry form or reads a blog post on a WordPress site, PHP is usually doing the work on the server.

On 20 October 2026 the PHP security team gave advance notice that an urgent fix for two critical problems was coming the next day. On 21 October it released that fix and published the details.

In simple terms, both problems are about how PHP tidies up after itself:

  • CVE-2026-109618 ("RCE via OOM corruption"). When a request uses up its memory allowance at exactly the wrong moment, PHP can leave half-finished data behind and then treat it as valid. A specially crafted request, such as an oversized form or file upload, can use this to corrupt memory.
  • CVE-2026-109619 ("RCE via stale global state"). After certain errors, PHP can keep hold of information from one visitor’s request after that memory has been cleared. The next request handled by the same part of the server can then pick up that leftover data.

In both cases the worst outcome is "remote code execution": an attacker on the internet runs their own commands on the web server, with no login needed. On one common setup (Apache with mod_php), the PHP team showed this can happen before the website’s own code even starts, so a well-built website does not protect itself.

The two flaws have been nicknamed "php2shell" in security alerts.

Is it being exploited? At the time of the patch, the US Cybersecurity and Infrastructure Security Agency (CISA) said it had not yet seen attacks using these flaws. The EU’s CERT-EU said early proof-of-concept code was already circulating, which makes attacks more likely soon. The safe assumption is that unpatched sites will be targeted.

Who is affected

Any website or system where PHP serves web pages is in scope. That includes:

  • WordPress, WooCommerce, Drupal and Joomla sites
  • Booking engines, enquiry forms and travel blogs built on PHP
  • Common server setups, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed (the PHP team rates Apache with mod_php as the highest risk)
  • Other products that quietly include PHP inside them. The Dutch NCSC keeps a list of affected third-party software

Affected versions are all PHP 8.2 releases before 8.2.35, PHP 8.3 before 8.3.36, PHP 8.4 before 8.4.27 and PHP 8.5 before 8.5.12. PHP 8.1 and older no longer receive fixes from the PHP project and should be treated as vulnerable.

For a typical tourism business, this covers the main website, a separate blog, a staging copy of the site, and any old microsites or campaign pages still online.

What the patch fixes

The PHP project released four security updates on 21 October 2026:

PHP branchFixed version
PHP 8.58.5.12
PHP 8.48.4.27
PHP 8.38.3.36
PHP 8.28.2.35

These versions change how PHP handles running out of memory, so it no longer leaves broken data behind, and make sure leftover data from one request is properly cleared before the next one starts.

A few points worth knowing:

  • Updating is the only complete fix. The PHP team has published temporary settings that reduce some of the risk, but says they "do not make an installation safe".
  • Linux distributions and long-term support vendors got the fixes in advance, so most good hosting companies can roll them out quickly.
  • PHP 8.1, 8.0 and 7.4 are end of life. Because of the severity, the PHP team published minimal source fixes for these older versions, but the real answer is to move to a supported version.
  • PHP 8.2 reaches end of life on 31 December 2026, so a site on 8.2 should plan its next upgrade now.

The current list of supported versions is on the PHP supported versions page.

What tourism businesses should do

Most hotels, guesthouses, tour operators and travel publishers use shared or managed hosting, so the hosting company or web developer does the technical work. The checklist below is about asking the right questions and covering the basics.

  1. Find out which PHP version the site runs. In WordPress, go to Tools, then Site Health, then the Info tab, and open the "Server" section. The hosting control panel (for example cPanel or Plesk) usually shows it too. Or simply ask the host or developer.
  2. Ask the hosting provider to confirm the update. A short message works: "Has PHP on my hosting been updated to a version that fixes CVE-2026-109618 and CVE-2026-109619 (8.5.12, 8.4.27, 8.3.36 or 8.2.35, or the vendor’s patched package)? If not, when will it be?" Get the answer in writing.
  3. If the site runs on its own server or VPS, the update needs to be installed by whoever manages that server. Ask the developer or IT provider to do it today and restart PHP afterwards.
  4. Take a fresh backup first. Make sure there is a recent copy of the website files and database stored somewhere other than the web server, and check it can actually be restored.
  5. Update WordPress, themes and plugins. This does not fix the PHP flaw itself, but it closes other doors attackers often try at the same time. Remove plugins and themes that are no longer used. WordPress has a guide to updating WordPress.
  6. Move off unsupported PHP. If the site is on PHP 8.1 or older, ask the host or developer to move it to a supported version. Check the PHP supported versions page and the WordPress requirements. Test on a staging copy first if possible.
  7. Look for signs of trouble. Warning signs include new administrator accounts nobody created, unexpected redirects to other websites, strange pages appearing in Google, the site suddenly slowing down, unknown files in the hosting account, or a warning from the host or Google. If anything looks wrong, tell the host straight away.
  8. Change passwords if there is any doubt. This means the hosting account, WordPress admin and database passwords, and turning on two-factor sign-in wherever it is offered.
  9. Remember the other places PHP may be hiding. This includes old campaign sites, a staging site, a separate blog, or a third-party booking or CRM tool that runs on PHP. Ask each supplier whether they are affected and have updated.

If a site cannot be updated quickly, the UK NCSC advice is to consider taking it offline until it can be fixed.

Taking a site offline without hurting Google rankings

On 21 October, Google Search Central reminded site owners that taking a site offline to patch PHP should be done with a "503 Service Unavailable" response, which tells search engines the outage is temporary. Google says this keeps pages that are already indexed in search while the work is done, and that rankings return to normal once the site is back.

In plain terms:

  • Ask the host or developer to show a 503 maintenance page, not a blank page, a "page not found" (404) error, or a normal-looking page that just says the site is down.
  • The 503 needs to come from outside PHP, because PHP is the thing being fixed. Common options are a rule at the CDN (for example Cloudflare), a host’s maintenance mode, or temporarily pointing the domain at a simple holding server.
  • Keep robots.txt working normally. Google says robots.txt should not return a 503, as that stops all crawling.
  • Keep it short. Google advises against serving a 503 for more than one to two days, as pages may start dropping out of search. For a longer closure, Google suggests a simple holding home page instead.
  • Optionally add a "Retry-After" header, which tells search engines when to check back.

Sources: Search Engine Journal report on Google’s 503 reminder, Google: how HTTP status codes affect Google’s crawlers, Google: pausing or disabling a website.

Where to get advice and help

  • Your hosting provider’s support team. This is the fastest route for most small businesses. Many hosts publish status updates when a major patch like this lands.
  • UK National Cyber Security Centre alert. The NCSC alert on the PHP security issue sets out the priority actions in plain language.
  • NCSC Small Business Guide. The Small Business Guide covers backups, updates, passwords and avoiding common attacks.
  • Cyber Essentials. Cyber Essentials is a UK government-backed scheme that sets out basic security controls, including keeping software up to date.
  • NCSC Early Warning. The free Early Warning service notifies UK organisations of potential threats on their networks.
  • Reporting an incident. If a business has been hacked or defrauded, it can report it to Action Fraud (England, Wales and Northern Ireland; Police Scotland handles reports in Scotland) and to the NCSC through its incident reporting service. For hands-on help, the NCSC lists assured Cyber Incident Response providers.
  • PHP’s own security information. The official PHP security advisory and the PHP security manual are the primary sources.
  • WordPress hardening. WordPress publishes a guide to hardening WordPress for site owners and developers.

Frequently asked questions

Does this affect a website built on Wix, Squarespace or Shopify?
These platforms manage their own servers, so site owners cannot and do not need to update PHP themselves. Any update is the platform’s job. The risk sits mainly with self-hosted WordPress, Drupal, Joomla and other PHP sites.
The site is on WordPress with managed hosting. Is it already safe?
Probably soon, if not already, but it is worth confirming. Ask the host which PHP version the site is on and whether it includes the 21 October fix. Do not assume.
Will updating PHP break the website?
A security update within the same branch (for example 8.3.x to 8.3.36) rarely causes problems. Moving from an old version such as PHP 7.4 to PHP 8.3 is a bigger change and is best tested on a staging copy first, with a backup in place.
Do guests’ card details or booking data need to be reported?
Only if there is evidence of a breach. If personal data may have been accessed, UK businesses may need to report it to the Information Commissioner’s Office within 72 hours. Getting advice early from the host or an incident response provider helps.
Will taking the site offline to patch it hurt Google rankings?
A short outage served as a 503 "Service Unavailable" page should not, according to Google. Problems start if the site shows errors or blank pages, or stays down for more than a day or two.

Sources