Oakshield Book a call
Menu

A plain-English guide for site owners and their developers

PHP2Shell, explained: check it, patch it, prove it

Last updated:

By Oakshield. Change log

On October 21, 2026, PHP released emergency fixes for two critical flaws in the PHP engine, CVE-2026-109618 and CVE-2026-109619, known as “PHP2Shell”. On October 23, PHP disclosed a related issue, CVE-2026-115560, that those releases don’t fix. This page covers who needs to act, how to prove a patch, and what to do before December 31.

Short on time? The plain-English guide for business owners. Running many client sites? The agency triage guide. All guides

Summary

Who acts
Many shared and managed hosts reported patching their managed plans. On your own server, you do.
Scale
Bitsight’s scans found only about a third of version-identifiable PHP instances on a branch that received the update, with 7.4 the most common branch.

What PHP2Shell is

PHP runs 69.3% of websites with an identifiable server-side language. PHP2Shell is the name Wiz gave to two flaws in the PHP engine itself. PHP’s security team rated both 9.2 out of 10. Under certain conditions, an unauthenticated attacker can run code on an unpatched server. Nearly every version back to 5.4 is affected, and the Apache mod_php setup carries the highest risk. Default settings are affected. One flaw can also leak memory from other requests, which may include passwords, tokens and API keys.

What happened

In October 2026 the PHP engine needed an emergency fix. The sequence, with a source for each line.

  1. Researchers at Calif and Wiz independently find the flaws using AI models and report them to PHP.

  2. Amazon’s threat intelligence team observes the first exploitation attempts, four days before a patch exists.

  3. PHP pre-announces an emergency security release.

  4. Japan’s Prime Minister posts what she calls an “extremely urgent request”, asking site operators to check for PHP and prepare to patch that night.

  5. PHP releases 8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP’s security team rates both flaws 9.2 out of 10. There is no official fixed release for 8.1 or older.

  6. CISA advises taking systems offline where they can’t be patched; the UK NCSC advises considering it if temporary mitigations can’t be applied in time. Proof-of-concept code begins circulating.

  7. Many shared and managed hosts report patching PHP on their managed plans; owners of their own servers must patch themselves. Governments, banks and airlines take some services offline as a precaution.

  8. WP Engine reports blocking more than one million related requests in 24 hours, with no successful exploits.

  9. PHP discloses CVE-2026-115560, which the October 21 releases don’t fix, and recommends a configuration change.

  10. Status

    As of October 23: attempts are widespread. One compromise has been reported, by Palo Alto Networks’ Unit 42 (a European government entity), and it has not been independently corroborated.

    Last checked: October 23, 2026. We update this line as facts change.

  11. PHP 8.2 stops receiving security fixes.

What we know, and what we don’t

Known

Not yet known

On AI: AI tools helped researchers find these flaws, and attackers use AI agents too. But Google’s threat researchers said in September 2026 that they hadn’t yet observed fully autonomous attack pipelines in the wild, and AI-discovered bugs aren’t exploited more often than others. What has changed is speed and cost.

Who needs to act

Your setupWho patches PHPWhat to do
Shared or managed hosting (e.g. GoDaddy, Hostinger, SiteGround, WP Engine, WordPress.com; Xserver, Sakura, Lolipop) Your host. Many reported patching their managed plans. Get written confirmation (template). Plan for 8.2’s end of life.
Fully hosted platforms, such as WordPress.com The platform Check its status page.
Your own server: VPS, cloud VM, dedicated, self-managed cPanel or Plesk, containers You, or whoever runs it for you Follow What to do.
An agency or developer runs it Ask them Send the template.
Website visitors No action needed Nothing

Check it yourself: how to prove a patch

Everything in this section is free. These are the checks we run ourselves, written so you or your developer can run them.

Backported fixes keep the old version number, the command-line PHP may differ from the one serving your site, and a patched package takes effect only after a restart. As AlmaLinux put it: “Don’t rely on php -v: our fixes are backported, so the upstream PHP version number doesn’t change.”

The full method, with the four evidence levels and a status record you can copy: how to prove your server is patched.

What counts as proof

  1. The PHP that serves the site. Check the web server’s PHP (control panel setting, or a temporary phpinfo page you delete immediately), not only the command line.
  2. Fixed release or backport. At or above 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or a backport whose changelog or vendor advisory cites both CVE-2026-109618 and CVE-2026-109619.
  3. A restart after the update. PHP-FPM, Apache, LiteSpeed or containers restarted or rebuilt.
  4. The CVE-2026-115560 setting. session.upload_progress.enabled=0 in php.ini, the FPM pool or the server configuration, then a restart. Not ini_set() or .user.ini.
  5. Everything else on the server. Staging copies, old sites and bundled PHP.

For your developer

  • Debian and Ubuntu: the package changelog, or Ubuntu’s CVE page (USN-8948-1 and -2).
  • RHEL, AlmaLinux, Rocky: rpm -q --changelog for the PHP package; vendor advisories.
  • cPanel ea-php, CloudLinux alt-php, Plesk: vendor changelogs. Backports keep strings such as 7.4.33 or 8.1.34.
  • Docker official images: 8.2.35 or later. No official image is maintained for 8.1 or older.
