Two critical remote code execution vulnerabilities in PHP, tracked as CVE-2026-109618 and CVE-2026-109619, are being actively exploited after details leaked ahead of the October 21, 2026 patch release. The PHP security team rates both flaws CVSSv4.0 9.2. CERT-EU advisory 2026-018 warns the vulnerabilities could affect all PHP versions from PHP 5 onwards. According to Tenable, Cloudflare CTO Dane Knecht reported his company is seeing early attacks emerge. If your business runs a website, web application, or backend system built on PHP, you need to confirm today that your hosting provider or IT team has updated to PHP 8.5.12, 8.4.27, 8.3.36, or 8.2.35.

PHP powers approximately 69% of websites with a known server-side language, according to W3Techs. WordPress, WooCommerce, Drupal, Joomla, Magento, Laravel, and countless custom applications run on PHP. For small and mid-sized businesses across the US and Canada, the exposure is rarely direct: you may not know whether the platform you rely on embeds PHP or what version it runs. That gap between "I have a website" and "I need to patch PHP today" is where risk hides.

What Is PHP2Shell and Why Does It Matter?

PHP2Shell is the nickname researchers gave to two critical vulnerabilities (CVE-2026-109618 and CVE-2026-109619) in PHP's core. According to the PHP security team's October 20 announcement, both flaws are rated CVSSv4.0 9.2, a score CERT-EU says indicates the potential for unauthenticated remote code execution. Sansec reports the vulnerabilities affect every PHP release from 5.4.0 onward. This means a successful attacker could run commands on your server without needing a login, password, or any existing foothold in your systems.

The name follows a familiar pattern: just as "Log4Shell" named the critical Log4j flaw in 2021, "PHP2Shell" signals that sending a crafted request can hand attackers a shell on a vulnerable server. For business owners, the technical details matter less than the outcome: total control of the web server, access to databases, credentials, and customer data, and the ability to pivot deeper into connected systems.

Which PHP Versions Fix PHP2Shell?

The PHP security team released the fixes on October 21, 2026, as scheduled for 14:00 UTC (10:00 AM Eastern, 7:00 AM Pacific). According to the official PHP security advisory, PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35 fix both vulnerabilities, and all PHP users are strongly encouraged to update immediately. Linux distributions and LTS vendors received the patches in advance, so check your vendor for updated packages. PHP 8.1 and older no longer receive updates from the PHP project, though the security team published minimal source backports for PHP 7.4, 8.0, and 8.1 for people who build from source.

If you manage your own PHP servers, update today using your distribution's packages or the downloads on php.net. If your hosting provider manages PHP updates, contact them to confirm they have applied the fix.

Has Exploitation Already Started?

Yes. According to Tenable, Cloudflare CTO Dane Knecht stated on October 21 that the company is "seeing early attacks emerging" and is updating mitigations as new attack vectors appear. Sansec reported that Cloudflare first reported early attacks at 07:43 UTC on October 21. Security firm Huntress reports that watchTowr confirmed the vulnerabilities are real and said it reproduced CVE-2026-109618.

Attacks started before the patch was available because details leaked ahead of the coordinated disclosure. According to Huntress, a post on Hacker News on October 20 revealed the upcoming vulnerabilities, and screenshots spread across social media before the post was removed. According to watchTowr, the vulnerabilities were originally set to be disclosed on Thursday, October 22, under embargo, so the leak pushed the PHP release up by a day.

Why Configuration Changes Will Not Protect You

Some settings can reduce exposure while you schedule the update, but PHP's own developers and its official advisory are clear that they do not replace it. According to Tenable, PHP core developer Gina Peter Banyard stated before the release that "the only mitigation is patching / upgrading PHP." Tenable also reported that PHP 8.6 release manager Joe Ferguson, responding to a suggestion that included turning off session upload progress, stated "ini settings won't save you."

