Two critical PHP vulnerabilities, the widely used programming language underpinning millions of websites and web applications, have prompted urgent warnings from cybersecurity authorities worldwide.
Following reports on the 20th October that details of the vulnerabilities had leaked ahead of their scheduled disclosure, PHP developers released emergency security updates on 21 October. The UK’s National Cyber Security Centre (NCSC) urged organisations to identify affected systems and apply updates immediately, while Amazon’s threat intelligence team reported evidence of exploitation attempts dating back to 17 October.
With the vulnerabilities highlighting the potential consequences of security flaws in widely used web infrastructure, The IT Security Guru has gathered reactions from cybersecurity industry experts on the risks, implications and lessons for organisations.
Samuel Hassine, CEO and co-founder, Filigran:
“Taking a website offline for a day is a far cheaper decision than explaining a breach for a year. The agencies asking organisations to do exactly that are giving sound advice, and the speed of the coordinated response shows how much the discipline has matured. These flaws sat in code that dates back to 2004 and were found with AI. The same tools will help attackers move just as fast, and early attacks are already being reported. The job is simple to state and hard to do. Find every system running PHP, including the ones hidden inside third-party products. Update to a supported version or take it offline. Then check that nothing got in while the window was open. Patching is the easy part. Knowing what you run is the real test.”
Sai Molige, senior manager of threat hunting at Forescout:
“PHP2Shell has the potential to become a Log4Shell-scale event, but for a different reason. With Log4j, the main problem was finding a library you didn’t know you had. With PHP, much of the forgotten infrastructure will be found, but won’t have an upstream fix.
“The durable lesson from Log4j is that organisations should treat “How quickly can we identify where we run X” as a measurable capability separate from patching speed.
“Discovering vulnerable infrastructure, however, is only the first step. When older systems have no available fix or depend on a vendor update, organisations need to reduce exposure, restrict unnecessary connections, and isolate affected systems while planning remediation.
“AI is very good at performing variant analysis when it has a reference point, lowering the effort and expertise required. That could increase the volume of attempts we see with these critical vulnerabilities, even if many never turn into full exploits.
“Common places where forgotten PHP tends to live include:
- Vendor appliances whose admin UIs are PHP: NAS devices, some firewalls and VPN portals, printers, building-management panels, and OT/ICS HMIs with web front ends. Organisations cannot patch them directly and have to wait for vendors which introduces lag.
- Bundled runtimes. Control panels and commercial packages often ship their own PHP binary, invisible to the OS package manager.
- Containers pinned to old base images. The host is current; the image from 2021 isn’t.
- Marketing microsites, campaign pages, and acquired-company infrastructure, often on hosting accounts paid by credit card outside IT.
- Admin tools on dev or jump boxes: phpMyAdmin, Roundcube, Nextcloud.
- Origins behind a CDN or WAF that are still directly reachable, which quietly defeats your edge rules.
“Organisations concerned about exposure should prioritise identifying affected systems, reducing unnecessary external exposure, and follow vendor guidance for remediation or compensating controls. Teams should use a combination of external exposure scanning, host-level package managers, container or SBOM scans and network behavior to identify all implementations of PHP in their environment. Organisations who believe they are compromised should rotate secrets on exposed hosts, filter multipart at the edge, restrict agree from web workers, isolate EOL hosts. Look for classic web-shell patterns: php-fpm, httpd, or apache2 spawning sh, bash, curl, wget, or base64, new or modified .php files in web roots and outbound connections from web worker processes.”
Oliver Simonnet, Lead Cybersecurity Researcher at CultureAI:
“PHP2Shell is a clear example of how little time we now have as defenders to secure our environments in the age of AI. In a world where these types of vulnerability discoveries may become commonplace, and details being leaked before formal disclosure, exploits created exceptionally fast, and attackers exploiting the issue in the wild rapidly before fixes are even available. It’s almost impossible to justify a traditional maintenance window in this situation and what can you do if you know for a fact you’re vulnerable and you need to decide if you even can apply a temporary mitigation, or need take exposed systems offline. Its a nightmare scenario for security teams.
AI may play a part in making this worse as it helps attackers develop exploits faster, but its also what gives us the power to discover these issues so they can finally be fixed. So the challenge is now to arrive at a balance where we have the capability to not only identify exposed systems, but also develop effective mitigations and get them deployed before active exploitation can cause these types of disruptions.”
Charlotte Wilson, head of enterprise at Check Point:
“The scale of this is enormous. We’re talking about two serious security flaws in technology that underpins around three-quarters of the internet, potentially allowing criminals to access vulnerable systems remotely without even needing a password. We’ve become so dependent on digital services that we rarely stop to consider how much of our everyday lives relies on the same underlying technology. Governments, businesses, banks and public services are all connected through an increasingly complex web of systems, and when a weakness like this is discovered, huge numbers of organisations can find themselves exposed at once. It’s a bit like discovering that millions of buildings have been fitted with the same faulty lock. Suddenly, everyone is racing to change it before someone works out how to open the door.
We’ve already seen how disruption involving major technology providers can have consequences across the world, and there are growing questions about our reliance on a handful of companies to keep essential services running. Regulators are now looking much more closely at the role these providers play in our critical infrastructure. The timing is particularly concerning given the NCSC’s warnings that artificial intelligence will increase the frequency and intensity of cyberattacks. Criminals are becoming faster at identifying weaknesses and exploiting them, leaving organisations with less time to respond.
When governments are choosing to take their own websites offline rather than risk leaving them exposed, it gives you a pretty clear indication of how seriously this is being taken. The immediate priority is getting systems updated, but the bigger question is whether we’ve become too dependent on technology that can leave so many organisations vulnerable at exactly the same time.”
Ben Ronallo, director of cybersecurity operations at Black Duck:
“This is a genuine drop-everything moment for anyone running PHP. The flaws are in the PHP engine itself, so a perfectly secure application on top of a vulnerable runtime is still exposed. Updating WordPress or your framework won’t fix it. You have to update PHP itself and restart the services that run it. It’s understandable that people are confused about how this unfolded. Word of the vulnerabilities leaked on Y Combinator’s Hacker News forum two days before the planned disclosure, and PHP moved its security release up a day in response. The source of the leak hasn’t been identified, but there’s no evidence a threat group was involved, and no exploit code was released. A screenshot of the researchers’ exploit tool did circulate, which added to the alarm. In the end, the early reports were largely accurate. The main difference is severity: PHP officially rates both flaws 9.2 rather than the 10.0 some reports cited. That’s still critical, and it doesn’t change the advice. The organizations I’m most concerned about are the ones that don’t know where PHP is running in their environment. Older versions sitting in containers, appliances, or legacy sites won’t receive an official fix. Nobody wants to be building a software inventory in the middle of an emergency. You need that visibility before the next one hits.”
Tim Mackey, head of software supply chain risk strategy at Black Duck:
“Preventing leaks of any vulnerability data for a CVE prior to an embargo for the patch being published is precisely what coordinated vulnerability disclosure processes are designed to protect against. When a leak, or advance knowledge, of a vulnerability occurs the entire ecosystem surrounding the vulnerability is placed at risk. As details of the leak are published, security defenders are faced with the real risk that malicious actors could use the absence of an official patch to supply their own malicious patches. Defenders should pay extra attention to the origin of their patches and validate functional changes against official release notes. After all, a malicious patch could implant a backdoor for future use and a rush to patch might present the right opportunity for malicious actors.”
Jamie Akhtar, CEO and Co-founder of CyberSmart:
“The NCSC advises identifying PHP across your infrastructure, prioritising internet-facing systems, and not limiting the search to outdated versions. That includes appliances and services that bundle PHP, so keep monitoring for updates from third-party vendors.
Update to the latest version of PHP and apply the additional hardening steps from the PHP Team. If you cannot update, the PHP Team has provided temporary mitigations. If those cannot be applied, or would take too long, the NCSC suggests considering taking the system offline until it can be fully mitigated.”
The PHP2Shell vulnerabilities serve as a reminder of how quickly weaknesses in widely used software can become a global cybersecurity concern. As organisations work to secure affected systems, the incident reinforces the importance of timely patching, continuous monitoring and maintaining visibility across the software powering critical services.
