Skip to content
Latentism

Google Searches for PHP Just Jumped 10x. Here's Why

Google searches for PHP jumped 10x in October 2026. The reason is PHP2Shell, two critical bugs in PHP itself. What happened, who is affected, and how to patch.

4 min read

Line chart of Google searches for php in October 2026: flat for weeks, then a spike about ten times higher around 21 October, labelled 10x and PHP2Shell

Google searches for “php” jumped about tenfold in a few days because of PHP2Shell: two critical bugs in PHP itself, CVE-2026-109618 and CVE-2026-109619, that let an attacker run code on a PHP web server without logging in. PHP fixed them on 21 October 2026 in versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Since PHP runs most of the web, teams everywhere suddenly had to find and patch servers they had stopped thinking about.

If you run PHP, update now and restart every PHP process.

The spike in one chart

Worldwide search interest in “php” sat flat for a month, then shot up within days:

Google Trends chart of worldwide search interest in php over the past month: flat at around 10 from late September to 20 October 2026, then a sudden spike to 100 around 21 October

Source: Google Trends, worldwide, past month, captured 23 October 2026. Values are relative, with 100 as the peak.

No release or conference did this. A security emergency did.

Why one bug reached most of the web

PHP runs on 69.3% of websites whose server-side language is known, according to W3Techs (23 October 2026). WordPress, Drupal, Magento, Joomla, Nextcloud and Laravel apps all sit on top of it.

For years PHP was the language people wrote off. But “unfashionable” never meant “not in production”, so a bug in PHP’s runtime reaches most of the internet at once.

The uncomfortable part: 26.9% of PHP sites still run PHP 7 and 7.7% run PHP 5, which get no official patched release.

What PHP2Shell actually is

Both bugs are memory-safety flaws in PHP’s C core, not in any framework or app. Both are rated 9.2 on CVSS v4.0:

  • CVE-2026-109618: PHP can run out of memory partway through setting up a request. Cleanup code then trusts half-built internal data, and a crafted request can turn that into code execution.
  • CVE-2026-109619: some internal state outlives the memory it points to, so the next request on the same worker can use stale data. One confirmed path goes through session upload progress, which is on by default.

Rapid7 lists PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed as affected, and rates mod_php as the most exposed, because the attack can land before any application code runs. The researchers at Calif, who reported the first bug to PHP on 11 August, confirmed code execution against versions of WordPress, Drupal, Joomla, Magento, Nextcloud and Laravel apps, in some cases without any login. The oldest affected code path they found dates back to PHP 5.4.

Calif and Wiz, who found the bugs independently, both say they used AI models in the research. Then the details leaked on social media on 20 October, two days early, forcing PHP to ship an emergency release the next day.

The whole industry took PHP seriously overnight

  • CISA told organisations to patch immediately, and to take systems on PHP 8.1 or older offline until they are upgraded.
  • Cloudflare deployed firewall rules against the attack traffic, and Krebs on Security warned of site outages as teams rushed to update.
  • Wiz compared it to Log4Shell, the 2021 Java logging bug that sent every Java team into emergency patching.
  • Attackers are already probing. watchTowr saw exploitation attempts in its honeypots from 21 October, while Rapid7 and CISA had not confirmed attacks in the wild when they published. Public proof-of-concept exploits exist, so treat it as live.

How to patch PHP2Shell today

PHP2Shell patch checklist: find every PHP install, update the branch to 8.2.35, 8.3.36, 8.4.27 or 8.5.12, restart PHP-FPM, Apache, workers and long-running scripts, and retire PHP 8.1 and older

Branch Fixed version
8.5 8.5.12
8.4 8.4.27
8.3 8.3.36
8.2 8.2.35
8.1 and older No official release

For 7.4, 8.0 and 8.1, PHP published minimal source backports, and some distributions and support vendors ship patched packages. PHP 7.3 and older, including PHP 5, have no fix at all: upgrade.

Check what your web server runs, not just the command line. They are often different binaries:

php -v            # the command-line PHP
php-fpm8.4 -v     # the FPM service (adjust the version)

On Ubuntu or Debian with the popular ondrej/php packages, upgrade every package for that version and keep your config files:

sudo apt-get update
sudo apt-get install --only-upgrade -y -o Dpkg::Options::="--force-confold" \
  $(dpkg -l 'php8.4*' | awk '/^ii/ {print $2}')

Then restart everything that runs PHP:

  • PHP-FPM or Apache. The upgrade usually restarts these, but check.
  • Long-running processes. Queue workers and daemons keep the old binary until restarted.
  • Containers. Rebuild on a patched base image and redeploy. A running container never picks up a host update.

PHP developers were right all along

This week, the most useful person in many companies was whoever could upgrade a PHP 7 app, read a php.ini, or find the admin panel nobody owned. The language people wrote off was holding up much of the internet, and the developers who kept it running were the ones everyone needed.

Java teams lived through the same scramble with Log4Shell. The danger is rarely the language; it is the forgotten deployment. Know where PHP runs, keep it on a supported branch, and patch it on a schedule, the same discipline your Spring Boot services need.

PHP never went anywhere. Most of the industry just stopped looking.

Recommended from Latentism