PHP2Shell. What is it and What Do You Need to Do?

Time to read:

Written by

Reviewed by

PHP2Shell. What is it and What Do You Need to Do? #

You don't need to be a PHP developer or a systems administrator managing PHP-based software, to know about the recent PHP2Shell exploit:

• Reports by CBS News ,the BBC ,Le Monde (French),the Australian Broadcasting Corporation , on major news sites and podcasts, such asHacker News ,Bleeping Computer ,Heise.de (German),The Times of India , andITWire
• The Japanese Prime Minister mentioned it
• The German Federal Ministry for Digital Transformation and Government Modernisation, and France’s Ministry of the Interior, among so many others around the world took websites down until they could be patched
• It is — still — all over social media, such asthe NSA posting : "Effective Immediately, all organizations using PHP for their systems are advised to be prepared for an update addressing two critical vulnerabilities "

Just in case you missed it, PHP2Shell is a combination of two RCE (Remote Code Execution) exploits: CVE-2026-109618, which is an RCE via OOM (Out-Of-Memory) corruption, and CVE-2026-109619, which is an RCE via stale global state.

Citing The PHP Foundation (emphasis mine): CVE-2026-109618: If a request reached PHP's memory limit at exactly the wrong moment, PHP could leave partially initialized internal data behind and later treat it as valid, corrupting memory. On Apache with mod_php, an unauthenticated request can trigger this before any application code runs, and full remote code execution was demonstrated with default settings. Remote code execution was also confirmed on PHP-FPM through application-level code paths.

CVE-2026-109619: A fatal error at the wrong point could leave internal state pointing to memory that belonged to a previous request. A later request handled by the same worker could then use that freed memory. A use-after-free and worker crash were confirmed, and the reporter demonstrated remote code execution against a real-world application running on Apache with mod_php.

Both exploits affect every version of PHP back to PHP 5.4!

How was it discovered? #

CVE-2026-109618 was initially uncovered back in 2024, when one of the issues uncovered during an external security audit of PHP was being fixed. However, the exploit was never fixed for several reasons:

1. The core team wasn't sure that it could be readily exploited
2. Other issues were considered more pressing
3. To fix the issue would likely cause backward-compatibility breaks, a significant amount of work for the resources available, and uncertainty around the impact of fixing it on the wider community

Then, in 2026 during OpenAI's Patch the Planet program, a more recent audit was conducted by two firms: Calif and Wiz. This audit resulted in discovering the earlier RCE, as well as the latter one, CVE-2026-109619. In addition, the firms showed how both exploits could be utilised, and their severity.

To talk specifics, both exploits are ranked a 9.2 out of a possible 10.0 on the CVSS (Common Vulnerability Scoring System) 4.0, marking them critical. What's more, neither exploit needed a login. Both exploits can allow unauthenticated attackers to run code with the privileges of the PHP worker’s user, e.g., www-data.

Unfortunately, before a coordinated effort to patch PHP could be completed, a proof-of-concept video was accidentally leaked. Keeping something of this severity a secret for too long is all but impossible.

Not long after, updates of PHP for the four most recent versions were released, along with backports to PHP 8.1, 8.0, and 7.4. Even though the latter three versions are no longer supported, they were patched due to the impact of the exploits.

Given all of the steps involved between merging a change into PHP and it being available as an update, these patches were made available pretty quickly.

## [Have the exploits been successfully exploited?](#toc-heading-455c96cd-a0d4-4594-9c90-04fbd8a287e1)

