On October 21, 2026, the team maintaining PHP released emergency security updates for a pair of critical flaws known as PHP2Shell. PHP runs websites and applications built on platforms such as WordPress, Drupal and Magento. The flaws can let an attacker take control of an affected server without logging in, and PHP’s advisory is blunt: update now.

Business leaders should confirm whether their organization is affected, who owns the fix and how completion will be verified.

Why leadership should care

PHP may power your public website, a customer portal, an online store or an application a vendor hosts for you. If one is compromised, the consequences are business ones: lost sales, interrupted service, exposed data or a trusted website turned against its customers. Investigation and recovery carry real costs, even when the website seems like a small part of the operation.

Your hosting provider may well install the fix. Leadership still needs to know it happened, everywhere it needed to.

Don’t wait but don’t panic

Details leaked before the official release. Cloudflare saw attack traffic before patches were out, and security firm watchTowr reports exploitation in the wild.

On October 22, Sansec reported the public attack tools it reviewed needed specific conditions to succeed and didn’t work against a default PHP installation. That finding concerns those tools, not whether default installations are safe. PHP continues to recommend immediate updates.

Real exposure depends heavily on how each environment is set up. A vulnerable version is not proof of a compromise. It is, however, a likely target, and unpatched software will attract attackers.

Assess your environment promptly, apply the update and document any protections needed while work remains outstanding. If taking a service offline comes up, weigh the risk, available protections and how much the business depends on it.

Getting the fix right

Updating a website’s content, theme or plugins does not fix PHP2Shell. The PHP software underneath has to be updated, whether your own team, a hosting company or another vendor runs it.

Some vendors have released fixes for older PHP versions, and PHP’s security team published limited fixes for a few older branches. Confirm the installed package covers these flaws. An emergency fix on unsupported software buys time; it doesn’t remove the need to move to a maintained platform.

Where patching will take time, temporary protections can help. CERT-EU suggests considering isolation of exposed applications when patching isn’t feasible. Your technical team should explain what risk remains and recommend the least disruptive effective option.

A patch fixes the weakness going forward. It says nothing about whether someone got in beforehand. If exposure justifies a closer look, preserve relevant records and evaluate possible compromise through your incident response process, involving legal and insurance where appropriate.

Four questions worth asking this week

1. Do we know every affected service running on our behalf?

Think beyond the main website to customer portals, online stores, older sites and vendor-managed applications. Ask for a list with a named owner for each. If “someone else handles our website,” get confirmation from them.

2. Who owns the fix and how do we know it’s done?

Look for confirmation by service, a completion date and how the update was checked. An external scan may not see the PHP version behind a website, so ask how the update was confirmed.

3. What protects us until every fix is in place?

Expect a target date, temporary protections and a plain explanation of remaining risk. Leadership may need to approve restrictions or downtime. Write down who accepted the decision and when it will be revisited.

4. Would we know if someone got in before we patched?

Ask what evidence exists and whether anything warrants specialist review. A compromise assessment can shed light on what happened, though incomplete records may leave questions open. A clean scan alone doesn’t prove a system was never compromised.

The bigger lesson

Wiz’s researchers credit AI as an important contributor to finding these long-hidden flaws and building working attacks. By Wiz’s account, a single researcher did in about a week what once would have taken a team months.

The lesson reinforces our discussion in The Shrinking Patch Window: organizations need a reliable way to identify exposure, assign responsibility and act quickly when a serious vulnerability becomes public.

Get verified answers on exposure and remediation first. Then address gaps in system inventories, vendor accountability and incident readiness before the next disclosure.

RubinBrown’s Cyber Security Services and Technology Consulting teams can help identify affected systems, confirm updates with your providers and investigate suspected compromise. Learn more about RubinBrown Cyber Security Services.

Published: 10/23/2026

_{^{Readers should not act upon information presented without individual professional consultation.}}

_{^{Any federal tax advice contained in this communication (including any attachments): (i) is intended for your use only; (ii) is based on the accuracy and completeness of the facts you have provided us; and (iii) may not be relied upon to avoid penalties.}}