Two critical bugs in PHP, the open source language behind roughly 70% of websites, set off a rapid effort to protect affected systems. Some organizations took sites offline while they waited for patches. For Tomer Schwartz, CTO of Exposure Management & AppSec at Google-owned Wiz, the episode also points to a bigger concern: AI could change how quickly new vulnerabilities are found and exploited.
A patching scramble with wider stakes
The PHP bugs drew researchers and maintainers into a race to fix the problem. Schwartz was part of that effort alongside OpenAI, research group Calif, and the PHP team. The source does not describe the technical details of the vulnerabilities, but it makes clear that their severity forced organizations to act quickly.
Taking a site offline illustrates the tradeoff facing organizations during a critical security response. Keeping a service available may expose systems to risk while a fix is pending; shutting it down can disrupt the people who rely on it. Each organization must weigh those costs as it works to apply a patch.
The immediate repair is only one part of the challenge. Teams also need to identify which systems are affected and complete the work across them. The account of the PHP incident underscores how a vulnerability in widely used software can create pressure well beyond the researchers and developers who first investigate it.
Why AI could accelerate the cycle
Researchers who found the bugs warned that this may be only the beginning. Their concern is that AI could change the pace at which novel vulnerabilities are uncovered and exploited. If discovery and exploitation move faster, organizations may have less time to understand a flaw, prepare a response, and apply a fix.
That prospect makes speed a practical security issue, not just a research question. A response that depends on people manually finding and patching each affected system may struggle when teams have to act across many systems under time pressure. Schwartz and podcast host Rebecca Bellan discuss why patching by hand will not scale.
The episode does not give a timeline for a future wave of vulnerabilities or say that every organization will face the same exposure. Its central warning is about the changing pace of the work: defenders need to be ready for problems to surface and spread faster than a manual process can comfortably handle.
Building security into startup work
Schwartz and Bellan also discuss how early-stage startups can build with security in mind. That focus matters because security decisions made while a product is being built can affect how difficult it is to respond when a vulnerability appears. The PHP incident offers a concrete reason to treat vulnerability response as part of building and operating software.
For a startup, the discussion raises straightforward questions: how will the team know which systems need attention, how will it coordinate a fix, and what happens if a service must be taken offline? The source does not prescribe particular tools or procedures, but it connects these questions to a clear limit: manual patching alone will not scale.
The episode’s account of PHP2Shell links an urgent repair effort to a longer-term shift in security work. A fast fix matters, but organizations also need a way to respond across their systems as new vulnerabilities emerge. As AI changes the speed of discovery and exploitation, the ability to keep that response moving becomes more consequential.