Critical PHP flaws intensify pressure for automated remediation

Two critical vulnerabilities in PHP, the open-source programming language behind roughly 70% of websites, recently sent organisations into a race to patch affected systems. Some operators took websites offline while applying fixes, underscoring the operational disruption that can follow a severe flaw in a widely deployed component.

Tomer Schwartz, CTO of Exposure Management & AppSec at Google-owned Wiz, described the response on TechCrunch’s Equity podcast. Schwartz was involved in the remediation effort alongside OpenAI, research group Calif and the PHP team.

A broad PHP patching challenge

The immediate issue was the pair of critical bugs, but the response extended beyond applying updates. Organisations had to determine where PHP was running, identify affected systems and decide whether services could remain online during remediation. The fact that some sites were taken offline illustrates the trade-off between availability and exposure when critical vulnerabilities emerge.

PHP’s reach makes those decisions consequential. A vulnerability in a language used across a large portion of the web can create a patching task that spans websites, applications and the infrastructure supporting them. Teams that do not have a clear inventory of deployed software face additional pressure when fixes must be prioritised quickly.

AI changes the vulnerability timeline

Researchers who found the bugs said the PHP incident is only the beginning. Their concern is that AI is changing the speed at which novel vulnerabilities can be uncovered and exploited. That shorter window raises the importance of moving from discovery and assessment to remediation without relying solely on manual action.

Schwartz and Equity host Rebecca Bellan also discussed how early-stage startups can build with security in mind. The central operational point is that patching by hand does not scale, particularly when critical flaws affect broadly used technologies and the pace of vulnerability discovery increases.

What organisations can take from the incident

The PHP response points to a practical discipline: maintain visibility into where core components are used, assign responsibility for patch decisions and prepare workflows that can accelerate remediation when a critical issue appears. Taking services offline may sometimes be necessary, but it should be a deliberate option rather than the first way to discover an organisation’s exposure.

For business and technology leaders, the implication is to treat automated, accountable remediation as part of operational resilience, so that a widely used dependency does not turn the next critical disclosure into an extended service decision.