Commands your developer can run

Package names use PHP 8.1 as the example. These are read-only checks, plus a restart.

  1. Find the PHP that serves the site. Look up the PHP-FPM pool or socket in the web-server configuration (e.g. /run/php/php8.1-fpm.sock) or the Apache module (apache2ctl -M | grep -i php), then check that binary: php-fpm8.1 -v on Debian or Ubuntu, php-fpm -v on the RHEL family.
  2. Search the package changelog for the CVE IDs. Debian or Ubuntu: zgrep -E 'CVE-2026-(109618|109619|115560)' /usr/share/doc/php8.1-fpm/changelog.Debian.gz. RHEL family: rpm -q --changelog php-fpm | grep -E 'CVE-2026-(109618|109619|115560)'. If the IDs aren’t listed and the version is below the fixed release, treat it as not fixed.
  3. Restart PHP after updating. sudo systemctl restart php8.1-fpm (Debian or Ubuntu), sudo systemctl restart php-fpm (RHEL family), or restart Apache for mod_php. Confirm the service started after the update: systemctl show -p ActiveEnterTimestamp php8.1-fpm.
  4. Apply the CVE-2026-115560 setting in the php.ini or FPM pool the site uses, then restart. Pool settings (php_admin_value, php_value) override php.ini, so check both.

Prefer a signed answer? A Patch Verification ($590) delivers per-CVE status with evidence levels in 1 business day. Book a call

What to do

Tonight

  1. Find out who manages your PHP (see the table). If it’s your host, request written confirmation.
  2. On your own server: install the fixed release or the distribution’s patched package, then restart PHP. “The only mitigation is patching/upgrading PHP.”
  3. Apply the CVE-2026-115560 setting and restart.
  4. If you can’t patch quickly, follow your host’s or vendor’s mitigation guidance, and consider a maintenance page. CISA advised taking systems offline where they can’t be patched; the UK NCSC advised considering it if temporary mitigations can’t be applied in time. Use a proper maintenance page, not a disabled PHP handler, which can expose source code.

This week

  1. Review for signs of compromise since October 17: unfamiliar files or admin accounts, new scheduled tasks, processes started by the web server. PHP’s advisory warns that “absence of an error in logs is not proof of safety.”
  2. Rotate secrets if the server ran unpatched while exposed.
  3. Don’t rely on a firewall alone.

Before December 31, 2026

  1. If you run PHP 8.2 or older, plan a move to 8.4 or 8.5, so the work is done once.

The PHP 8.2 end-of-life checklist

Email for your host or developer

Copy it, fill in the brackets and send it. Keep the reply: it’s your written confirmation.

Email template

Subject: PHP2Shell (CVE-2026-109618 / CVE-2026-109619): please confirm our PHP is patched

Hello [name],

Following the PHP security release on October 21, 2026, please confirm
in writing for [your-domain.com]:

1. Is the PHP serving our site managed by you or by us?
2. Which PHP version and build serves the site (not just the command
   line), and is it PHP-FPM or Apache mod_php?
3. Does it include the fixes for CVE-2026-109618 and CVE-2026-109619?
   If it is a backport, which vendor or package version, and when was it
   applied? Were PHP workers restarted afterwards?
4. Has session upload progress been disabled at server level for
   CVE-2026-115560, as PHP recommends?
5. Have you reviewed for signs of compromise since October 17? Should we
   rotate passwords or API keys stored on the server?
6. Are staging and old copies of our site covered?
7. What is the plan and date to move us off PHP 8.2 or older before
   PHP 8.2 reaches end of life on December 31, 2026?

Thank you,
[your name]

Why this isn’t a one-week story

Exploiting known vulnerabilities is the most common way breaches begin, at 31% according to Verizon.

Should we leave PHP?

No. Leave unmaintained PHP. Current releases fix PHP2Shell. Other stacks have had flaws just as severe. Close the current exposure first. As Kevin Riedl of Wavect, a consultancy that sells upgrades and migrations, put it: “Close the current exposure before making the emergency dependent on a full rebuild.”

Is a firewall enough?

A firewall is a useful second layer, but it doesn’t replace the patch. Cloudflare reports rules on all plans, but they cover only traffic that passes through Cloudflare.

Technical sources

Services

Questions

Is PHP2Shell in the US Known Exploited Vulnerabilities catalog?

Not as of October 23, 2026. We re-check before every update to this page.

Why do severity scores differ?

Different organizations score differently. We cite PHP’s own score: 9.2 out of 10.

When can I bring an offline site back?

Once PHP is confirmed patched and restarted, the CVE-2026-115560 setting is applied, and a compromise review is complete.

Change log

  • : Published. Facts current as of October 23, 2026.

Your website, accounted for.

Want a signed answer instead?

A Patch Verification gives you per-CVE status for every PHP runtime on the server, and a compromise review, in 1 business day.

Book a call See a sample report

Sources

Every figure and quotation on this page links to its primary source. All of them, with the date we last checked each: full wording and methods.