Yes! [Mallory confirmed that](https://mallory.ai/blog/php-rce-rapid-response) on October 26th:

Dream Research reported artifacts of a campaign that rooted 25 servers by chaining PHP2Shell with the Linux kernel privilege-escalation flaw Fragnesia (CVE-2026-46300).

This is in addition to Cloudflare, Imperva and Check Point reporting exploit attempts "in the hundreds of thousands to millions", as well as reports from AWS.

What do you need to do? #

In order to stay safe from these security vulnerabilities, you’ll need to review any applications that utilise PHP. Follow the steps below to stay secure, making sure you check if any of your applications are using PHP, which you might have forgotten or missed.

Step 1: Perform an inventory of all of your PHP-dependent code and installations

As PHP is so ubiquitous, don't look in just the obvious places, such as the software you're developing, or the software that you're administering that you know is based on PHP. Look everywhere.

Quoting Steve Gibson from episode 1102 of the Security Now podcast: I believe there will be systems which are forgotten, that are in the backroom, or as we often say on the podcast, in some dusty closet where they will not be updated. An attacker will be able to get in. It's also not the case, and we saw hints of this in some of the reporting that I shared, where the immediate proofs of concept are mature and robust and work regardless of PHP version.

There will likely be a large variety of places where you might find PHP in your organisation. For example:

Check out Mallory's PHP-based enterprise software guide. The guide is broken down by task, such as phone systems, container and images, NAS and storage, and hosting control panels, making it super easy to follow.

Whether you use a spreadsheet, an app, or pen and paper, make sure you take an inventory, and keep it regularly updated. If you don't know how to start, I've created a Google Sheet to help you do so.

Step 2: Upgrade PHP

PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 have been released, each of which contains the fix for the two exploits in question.Upgrade to the closest one as soon as you can.

Source and binary downloads are available, and updated packages can be found in your Linux distribution's preferred package manager, e.g., APT, Yum, etc. In addition, even though they're no longer supported, fixes are also available for PHP 7.4, 8.0, and 8.1. If you're using containers, rebuild them using the relevant patched tag from the official sources, such as Docker Hub.

Step 2a: Configure PHP if you cannot upgrade

It isn't always possible to upgrade, as projects may have dependencies that depend on earlier, unpatched versions of PHP. In these instances, there are still a number of settings you can tune to reduce the likelihood of being affected by one or both exploits.

Here is a summary of  [the guidance from PHP.net](https://www.php.net/archive/2026.php#2026-10-21-5):

 **For CVE-2026-109618:**

• Set memory_limit to-1 .php2shell.com recommends also usingLinux cgroup v2memory.max (or an equivalent mechanism) to contain resource consumption and limit the impact to PHP processes. If you're using a container, consider settingdeploy.resources.limits.memory to an applicable value, or check your host provider's documentation to see what resource limits they allow to be configured.
• Set a low post_max_size value:
• If one or more of your applications don't use file uploads, set it to 8M
• If file uploads are necessary, set it to 32M
• Consider enforcing limits at the web server or proxy level for decoded request size, input field count, multipart part count, header count, and nesting depth. These limits must also cover requests without a usable content-length header .

- Keep the  [upload_max_filesize](https://www.php.net/manual/en/ini.core.php#ini.upload-max-filesize) value below that of`post_max_size`

 **For CVE-2026-109619:**

• Set session.upload_progress.enabled to0 and restart all your workers
• On PHP 8.5, set fatal_error_backtraces to0 and restart the relevant workers
• Remove invalid or deprecated settings applied per request that emit diagnostics before initialization
• Fix attacker-reachable fatal errors and execution timeouts, including failures in callbacks, upload or import processing and cleanup
• Ensure that php.ini changes cannot be overridden by worker settings

Restart all instances and workers to ensure that they're running the new configuration.

## [What should you do going forward?](#toc-heading-aa4bee54-7148-429a-8f6c-1b528e1c1bc9)

Matthew Weier O'Phinney from Perforce [recommends the following PHP security best practices](https://www.zend.com/blog/tips-php-security):

1. **Always code with secure PHP in mind:**  Stay on top of[the OWASP Foundation](http://owasp.org/) 's (annual)[top ten web app security risks](https://owasp.org/www-project-top-ten/) .

2. Update all application components regularly:  As was covered earlier, make sure you regularly update to the latest version of PHP.
3. Understand and document your existing infrastructure:  To ensure no installation goes unpatched, and to reduce the work involved, do this on a regular basis.
4. Deploy hardened container images:  Wherever possible, use hardened containers to ensure your PHP applications are as secure as possible, and save you the effort of increasing their security position.
5. Ensure your PHP infrastructure is properly configured
6. Educate and train all employees in how to maintain secure PHP applications:  Proper software development goes beyond just writing code. It includes secure coding practices such as avoidingSQL injection attacks ,securing PHP , i.e., havingsecure sessions — and so much more. Make sure you include this as part of your standard developer training sessions.
7. Partner with third-party php security experts for additional support:  No matter how large, diverse, or well-resourced an organisation is, it can always benefit from specialist, outside support. Budget-permitting, ensure you're using the expertise of security professionals to review your PHP code and configuration.

And, I'll add one more, from Damien Seguy, Senior PHP developer at Exakat: Be ready to rebuild or update your installation at a moment's notice. However, are you in a position to do so? How simple and trusted are your deployment procedures? This is the perfect time to review them,find out, and put plans in place to improve them, as required.

Sponsor your favourite open source projects

PHP forms the basis of so many commercial services and projects, ones which contribute significantly (or solely) to company bottom lines. But, despite this importance, it remains critically underfunded.

According to The PHP Foundation's Impact and Transparency Report 2025 the total contributions received from sponsors and individual donors was $730,534 USD. Compared to the annual — even quarterly — revenues of companies in the S&P 500. According to FatFIRE, they generated roughly $18.3 trillion USD in trailing twelve-month revenue.

It would be great if those companies, and other companies and organisations who use PHP, would actually contribute to PHP (and other open source projects which they use). In the meantime, if you can, sponsor your favourite contributor, your favourite project, or The PHP Foundation. And, whenever possible, advocate that your organisation or company do so as well.

It's a bit of a cliché, but if everyone chipped in just a little, it would go an incredibly long way.

Despite a comparable lack of funding and resources, the PHP community has shown it is proactive in securing the web. That is demonstrated by how it responded to the PHP2Shell vulnerability in a calm, organized, and well-thought-out way. It was an excellent example of how to respond in these situations.

Don't get complacent #

Being all over the news helped ensure that if you had any responsibility for a PHP or PHP-adjacent site, you knew that you had to take action straight-away — lest your site was hacked!

However, like most things of this magnitude, there was initial attention — even hysteria — and then the news cycle moved on, as the graph below, from Censys attests.

However, this doesn't mean the problem has gone away. According to Censys, of the 46,272,123 PHP installations (those with known versions) that they identified as being affected on October 21, 29,311,837 are still affected at the time of writing.

Gladly, the services running newer, supported, versions of PHP have been patched. Unfortunately, services running PHP 8.1 and 7.4 are still affected.

If you haven't already, I strongly encourage you to perform a complete inventory of your systems and ensure they are patched. Then, perform an audit on a regular basis. By doing so and by following PHP security best practices, you should remain as prepared as possible for when the *next* exploit appears.

## [Further reading](#further-reading)

Matthew Setter is a PHP and Go Editor in the Twilio Voices team. He’s also the author of Mezzio Essentials and Deploy with Docker Compose. You can find him at msetter@twilio.com. He's also on LinkedIn and GitHub.

Related Posts #

Related Resources #

Twilio Docs

From APIs to SDKs to sample apps API reference documentation, SDKs, helper libraries, quickstarts, and tutorials for your language and platform.

Resource Center

The latest ebooks, industry reports, and webinars

Learn from customer engagement experts to improve your own communication.

Ahoy

Twilio's developer community hub

Best practices, code samples, and inspiration to build communications and digital engagement experiences.