PHP's official advisory now lists settings, such as turning off session upload progress, that reduce exposure to specific attack paths, but it says they do not make an installation safe and that only an update is a complete solution. Aikido Security gives the same warning, saying its temporary mitigations "reduce exposure but do not make an installation safe." If you cannot patch immediately, isolation from the public internet is the fallback.

Which Businesses Are Actually Exposed?

Any organization running PHP on an internet-facing server. The population is large: W3Techs reports PHP powers 69.3% of all websites with a known server-side language. Tenable cited security researcher Silas Cutler's rough estimate of over 1.3 million internet-exposed hosts, and a Shodan search by Henk Poley counted over 1.9 million internet-exposed hosts running PHP.

For most small businesses, the exposure is indirect. You run WordPress, WooCommerce, Magento, Drupal, Joomla, or a custom web application built in Laravel or another PHP framework. PHP runs beneath the platform. Unless you check, you may not know which PHP version is active or who is responsible for updating it.

  • Self-hosted or VPS: If you manage your own server, you are responsible for updating PHP. Check your version with php -v on the command line or in your control panel (cPanel, Plesk, etc.).
  • Managed hosting (shared, managed WordPress, etc.): Your hosting provider typically handles PHP updates. Contact them to confirm they have applied the patch.
  • Fully hosted website platforms (Webflow, Squarespace, Wix): The platform manages the server software for you, so patching is the platform's job, not yours. Check its status page if you want confirmation.

WordPress sites face particular attention because of the platform's scale. As we covered in our analysis of WordPress security risks in 2026, nearly 8,000 WordPress-ecosystem vulnerabilities were discovered last year, with 96% in plugins. PHP2Shell is different: it hits PHP itself, which means every WordPress, WooCommerce, or Magento site is potentially affected regardless of which plugins are installed.

Why Internet Exposure Matters More Than You Think

A critical flaw in a core component like PHP underscores a principle that applies to every serious vulnerability: if an attacker cannot reach it, they cannot exploit it. This is why CERT-EU recommends that organizations "consider isolating internet-facing applications from public networks until a fix is available" when immediate patching is not feasible.

For business owners, the practical version of this is straightforward. Sensitive administrative interfaces, internal web applications, and backend systems should not be reachable from the open internet unless absolutely necessary. Tools and approaches that implement this include:

  • VPN or ZTNA (Zero Trust Network Access): Require authenticated, encrypted access before anyone can reach internal systems.
  • IP allowlisting: Restrict access to specific known IP addresses, such as your office or a list of remote employee IPs.
  • Web Application Firewalls (WAFs): Services like Cloudflare can filter malicious traffic. Cloudflare deployed WAF rules for PHP2Shell's known exploit vectors for all customers including the free tier, according to Tenable. Cloudflare itself describes the rules as a stopgap, not a replacement for patching.

When a vulnerability like PHP2Shell appears with little warning and active exploitation, organizations with tighter network controls have more options. They can block access, patch deliberately, and verify before reopening. Organizations with everything exposed to the internet are racing the attackers.

Why Fast Exploitation Is the New Normal

PHP2Shell is not an isolated case. The time between vulnerability disclosure and active exploitation is shrinking. According to our earlier analysis of the CVE-to-exploit window, exploit-intelligence data suggests that attackers are weaponizing vulnerabilities within roughly 10 hours of disclosure. The Canadian Centre for Cyber Security's National Cyber Threat Assessment 2025-2026 states that "the time it takes threat actors to exploit these vulnerabilities continues to decrease, with attacks starting within days after their disclosure."

The same assessment notes that "cybercriminals driven by profit are increasingly benefiting from new illicit business models to access malicious tools and are using artificial intelligence to enhance their capabilities." It further states that "AI technologies are almost certainly lowering the barriers to entry and enhancing the quality, scale, and precision of malicious cyber threat activity" and that "technically skilled cyber threat actors will almost certainly attempt to misuse AI tools in novel ways over the next two years."

For business owners, the implication is clear. Every critical vulnerability is now a race, and the window to patch before exploitation is measured in hours, not weeks. If your patch process depends on someone remembering to check for updates, or if you do not know who is responsible for patching your web servers, PHP2Shell is a reminder that the gap matters.

