A Critical Flaw in PHP Means Laravel, CodeIgniter, and WordPress Sites Need Checking Too

On October 21, 2026, the PHP team released an emergency security update for two critical flaws, CVE-2026-109618 and CVE-2026-109619, which their discoverers named PHP2Shell. Both are rated 9.2 out of 10 (CVSS v4.0) and can let an attacker run code on the server without logging in.

When they hear this news, many teams immediately think, "We use Laravel, not plain PHP." Or, "We updated WordPress yesterday." The problem is that these flaws are in PHP itself, not in the framework or CMS.

Why your framework doesn't help

Laravel, CodeIgniter, and WordPress are all written in PHP and run by PHP on the server. If you think of it as a house, the framework is the building and PHP is the foundation. A freshly renovated building still shakes if the foundation is cracked.

According to the PHP team, every PHP installation serving web requests is at risk, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, and LiteSpeed. The risk is highest with mod_php, where the attack has been shown to work before any application code even runs.

Wiz, one of the teams that found the flaws, says even the simplest "Hello World" app can be vulnerable if its PHP version is affected. They also demonstrated the attack against the latest versions of WordPress, Drupal, and Joomla at the time of testing.

How serious it is

• No login needed. An attacker only has to send a request to the website.
• It's been there a long time. According to Wiz, the flaws have existed for more than ten years, and every PHP version since 5.4 is affected by at least one of them.
• Attack attempts have already happened. As of October 22, Rapid7 hadn't seen successful exploitation in the wild, but noted multiple reports of attack attempts and several proof-of-concept exploits already circulating publicly, though each only works on a specific combination of systems. Amazon, as reported by Help Net Security, recorded an attack attempt on its honeypot on October 17, four days before the flaws were announced.
• AI is speeding things up. The Wiz researchers wrote that the latest AI models greatly lowered the barrier to turning this old flaw into a working attack. To me, that's a sign the gap between a flaw being announced and real attacks will keep getting shorter.

What to check, depending on your framework

The patched versions are PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35. PHP 8.1 and older no longer get official updates from the PHP team.

If your website is on shared hosting, the hosting provider is usually the one who installs PHP patches. You may be able to pick a PHP version in your control panel, but still ask your host whether the patches for these two CVEs are in place.

Plenty of websites still run old PHP

According to W3Techs, PHP is used by 69.3% of websites whose server-side language is known. Of those PHP websites, more than a third are still on PHP 7 or older, versions that no longer get official updates.

For the technical team

1. Update PHP to 8.5.12, 8.4.27, 8.3.36, or 8.2.35. Linux distributions and LTS vendors received the patches in advance, so if your PHP comes from a distribution package such as Ubuntu or Debian, check that distribution's security notices. The version number may differ even when the patch is included.
2. Restart every worker, PHP-FPM or Apache, after updating, so the new version is actually in use.
3. Check the version that actually serves the website. php -v in a terminal isn't necessarily the same PHP your web server uses, especially on servers with several PHP versions. In WordPress, you can see it under Tools, Site Health, the Info tab, in the Server section.
4. If you use Docker, rebuild the image from an updated base image, then redeploy. Updating the host server doesn't automatically reach inside the container.
5. If you can't update today, the PHP team gives temporary mitigations, such as turning off session.upload_progress.enabled and limiting request sizes. The PHP team stresses that these only reduce the risk and are not a fix.
6. Check your logs for the signs Wiz mentions, such as unusual multipart requests followed by memory limit errors, repeated 500 errors, or PHPSESSID cookies of unusual size. But as Rapid7 points out, clean logs don't prove a server is safe.

If your website sits behind Cloudflare, Help Net Security reports that Cloudflare's CTO said initial WAF (web application firewall) rules for known attack patterns are in place for all customers, including the free plan. That helps, but it's still not a substitute for updating.

For owners, what to ask your team

You don't need to understand the technical details. What you need to make sure of is that someone is responsible and the answers are clear. You can send this message straight to your IT team, developer, or vendor:

Hi team, there's a critical security flaw in PHP (PHP2Shell, CVE-2026-109618 and CVE-2026-109619), patched on October 21, 2026. The flaw is in PHP, so it applies to Laravel, CodeIgniter, and WordPress too. Please check and get back to me today:

1. Which of our websites and apps use PHP, including admin panels, internal systems, and old websites nobody opens much?
2. Which PHP version does each one run on, and on which server or hosting?
3. Have they been updated to a patched version (8.5.12, 8.4.27, 8.3.36, 8.2.35, or a distribution package that includes the patch)? If not, when?
4. For anything still on PHP 8.1 or older, what's the plan?
5. If we can't update today, what temporary mitigations are in place?
6. Has anything unusual shown up in the server logs over the last few days?

Three answers to watch out for:

• "It's fine, our Laravel or WordPress is the latest version." The flaw is in PHP, not in the framework.
• "We'll check later." The PHP team is asking every user to update immediately, and attack attempts are already happening.
• "That's the host's job." That may be true, especially on shared hosting. But make sure someone actually asks the host and gets written confirmation.

If your website or app was built by a vendor whose contract has ended, a flaw like this can become a blind spot. The developer feels the job is done, and the owner assumes the vendor is looking after it. I cover this, including why a maintenance contract matters, in You Don't Need to Understand Code, But You Need to Know This Before Paying a Developer.

Wrapping up

PHP2Shell is in the foundation, so whatever framework you use, the answer is the same: update PHP. As an owner, you only need to confirm three things today: who looks after the server, which PHP version it runs, and when the update will be done.

If you're not sure which PHP version your company's website or apps run on, or who looks after them, tell me about your setup first.