Brown Walrus MANAGED IT · WEB · AI · CYBERSECURITY

· Brown Walrus

How we handled the PHP2Shell vulnerabilities on October 20 and 21, 2026

On Tuesday, October 20, 2026, the official ID numbers for two critical security flaws in PHP, the programming language many websites run on, leaked before PHP had a fix ready. The flaws are known as PHP2Shell. We took all client websites and servers offline at 10:00 p.m. that night and waited for PHP's security release. By noon on Wednesday, October 21, all 100+ sites were back online with the fix in place, on every type of server we run.

How it unfolded (Edmonton time)

  1. Tue, Oct 20

    Morning

    PHP2Shell details leak

    The ID numbers for the two flaws go public before PHP has a fix.

  2. Afternoon

    PHP schedules an emergency release

    The fix is set for 8:00 a.m. Wednesday.

  3. 10:00 p.m.

    We take every client site and server offline

    We wait for PHP's fix rather than run exposed.

  4. Wed, Oct 21

    8:00 a.m.

    No ready-made fix for some of our servers

    PHP's fix ships, but one supplier has nothing for our ARM64 servers and Amazon's hosting service has no patched version at all.

  5. Morning

    We build patched PHP ourselves

    Our ARM64 servers get the patched release without waiting on suppliers.

  6. Noon

    All 100+ sites back online, fully patched

    WordPress, Laravel, Craft CMS and custom PHP sites, on every type of server we run.

What PHP2Shell is

PHP2Shell is the nickname for two flaws in PHP itself, listed in the public catalogue of security flaws as CVE-2026-109618 and CVE-2026-109619. PHP rated both critical, with a severity score of 9.2 out of 10.

In plain terms, someone with no login could, under the right conditions, send requests to a vulnerable server and run their own code on it. PHP's security advisory lists every PHP installation that serves web pages as at risk.

The flaws sit in PHP, underneath the application. Updating WordPress or a plugin did nothing for them. The fix was a new PHP release: 8.5.12, 8.4.27, 8.3.36 or 8.2.35, depending on which version series a site was on.

Why we took sites offline

On Tuesday, the flaws' ID numbers were public and no fix existed. PHP rated both flaws critical in its afternoon notice, and security reports described them as remote code execution: an attacker running their own code on the server. PHP's fix was not due until 8:00 a.m. Wednesday. At 10:00 p.m. we took every client website and server offline while we waited for it.

When the fixes came out on Wednesday, PHP's release notes said: "There are no complete mitigations, updating is the only safe choice." Amazon's threat intelligence team has since reported an attempted PHP2Shell attack dated October 17, four days before the flaws were made public, as Help Net Security reported.

When the ready-made fix wasn't there

We run client sites on two kinds of server: x86, the traditional chip design in most servers and PCs, and ARM64, the newer chip design used in phones and recent Macs. When the release came out, two sources of ready-to-install PHP had nothing for ARM64:

  • Sury PHP packages, Ondřej Surý's ready-to-install PHP for Linux servers, had x86 versions only, with none for ARM64.
  • AWS Elastic Beanstalk, Amazon's managed hosting service, had no patched PHP version for either kind of server.

Waiting on those would have kept the ARM64 sites offline after the fix existed. We built patched PHP ourselves for our ARM64 web servers instead.

What we patched

By noon on Wednesday, October 21, we had upgraded PHP for:

  • 100+ client websites
  • Servers on x86 and ARM64
  • WordPress, Laravel and Craft CMS sites, plus custom PHP applications

What we would tell other site owners

Check your PHP version

Your site has the PHP2Shell fixes if it runs PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or a later release in the same version series. Your host or developer can tell you the version in a minute. Many hosting control panels show it too.

If your server gets PHP from its operating system's own updates or from a long-term support provider, the version number alone won't settle it, because those suppliers patch older versions too. PHP says those vendors received the patches in advance, so ask yours whether your packages include the October 21 fix.

Plan around older versions

The PHP project no longer ships updates for PHP 8.1 and older, so a site on those versions needs a patched older version from a supplier that still maintains it, or an upgrade to a supported version. PHP 8.2 reaches end of life on December 31, 2026, and gets no security fixes after that.

Watch for one more PHP issue

On October 23, PHP published an informational advisory about a further issue, CVE-2026-115560. PHP says the issue "can only occur under an unusual combination of configuration and application code." Until the next regular release, PHP suggests switching off one setting (session.upload_progress.enabled=0). Ask your host whether that applies to you.

If you run ARM64 servers

Check where your PHP packages come from and whether that source publishes ARM64 builds on release day. On October 21, the packages we needed for ARM64 were not there, so we built PHP ourselves.

Frequently asked questions

Is my PHP site vulnerable to PHP2Shell?

If your server runs a PHP version older than 8.5.12, 8.4.27, 8.3.36 or 8.2.35 in its version series, and your host or your server's operating system supplier has not confirmed the fix for your version, assume it is exposed. PHP's advisory lists all PHP installations serving web requests as at risk. Updating WordPress, Craft or a plugin does not help, because the flaws are in PHP itself. Ask your host or developer which version you run and where it comes from.

How do I check which PHP version my website runs?

Ask your host or developer first. They can read the version off the server in a minute, and many hosting control panels show it for each site. Compare it with the fixed releases: 8.5.12, 8.4.27, 8.3.36 and 8.2.35. If your PHP comes from your server's operating system updates or a long-term support provider, also ask whether those packages include the October 21 fix, because vendors patch older versions too.

Why did Brown Walrus take client sites offline before the patch came out?

On October 20 the ID numbers for both flaws leaked before PHP had a fix. PHP rated both flaws critical, security reports said attackers could run their own code on affected servers, and the patch was not due until 8:00 a.m. the next day. We took every client website and server offline while we waited for the release. All 100+ sites were back online on patched PHP by noon on October 21.

Does updating WordPress or my CMS protect against PHP2Shell?

No. The flaws are in PHP, the language your CMS runs on, so the fix is a PHP upgrade on the server. WordPress, Laravel, Craft CMS and custom PHP sites all needed the same thing: PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 or later in the same version series. Keep your CMS and plugins updated anyway, but check the PHP version separately.

What if my site runs PHP 8.1 or older?

The PHP project no longer ships updates for PHP 8.1 and older. For PHP2Shell, the PHP security team published code fixes for 7.4, 8.0 and 8.1 that a developer has to apply by hand, and some operating system makers and long-term support providers offer patched versions. The safer plan is an upgrade to a supported version. Note that PHP 8.2 also reaches end of life on December 31, 2026.

Still dealing with PHP2Shell?

If a site is still on an unpatched PHP version, or you're stuck waiting for a supplier to release a patched version, we can help. We'll check your PHP versions, patch or build what's missing, and get your sites back on supported releases through our web development and managed IT work. Call us at 780-540-7606.

Talk to us