Do You Know Which of Your Systems Run PHP?

Many small businesses cannot answer this question confidently. The first step is identifying exposure. Here is a practical inventory checklist:

  1. Your main website: Is it WordPress, Joomla, Drupal, Magento, or another PHP-based CMS? Is it on managed hosting (where the provider patches PHP) or self-hosted?
  2. E-commerce: WooCommerce, Magento, PrestaShop, and OpenCart all run on PHP.
  3. Internal web applications: Custom portals, dashboards, or tools built by developers or vendors. Ask whether they run on PHP.
  4. Control panels: cPanel, Plesk, and similar hosting control panels often serve PHP applications internally.
  5. Vendor software: Some business software bundles PHP for its web interface. Check with the vendor.

Once you have a list, identify who is responsible for patching PHP on each system. If you cannot answer that question for a system that faces the internet, escalate it today.

The Case for Managed Platforms and Managed Hosting

PHP2Shell highlights a structural advantage of managed website platforms and managed hosting providers. When a critical vulnerability drops with active exploitation, someone else's job is to patch immediately. Your job is to verify they did.

With fully hosted platforms like Webflow, Squarespace, and Wix, the provider manages the underlying server software, so patching is not your job. Managed WordPress hosts and managed PHP hosting providers handle updates for you, though you should still confirm they have applied this specific patch.

For organizations that need PHP's flexibility, choosing a provider with a clear patch commitment and verifiable response times is part of the security posture. As we discussed in our guide to evaluating managed IT providers, monthly or quarterly reporting on patch status should be standard, and a critical vulnerability like PHP2Shell should trigger immediate action with communication, not silence.

One Question to Ask Your IT Provider Today

Before the end of the day, ask your IT lead, web developer, or hosting provider this: "Do any of our internet-facing systems run PHP, and have you applied the patch for CVE-2026-109618 and CVE-2026-109619?"

The answer should include:

  • Which systems run PHP and what version
  • Who is responsible for patching each one
  • When they applied the fix, or when they will (the answer should be "already done" or "today")
  • Whether any systems are running end-of-life PHP versions that will not receive a patch

If your provider cannot answer these questions, that is itself an answer about your exposure.

If You Are Running End-of-Life PHP

PHP versions 8.1, 8.0, 7.x, and 5.x are all past their official support dates. The PHP project does not ship new releases for these branches. Its security team published minimal source backports for PHP 7.4, 8.0, and 8.1, but those are for people who build PHP from source. If you are running end-of-life PHP on an internet-facing server:

  1. Upgrade immediately to a supported PHP version (8.2 or later) and apply the patch.
  2. If you cannot upgrade today: Take the application offline or isolate it from the public internet behind a VPN or firewall until you can.
  3. Check with your Linux distribution: PHP's advisory says some distributions and LTS vendors provide backported fixes for older versions. Check your vendor's advisories.

Running end-of-life software on the internet is always a risk. When a critical RCE drops with no fix for your version, the risk becomes acute.

The Broader Lesson

PHP2Shell is a reminder that the software powering your website is infrastructure, and infrastructure requires maintenance. PHP is everywhere. Most of the time, that ubiquity is invisible. Today, it is a liability unless someone is patching it.

For SMBs, the lesson is not to become PHP experts. It is to know the answer to three questions: what runs PHP in our environment, who patches it, and how fast. If you are not sure, start with our free quick security assessment. It takes under five minutes, covers 22 security areas, and can help you identify which parts of your infrastructure need closer attention.

This article is intended for general informational purposes only and does not constitute professional security, legal, or compliance advice. Details about CVE-2026-109618 and CVE-2026-109619 are based on public advisories from the PHP security team, CERT-EU, Tenable, Huntress, Sansec, Aikido Security, and Cloudflare as of October 21, 2026. The situation is evolving rapidly, and technical details may change as researchers publish more analysis. Organizations should consult qualified cybersecurity professionals before making operational changes based on this article.