Critical PHP Vulnerabilities: What Happened and Why Our Clients Had Nothing to Do

Ricardo Figueiredo

Co-Founder

Stay Up to Date With Us

News letter form

This field is for validation purposes and should be left unchanged.

Share this Post

Blog categories

PHP Blog Post Featured Image

On October 21, 2026, the web had a rough day. Two critical vulnerabilities in PHP, the programming language WordPress runs on, were made public, and security agencies around the world told organizations to patch right away. Some government, school and hospital websites in Europe went offline as a precaution.

If you’re a Collective42 client, here’s the short version. Your site was patched the same day, and there was nothing you needed to do.

Here’s what happened, how it was handled, and what to do if your site lives somewhere else.

What happened

On October 20, the PHP security team gave advance notice of an urgent release. On October 21 it shipped the fixes in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. The two flaws are tracked as CVE-2026-109618 and CVE-2026-109619 and have been nicknamed “PHP2Shell.” According to PHP, they can allow an attacker to run code on a server without logging in, and every PHP installation serving web requests was at risk.

CISA, the U.S. Cybersecurity and Infrastructure Security Agency, urged organizations to patch immediately. Reuters reported that EU cybersecurity officials warned organizations that couldn’t apply the fixes to consider taking affected websites offline. Many did exactly that.

This was a big deal for a simple reason. PHP sits underneath a huge share of the web, including every WordPress site.

How WP Engine handled it

Our clients’ WordPress sites are hosted on WP Engine, a managed WordPress platform. WP Engine posted updates on its public status page throughout the day. Here’s the timeline as WP Engine reported it (all times Pacific):

  • 6:40 AM: PHP began releasing patches. WP Engine said it had already deployed protective mitigations at the CDN layer through Cloudflare and Fastly.
  • 10:30 AM: WP Engine said it was deploying patches, with mitigations active at both the CDN and hosting layers.
  • 2:52 PM: WP Engine said every PHP version on its platform (7.4, 8.2, 8.4 and 8.5) would be updated.
  • 6:19 PM: WP Engine reported the deployment complete (7.4.33.17, 8.2.35, 8.4.27 and 8.5.12) across North America, Europe and Asia/Pacific, and resolved the incident with no customer action needed.

That evening, WP Engine emailed customers a notice titled “No Action Required: Critical PHP Security Update Applied.” It said the patch had been applied and that WP Engine had mitigations in place before the official patch was released.

What it meant for our clients

Nothing to do. No plugins to update, no settings to change, no late-night scramble.

Several clients emailed us that morning asking if they were affected. Fair question, and a smart one to ask. We replied promptly with where things stood and a link to WP Engine’s status page, then followed up once WP Engine confirmed the rollout was complete.

That’s the job. You shouldn’t have to read security bulletins to know whether your website is safe.

Why managed hosting and a partner matter

Moments like this make the value easy to see.

  • This was a server fix, not a WordPress fix. Wordfence, a WordPress security company, warned that WordPress’s usual automatic updates would not apply it. Updating plugins and themes doesn’t touch PHP. Someone has to own the server.
  • On a managed platform, a dedicated team owns it. WP Engine says it had protections in place before the patch landed and finished patching the same day.
  • An agency partner closes the loop. We watch the situation, translate it into plain English, and confirm your site is covered.

For our clients in healthcare, life sciences, medical devices, aerospace and manufacturing, this matters even more. Your website is part of your reputation and often part of your compliance story. “We think we’re fine” isn’t good enough. “Here’s the confirmation” is.

On self-managed or budget hosting? Do this today

  1. Find out who is responsible for PHP on your server. On shared hosting, that’s usually your host. On a VPS or your own server, it’s probably you.
  2. Check your PHP version. In WordPress, go to Tools, then Site Health, then the Info tab, and open the Server section. The fixed releases are 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Some hosts apply the fix to the version you already run, so the number alone may not tell the whole story.
  3. Ask your host directly. Ask whether the fixes for CVE-2026-109618 and CVE-2026-109619 are applied to your site, and get the answer in writing.
  4. Running PHP 8.1 or older? The PHP project no longer ships updates for those versions. Ask your host about backported fixes and plan an upgrade.
  5. Can’t patch yet? CISA’s guidance is to take PHP-based systems offline until they can be patched.

A web application firewall like Cloudflare can help in the meantime. Cloudflare’s own CTO called its rules a stopgap, though, and said to patch as soon as possible. Patching is the fix.

Want this to be a non-event next time?

If you’re not sure where your site stands, or you’re tired of being your own IT department, let’s talk. We’ll take a look, tell you plainly what we find, and help you get set up so the next security headline is just a headline. Reach out at collective42.com.

Sources

Request a Call

Not sure where to start? Let’s discuss your goals.

Start a Project

Ready to get started? Tell us your project details.