Two critical PHP flaws expose 70% of the web and trigger mass patch alert

What happened

In the week before October 28, 2026, two critical flaws were discovered in PHP, the open source language that powers approximately 70% of the web's sites, according to data cited by TechCrunch. The case, nicknamed "PHP2Shell" in the episode of the Equity podcast that covered the topic, led organizations to race against time to apply fixes, and some even took sites offline until the patch was completed.

The account came from Tomer Schwartz, CTO of Exposure Management and AppSec at Wiz (a cloud security company acquired by Google), in an interview with journalist Rebecca Bellan on the Equity podcast, by TechCrunch. Schwartz was part of the group that rushed to fix the flaws.

Who went to the front line

According to TechCrunch, the response to the flaws brought together a diverse group of actors in a short time:

• Wiz, through the arm led by Schwartz;
• OpenAI, cited as part of the joint effort;
• a research group identified in the report as Calif;
• the PHP maintenance team itself.

The source does not detail CVE numbers, the specific PHP versions affected, or the exact technical exploitation vector of the flaws. What is clear is the scale of the effort: multiple organizations had to coordinate a rapid fix for a component that underpins most of the web.

Why this time is different

The central point raised by the researchers interviewed by TechCrunch is not the isolated severity of the two flaws, but what they signal: artificial intelligence is changing the speed at which novel vulnerabilities are discovered and exploited. In the view of those who found the bugs, the episode is just the beginning of a faster cycle of discovery and attack, which justifies the term "vulnpocalypse" used in the episode's title.

In short: if AI tools speed up both the search for flaws and the creation of exploits, the interval between the disclosure of a vulnerability and its mass exploitation tends to shrink. This changes the risk calculation for any team that keeps PHP in production, because the window to apply the patch before the attack gets smaller.

Active exploitation already confirmed

Two days before the episode was published, TechCrunch itself had already reported that the United States government confirmed hackers actively exploiting critical PHP-based web flaws, according to a reference included on the same report page. In other words, the scenario was not confined to theory: real-world exploitation was already underway while teams were still patching systems.

For those managing PHP infrastructure in Brazil, this matters directly. The country has a huge base of PHP applications: WordPress (which runs on PHP) dominates a significant share of Brazilian corporate and institutional sites, Laravel is one of the most widely used frameworks among local product squads, and much of the shared hosting offered by domestic providers runs legacy PHP stacks, often without automatic updates.

What remains unclear

TechCrunch's report, being a summary of a podcast episode, does not bring the technical details that normally accompany a security advisory: there are no CVE numbers, no list of affected PHP versions, and no public indication of indicators of compromise. Those who administer PHP servers need to seek this information directly from the official channels of the PHP project and from the security bulletins of their distribution or hosting provider.

In the podcast, Schwartz and Bellan also discussed two points that go beyond the specific incident: how early-stage startups can build security in from the architecture design stage, and why patching manually, bug by bug, server by server, is not a strategy that scales for organizations with many PHP instances in production.

What to do now

Even without the full technical details of PHP2Shell, the episode serves as a practical reminder for anyone keeping PHP running in production:

1. Check the PHP version across all environments, including those running behind a CDN or proxy, where forgetting a legacy server is common.
2. Confirm whether the hosting provider has already applied the latest security patches, especially on shared hosting plans.
3. Review whether the update process depends on manual intervention and, if so, prioritize patch management automation before the next incident of the same scale.
4. Follow the official security channels of PHP and the framework in use (Laravel, Symfony, WordPress) for future advisories, since the source of this episode does not list specific CVEs.

The underlying argument, raised by those who hunted the flaws, is that the speed of vulnerability discovery with AI support tends to increase. This does not mean panicking at every new bug, but it reinforces that relying on manual patching as the only line of defense becomes increasingly risky for those operating PHP infrastructure at scale.