When php2shell surfaced, teams running PHP sites had to make high-stakes decisions before every detail was settled. Some followed guidance to take their sites offline. Others checked runtime versions, logs, and dashboards. At the same time, agencies fielded urgent questions about whether cached content could still be served, whether a fix was really in place, and what the next request might mean.
That was the mood across the community response to php2shell during Pantheon’s LinkedIn Live (watch the recording to get all the color). One developer asked whether a site could be taken offline while still allowing cached requests to be served. Another asked how to explain a shutdown to clients.
php2shell may be behind us. The questions it surfaced are not.
Three Pantheon leaders offered distinct perspectives on the php2shell response: Steve Persch, Principal Developer Advocate, translated the unfolding response into practical questions for web teams; William Burke, Director of Security Engineering, explained the technical response; and Josh Koenig, Co-founder, described the communication and architectural decisions that helped reduce uncertainty and limit risk.
First, what was php2shell really a test of?
php2shell was a critical PHP vulnerability involving a potential two-stage attack. The incident, which some have dubbed Black October, was not proof that PHP is fundamentally insecure. The more useful distinction is between PHP itself and the security practices and deployment choices surrounding a PHP application. Current software, controlled production changes, layered defenses, monitoring, and practiced incident response all matter.
So the useful question is not whether PHP is simply “secure” or “insecure.” The useful question is whether the PHP application and the platform around it can be kept current, monitored, and controlled when the situation changes quickly.
For a technical deep-dive, read Pantheon’s CISO Joey Stanford blog.
How can teams verify that a patch is actually in place?
The clearest pain point raised was the difference between being told that a runtime was updated and being able to verify the exact build.
One developer described how the Pantheon platform handled the runtime update without requiring manual intervention. But the dashboard showed PHP 8.3 without the patch level or last-updated date. That is normally a reasonable simplification. During a phased response to a critical vulnerability, it can leave two materially different environments looking identical.
The request was simple: show the full patch version, show when it was updated, and name the fixed build in the security announcement so teams can compare the two.
As the commenter put it, “I’d rather know it.”
Does responding mean taking every site offline?
For some teams, the immediate response to a critical vulnerability was to take the site offline. That may be the right decision in some circumstances, but the community questions showed why teams need more than one emergency setting.
The resolution is a prepared set of response options that match the vulnerability, the exposure, and the defenses already in place.
For sites using Advanced Edge, putting a site into a read-only mode is one such option. This was described as a “break glass in case of emergency” capability that can shut off POST requests while continuing to serve content from GET requests.
The next step for teams is to understand which response modes are available, what each one protects against, and how to explain the choice to stakeholders. Those decisions are much easier to make before an incident than during one.
What defenses should teams expect during the patch window?
A security update is not the only control that matters while a vulnerability is being addressed. One application development leader asked how Pantheon was handling the 60,000 probing requests cited during the rollout, whether the CDN rules were already in place, and what those rules looked like.
That question gets to the heart of layered defense. A runtime update, traffic monitoring, request logs, web application firewall protections, and edge controls each address a different part of the problem. Together, they can help create time for teams to assess and respond.
The practical next step is to document those layers before they are needed. Teams should know who can restrict traffic, where relevant logs live, how changes are deployed, and which controls can be activated without creating a second incident.
How should teams prepare for faster, more AI-enabled attacks?
Questions about the future went beyond php2shell. A CISO asked whether teams should add AI-enabled code quality checks to pre-commit and pull-request workflows, and whether AI red teaming could help identify attack chains before they reach production.
The practical answer is measured. AI can help analyze large volumes of logs, identify patterns, and draft narrowly scoped response scripts. Experienced people still need to validate the output, understand the context, and authorize the action.
That balance is especially important as the time between disclosure and exploitation gets shorter. AI may help teams move faster, but speed is useful only when the response remains bounded, reviewable, and connected to the actual environment.
Is PHP secure?
PHP is not inherently insecure, but it is not secure by default.
Security depends on how quickly software can be updated, how well production changes are controlled, how traffic is monitored, how secrets are protected, and how many response options a team has when conditions change.
The strongest response is not panic, and it is not blind reassurance. It is a clear set of controls, evidence, and decisions that people can rely on when the next critical vulnerability arrives.
Watch the entire conversation and let us know how Pantheon can help!
