PHP2Shell: What Happened and How to Know Your Site Is Safe
A pair of critical PHP vulnerabilities affected much of the web this week. Here’s how they were fixed, how to check your site, and how to stay protected going forward.
This week’s disclosure of PHP2Shell, a pair of security vulnerabilities that impacted up to two-thirds of the internet and resulted in the temporary shutdown of many high-profile websites, was, for many people, the first real look at how AI is changing digital security. The vulnerabilities are now patched, and if you’re a Palantir.net client, your sites are protected. Below, we explain what happened, how to confirm your site is safe, and how to stay protected going forward.
Those of us who design, develop, and support digital applications have anticipated a disclosure like this for some time. Over the last year or so, AI coding tools have grown increasingly capable of finding and exploiting previously undetected software vulnerabilities.
The good news is that the same tools are also helping the people who build and maintain software find and fix vulnerabilities faster. Many open source software projects have dedicated security teams that work in collaboration with other projects and organizations like Alpha-Omega, who have access to security-focused AI models that are not available to the general public.
What is PHP2Shell, and who was impacted by it?
PHP2Shell is the collective name given to a pair of critical vulnerabilities discovered in PHP, a popular scripting language that many websites and web applications are written in, including content management platforms like Drupal, WordPress, and Joomla, as well as the software that powers Wikipedia. It is estimated that between half and two-thirds of sites on the internet run on PHP.
The vulnerabilities affect all versions of PHP released in the last 20 years. They allow attackers to run executable code on a target’s server and access passwords and other sensitive data stored in process memory. These flaws had been present in PHP for many years, but there were no known ways to exploit them until an independent audit of the codebase using AI tools was conducted in August.
How were the PHP2Shell vulnerabilities fixed?
Because the vulnerabilities exist in the PHP code itself, the only way to fix them was with a software patch written by the PHP security team, a very time-consuming process given the complexity and sophistication of the issue. Following established best practices, this work was conducted privately, because once the vulnerabilities were disclosed publicly, they could be exploited by malicious actors.
On October 20, the PHP security team issued an advisory that a critical security patch would be released the following day, giving software vendors and the general public time to prepare. The patch was then released on the 21st at 9am Central US Time (14:00 UTC).
At that point, web hosting and application vendors began integrating the patch into their software, testing it to make sure that it didn’t break pre-existing configurations or take their clients’ sites offline. Many hosting and developer platform companies, including the ones who host our clients’ sites, implemented short-term mitigations designed to temporarily protect their sites while the patch was still being rolled out; others simply took their sites offline until the patch was deployed.
How do I know if my site is safe from PHP2Shell?
You can tell if your website or application is protected by confirming it is running one of the latest supported versions of PHP. If you’re running a content management platform built in PHP, like Drupal or WordPress, you can look up the PHP version number in your site’s administrative interface:
- Drupal: by going to “Status Report” in the “Reports” menu.
- WordPress: by going to “Site Health” in the “Tools” menu, then clicking on “Info” and opening the “Server” section.
Your site should be running one of the following versions of PHP:
- 8.5.12 (or better)
- 8.4.27 (or better)
- 8.3.36 (or better)
- 8.2.35 (or better)
Keep in mind that updating Drupal or WordPress does not update the version of PHP running underneath it. PHP updates come from your server or hosting provider, and the server typically needs to be restarted before the patched version takes effect.
If you are running PHP version 8.1 or earlier, it is still possible that your site is protected, but you will need to confirm this with your hosting provider. The PHP team did not release official updates for these older versions; it published only minimal source code fixes that hosting providers must apply themselves.
Is it possible that my site was hacked before the patch was applied?
While some information about the PHP2Shell vulnerabilities was leaked in advance of the patch’s release and both Amazon and Cloudflare have reported early attempts to exploit them, there are currently no confirmed reports of any successful attacks before the patch was released.
Sites that use Cloudflare’s web application firewall (WAF) received protection more than 10 hours before the patch’s release, and as mentioned above, many hosting providers, including those who host our clients’ websites (Acquia, Pantheon, and Upsun), also applied temporary mitigations. The Drupal Association has posted information on how administrators can audit their sites to see if they were probed in the days leading up to the patch’s release.
How can I protect my site from future security vulnerabilities?
The best way to be sure that your site remains secure is to keep it up to date with the latest security releases. This includes not only server-level languages like PHP, but the applications that run on top of them like Drupal and WordPress.
We utilize automated security scanning to ensure that critical issues that impact your site’s content management platform are identified and addressed as quickly as possible. Our proactive approach anticipates potential issues instead of reacting to them, so you’re prepared when a new vulnerability is announced.
As an example, just one week before the release of PHP2Shell, a patch was released to address a critical vulnerability in Drupal’s core software. We made sure that all of our clients’ sites were up to date in advance of the patch’s release, applied mitigations within an hour of its release, and had all sites patched within three hours.
We also partner with hosting platforms like Acquia and Pantheon who are part of the Drupal Steward Program, which provides mitigation for critical Drupal security vulnerabilities in advance of their official release. In addition, these partners have long and well-established records of keeping their platforms secured from threats that occur outside the application layer.
Staying secure as AI changes the landscape
AI is speeding up security work on both sides. The same tools that uncover vulnerabilities are also helping maintainers, hosting partners, and teams like ours find and fix them faster. Staying secure in this environment comes down to steady habits: keeping every layer of your site current, working with hosting partners who mitigate threats early, and having people watching on your behalf.
If you’re a Palantir.net client, there’s nothing you need to do. Your sites are running patched versions of PHP, and our team continues to monitor for new issues. If you’re not a client and want help confirming your site is protected, or want to build a support plan that keeps you ready for the next disclosure, get in touch with us.
Cover illustration created using Google Gemini.
