Small Town Sysadmin
Free CJIS checklist

Tech basics

Security alert

PHP2Shell: two critical flaws in PHP itself are being attacked, and updating WordPress won't fix them

Two critical flaws in the PHP runtime (CVE-2026-109618 and CVE-2026-109619) let attackers run code on web servers. Here is who is affected, what to ask your host, and what IT should patch.

On October 21, 2026, the PHP project released emergency fixes for two critical flaws, CVE-2026-109618 and CVE-2026-109619, nicknamed PHP2Shell. Both are rated 9.2 out of 10 (CVSS v4.0). If your website, intranet, or any business web application runs on PHP, this applies to you. WordPress, Drupal, Joomla, Magento and Laravel all run on PHP.

The flaws are in PHP itself, the software that runs underneath those programs, not in WordPress or any plugin. A site can be fully up to date and carefully built and still be exposed. Security researchers say all PHP setups that serve web pages are affected, and one report says nearly 70 percent of websites use PHP.

What the flaws allow

An attacker who doesn’t need a login can send a specially built web request and run their own commands on the server. They can also read memory from the PHP worker processes, which can expose passwords and sign-in tokens belonging to other visitors’ requests. The most exposed setup is Apache with mod_php, where a single request can trigger the problem before your site’s own code runs. PHP-FPM, php-cgi, FrankenPHP and LiteSpeed are affected too.

Is it being attacked?

Yes, attempts at least. The security firm watchTowr reported active exploitation attempts against both flaws on October 21, and Cloudflare reported early attacks and added firewall rules as a stopgap, saying attackers kept changing their payloads. Wiz expects mass exploitation aimed at planting web shells, small hidden files that give an attacker remote control of a site.

As of this writing, none of the sources we checked confirmed a successful break-in of a specific server. The NSA advised organizations to update immediately, or take systems offline until they can. Government websites went offline after the disclosure, according to Reuters.

If you own a website but don’t run the server

You don’t need to touch anything technical. Send your web host or IT provider this question in writing and keep the answer:

Has the PHP runtime on my site been updated to a fixed version for CVE-2026-109618 and CVE-2026-109619?

Updating WordPress, a theme or a plugin does not update PHP. The fix comes from your hosting company, the server’s software packages, or the container image the site runs in. If your site is plain static pages, or runs on a platform that doesn’t use PHP, these flaws don’t apply to it.

If your host can’t answer, or says the update is “scheduled,” ask when and whether the site can be taken offline until then.

For IT: fixed versions

PHP branch Fixed version
8.5 8.5.12
8.4 8.4.27
8.3 8.3.36
8.2 8.2.35

PHP 8.1 and older no longer get project updates, but PHP published source backports for 7.4, 8.0 and 8.1. Reports say the affected code goes back to PHP 5.4 and that every PHP version of the last decade is affected by at least one of the two flaws, so an old server isn’t safe just because it is old.

Check the CVE, not just the version number. Linux distributions often backport a fix into a package that still shows an old-looking version. Ubuntu has released updated PHP packages. Check the package changelog for the two CVE numbers.

For IT: what to do

  1. Find every PHP runtime serving web requests: servers, containers, hosting accounts, and vendor appliances that bundle a web application.
  2. Update PHP from your distribution, your host, or a fixed container image.
  3. Restart Apache, PHP-FPM and any long-running PHP workers. A package update alone doesn’t replace a process that is already running.
  4. Check memory settings after patching. The fix adds a hard memory limit, so review memory_limit and post_max_size against what your application needs.
  5. Check for signs of trouble (below), especially on anything that was exposed to the internet before you patched.

If you can’t patch yet

The PHP advisory describes partial workarounds and says they do not make a server safe. Use them only to reduce exposure while you arrange the update:

  • CVE-2026-109618: set memory_limit=-1 so applications can’t override it, keep post_max_size low, and enforce request-size limits at the web server or proxy.
  • CVE-2026-109619: set session.upload_progress.enabled=0 and restart all workers. On PHP 8.5, also set fatal_error_backtraces=0.

A web application firewall in front of the site, such as Cloudflare’s, can help as a stopgap, but attackers have already changed their requests to get around it. Taking the site offline is the safer interim choice if it isn’t needed.

Signs a site was hit

  • Unusual multipart requests (the kind used for file uploads) followed by memory-limit errors
  • Repeated HTTP 500 errors
  • Oversized PHPSESSID cookies in responses
  • PHP workers restarting without explanation

Also look for files in the web folders that nobody put there, especially recently added .php files in upload or cache folders. If you find any, treat the server as compromised, change the passwords and keys stored on it, and get incident response help before you wipe anything. Our incident response plan checklist is a place to start, and what to do if you think you’ve been hacked covers the basics.

This article follows the published facts as of October 21, 2026. The situation is moving quickly, so check the PHP project’s advisory for updates.

Sources

All articles