After PHP2Shell: How CISOs Can Be Ready for the Next Zero-Day

On October 20, two critical vulnerabilities in PHP leaked online, ahead of a coordinated disclosure. Known as PHP2Shell and tracked as CVE-2026-109618 and CVE-2026-109619, the flaws sit in the core engine of PHP, the programming language behind WordPress, Drupal, Joomla, Magento, and many other web applications. They affect every version back to PHP 5.4 and let an attacker take control of a web server remotely, with no login or credentials required.

PHP released fixes the next day. Once the flaws were public, exploitation attempts jumped from a handful to millions within minutes, and AI agents meant even an unskilled attacker could build a working attack. Our research team's breakdown has the full technical details.

PHP runs roughly 70% of the web, so for most organizations it’s everywhere: the marketing site, the e-commerce platform, shared hosting, control panels, and software bundled inside vendor appliances. Many of those installs are easy to forget. Roughly 1.5 million internet-facing hosts advertise a PHP version, and more than half run versions with no official fix. So the question that landed on CISOs' desks was simple: are we exposed?
‍

PHP2Shell is part of a larger trend

Industry leaders are warning that PHP2Shell is only the beginning of a larger trend. Days after the disclosure, Gizmodo reported that OpenAI CEO Sam Altman told an audience at Stanford's Graduate School of Business he no longer believes organizations can "just patch all the bugs." His point: many organizations treated the Claude Mythos announcement as a one-time event, patched what the models found, and moved on while the models kept improving.

PHP2Shell shows why that approach no longer works. Frontier AI is changing the speed, scale, and sophistication of attacks, and that forces defenders to move away from patching everything. With PHP2Shell, a patch existed within a day, but many versions had no official fix, PHP inside vendor appliances depended on the vendor, and every update needed testing and restarts. Meanwhile, several threat groups and botnets were already targeting both flaws. Patching alone can't close that gap.

At Zafran, we see this as the point where the traditional remediation cycle breaks down. Scoping the exposure, planning the fix, and handing it off for remediation works when teams have weeks. In the AI era, they have hours. Security teams need defenses that are built and ready before the attack comes.

Patching is still the priority, starting with internet-facing systems. The work around the patch needs to move faster: knowing where you're exposed before scanners catch up, and having a tested mitigation ready for the systems you can't patch yet.
‍

What you need before the next zero-day

Know where you're exposed, and be able to prove it

Your executives will ask "are we affected?" within hours. A credible answer covers three things for each asset: whether the vulnerable software is there, whether it's running, and whether an attacker can reach it. For PHP2Shell, finding every install was the hard part: PHP sits in vendor appliances, control panels, container base images, and bundled software, where a single tool can easily miss it. Evidence matters just as much when the answer is "we're protected." If a WAF rule or IPS signature blocks the attack path, document it. That record is what lets you defend a patch schedule to auditors and leadership.

Have a mitigation ready before uncertainty forces an outage

When teams can't tell what's exposed, the default is to take systems offline. For customer-facing applications, that means downtime and lost revenue. A tested mitigation, deployed through tools you already own, reduces the risk without that cost. Vet workarounds carefully, since the ones published for PHP2Shell were partial and could be bypassed. Treat any mitigation as a first step while your team tests and deploys the patch.

Keep the response in your normal workflow

A separate scramble for every zero-day wears out your team and stalls routine work. Each new exposure should land as tracked work, assigned to an owner, with an SLA and a mitigation, in the ticketing system you already use. That keeps the response auditable and repeatable, and it removes slow handoffs from the first critical hours.

Brief leadership early, in business terms

Executives will ask before you have every answer. Get ahead of them with a short brief in the first day, and be ready for these questions:

• "Are we affected?" Give numbers: how many assets run the affected software, how many are reachable, and how many your existing controls already protect.
• "Do we need to take anything offline?" Explain the mitigations in place and what would change that decision, such as confirmed exploitation in your sector.
• "When will it be fixed?" Share patch target dates, and name the systems with no available fix along with the plan for them.
• "Does this reach beyond our own systems?" Cover exposure through vendors and third parties, and any customer or regulatory communication needed.
  ‍

How Zafran helped customers respond to PHP2Shell

Finding every PHP asset. Zafran builds its software inventory from live data in the tools customers already run, and Zafran Discover adds continuous, agentless scanning through existing EDR agents. Inventories and CMDBs that update on a schedule can miss a PHP runtime added last week, and scanners needed time to publish detections for the new CVEs. Customers using Zafran Discover didn't have to wait for either: they could see every asset running PHP, and which version, as the news broke.

Answering "are we exposed?" before the scanners could. Zafran's Zero Day agent pulled threat intelligence on PHP2Shell, searched each customer's inventory for vulnerable versions, and checked every match: is PHP running, is the asset reachable from the internet, and does an existing firewall, WAF, or EDR already block the path? Where data was missing, it flagged the gap and did not assume the asset was safe. Results came back grouped by business unit, owner, and criticality, ready to route as tickets.

Protecting systems that couldn't be patched yet. Many PHP versions had no official fix, and PHP said its own suggested mitigations didn’t fully solve the problem.

Where vendors like CrowdStrike, Fastly, and Palo Alto Networks had published rules, Zafran surfaced them. Where they hadn’t, Zafran wrote its own. The Zafran Research team built and lab-tested Snort and Suricata signatures for the exploit. Deployed inline on an IPS with the action set to drop, they block multipart POST requests that carry both PHP_SESSION_UPLOAD_PROGRESS and PHPSESSID. Customers see the mitigation directly on PHP2Shell findings in the platform.

The result: on CVE-2026-109619, vendor mitigations alone covered 4.7% of findings. With Zafran's custom mitigations added, coverage reached 17.8%, 3.8 times as many. For 3,032 findings, Zafran's mitigation was the only one available.
‍

Plan for the next one now

Altman's warning: zero-days like PHP2Shell will keep coming, and the teams that respond fastest will be the ones that are prepared. Measure your readiness by how quickly your team can assess, protect, and brief leadership.

That's the idea behind how we built Zafran: defenses that are ready before the attack comes. It works from live data in your existing tools, checks exposure before scanners have a detection, shows which assets your controls already protect, and gives you a mitigation for the ones they don't. For PHP2Shell, Zafran also wrote its own rules where vendors hadn't, which raised mitigation coverage 3.8 times over vendor rules alone. Every zero-day runs through the same steps, so your team has no new process to invent under pressure.