PHP2Shell Vulnerability: What It Means for Your Website and How We Patched It

The PHP2Shell vulnerability is the most serious PHP security problem in years, and it affects a large share of the web. WordPress, WooCommerce, Laravel, Drupal, Magento and most custom business sites run on PHP. On October 21, 2026, the PHP project shipped an emergency release for two critical flaws, CVE-2026-109618 and CVE-2026-109619, and attacks were already being observed before the patch was public.

Our own servers were patched the same day, about 70 minutes after the fix was released. Below we explain what happened, how to check whether your website is still exposed, and why the version number your server reports can mislead you.

Quick answer: PHP2Shell lets an attacker run code on a web server through a crafted request, without logging in. The fixed PHP versions are 8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP 8.1 and older will not receive a fix. If your site runs on PHP, confirm with your developer or hosting provider today that the patched build is installed and that PHP was restarted after the update.

What PHP2Shell Is, in Plain Terms

PHP is the language that builds the pages of your website every time a visitor loads them. PHP2Shell is the nickname for two memory-handling bugs inside PHP itself, not inside a plugin or theme. When a request causes a fatal error at the wrong moment, PHP can leave behind memory it has already released. A later request can then treat that freed memory as live data, and a skilled attacker can turn that into running their own code on the server.

That is why the industry treats it as an emergency. Code execution on the server means the attacker can read the database, steal customer data, plant malware or redirect visitors. The PHP security team rates both flaws as critical, with a CVSS 4.0 score of 9.2. Some early reports said 10.0; the PHP Foundation corrected that figure.

Timeline: How Fast This Moved

• October 20, 2026: the CVE identifiers circulated before the scheduled disclosure. No technical details leaked at that point.
• October 21, 07:43 UTC: Cloudflare reported the first exploitation attempts, before any patch was available.
• October 21, 14:00 UTC: the PHP project published the fixed releases and urged everyone to update immediately.
• October 21, same day: Ubuntu published security notice USN-8948-1 with patched packages, and hosting control panels such as Plesk began rebuilding their PHP builds.

Public write-ups and exploit tooling appeared within hours. For a vulnerability like this, the window between disclosure and mass scanning is measured in hours, not weeks.

What We Did at Heyday

Heyday runs its website and several client properties on servers we manage directly. Here is exactly what happened on our side on October 21:

• 15:09 UTC: our team installed Ubuntu's patched PHP 8.3 packages (build 8.3.6-0ubuntu0.24.04.13, which contains the fix for both CVEs).
• 15:10 UTC: PHP-FPM, the service that actually answers web requests, restarted on the new build. We verified the restart time against the package installation log, because an update that is installed but not loaded does not protect anything.
• The same afternoon: we reviewed client projects we maintain, confirmed which ones depend on a hosting provider's PHP build, and updated outdated framework dependencies where we found them.

From the official release to a patched, restarted production server took about 70 minutes. We share this so clients and partners know where they stand, and so other business owners have a concrete benchmark to ask their own providers about.

The Version Number Trap

Here is the detail that confuses many teams. On Ubuntu and Debian servers, running php -v after the update still shows 8.3.6, not 8.3.36. That is normal. Linux distributions backport security fixes into their own package builds instead of jumping to the upstream version number.

So the upstream version is not the right test. The right test is the exact package build:

• Ubuntu or Debian servers: run dpkg -l | grep php or apt-cache policy php8.3-fpm and compare the installed build with the one listed in Ubuntu security notice USN-8948-1 (for Ubuntu 24.04 and PHP 8.3, that is 8.3.6-0ubuntu0.24.04.13).
• Servers using upstream builds: php -v should show 8.5.12, 8.4.27, 8.3.36 or 8.2.35 or later.
• Shared hosting, cPanel or Plesk: the hosting company compiles PHP for you. You need their patched build, which may appear under a different version label. Ask support directly whether the fix for CVE-2026-109618 and CVE-2026-109619 is live on your account.

Installed Is Not the Same as Protected

A patched package on disk does nothing until the PHP process that serves your site is restarted. On servers using PHP-FPM, compare the package installation time with the service start time. If PHP-FPM started before the update was installed, the old vulnerable code is still the one answering visitors.

Long-running workers, queue processors and application servers such as Laravel Octane, Horizon or FrankenPHP also need a restart so they load the new build.

If Your Host Has Not Patched Yet

Many small business websites sit on shared hosting, where the owner cannot update PHP directly. If your provider has not rolled out the fix yet, these are the realistic options:

• Open a support request now and ask for the patched PHP build by CVE number. Providers prioritize tickets that name the vulnerability.
• Ask about temporary mitigations. Security researchers at Sansec report that every known trigger is a multipart/form-data request, the format browsers use for file uploads. Blocking those requests at the web server reduces exposure but also breaks upload forms, so it is a short-term measure.
• Check session.upload_progress.enabled. Turning it off removes one path to the bug, although researchers note it is not enough on its own.
• Plan to move off PHP 8.1 or older. Those versions are end of life and will not receive this fix at all.

What Miami Business Owners Should Ask This Week

You do not need to read server logs yourself. You need clear answers from whoever runs your website. Send your developer, agency or hosting provider these questions:

• Which PHP version and exact build is serving our website right now?
• When was the fix for CVE-2026-109618 and CVE-2026-109619 installed, and when was PHP restarted?
• Do any of our sites still run PHP 8.1 or older?
• Who is responsible for applying security updates on our hosting, and how fast do they usually happen?

If nobody can answer those questions, that is useful information too. A website that generates leads, takes payments or stores customer data needs someone accountable for its security, the same way it needs someone accountable for its marketing.

Security Is Part of Marketing Performance

A compromised website does more than create an IT problem. Google can flag the domain as dangerous, ad platforms can pause campaigns that send traffic to it, and customers lose trust quickly when a familiar site starts redirecting to spam. Search rankings built over years can drop in days.

That is why our web design and development team treats updates, monitoring and backups as part of every website we build and maintain. If you are not sure whether your site is protected from PHP2Shell, contact Heyday and we will tell you what to check.