PHP2Shell: what we know about the critical PHP flaws and how to protect your servers.

On Wednesday, October 21, 2026, the PHP project released an emergency update to fix two critical vulnerabilities that, together, became known as PHP2Shell. The flaws allow an attacker, with no login and no password, to run code on the server and read parts of its memory that may contain passwords, access tokens and API keys.

The reach is huge. PHP is the language behind about 70% of websites whose server-side technology is known, according to W3Techs, including platforms such as WordPress, Drupal, Joomla and Magento. And unlike a flaw in a plugin or in a specific system, the problem lies in PHP itself: updating the CMS, the theme or the plugins does not fix it.

In this post, we bring together what is known so far, explain the flaws in plain language and list what technology teams and website owners should do.

What is PHP2Shell

PHP2Shell is the name given to a pair of vulnerabilities registered as CVE-2026-109618 and CVE-2026-109619. Both received a score of 9.2 out of 10 on the CVSS severity scale (version 4.0), which places them in the critical range. The name refers to the attacker's goal: getting a shell, that is, the ability to run commands on the server.

According to the PHP Foundation, both flaws sit in parts of PHP that nearly every request touches: memory management and error handling. That is what makes the problem so far-reaching.

CVE-2026-109618: running out of memory at the wrong moment

Every time someone opens a page built with PHP, the server sets up a series of internal structures to process that request. The first flaw happens when available memory runs out in the middle of that setup. PHP stops processing, but the cleanup step that follows treats the still incomplete data as if it were valid.

An attacker can trigger this memory shortage on purpose, for example with form and file submission requests (multipart) crafted to consume memory without exceeding the apparent configuration limits. This corrupts the process memory and can lead to code execution.

CVE-2026-109619: the "ghost state" between requests

PHP servers usually reuse the same process (worker) to handle several requests in a row. The second flaw happens when a request ends abruptly, because of a fatal error or a lack of memory, and leaves behind references to a memory area that has already been freed. The next request handled by the same process may use those references before PHP resets them.

This kind of bug, known as use-after-free, makes it possible both to read data that belonged to another request and to execute code. One of the confirmed paths goes through the session upload progress feature (session.upload_progress), which is enabled by default in PHP.

What is the practical impact

If successfully exploited, the vulnerability allows an attacker to:

• Run code on the server with the permissions of the user running the web server, without any authentication.
• Read the memory of the PHP process, which may contain database passwords, authentication tokens and API keys.
• From there, install hidden access, change the website, steal data or use the server as a launching point to attack other systems on the network.

Exploitation is not trivial: it depends on the version, the installed extensions, the server configuration and the application's behavior. But researchers have already demonstrated working attacks, and the techniques are likely to become more accessible over time.

Who is at risk

According to PHP's official announcement, every PHP installation that serves web requests is at risk, including:

• Apache with mod_php: the highest-risk scenario. There is a demonstrated exploit in which an unauthenticated request triggers the attack before any application code even runs.
• PHP-FPM: the most common model on servers running Nginx. Exploitation was validated under specific application conditions.
• php-cgi, FrankenPHP and LiteSpeed.

The vulnerable code has existed since PHP 5.4, released in 2012. In practice, this covers virtually every version in use today.

Security company Calif, one of those responsible for the discovery, says it confirmed unauthenticated remote code execution against specific versions of WordPress, Drupal, Joomla and Magento. This does not mean these platforms have a flaw of their own: they are affected because they run on vulnerable PHP.

Fixed versions

• PHP 8.5: update to 8.5.12.
• PHP 8.4: update to 8.4.27.
• PHP 8.3: update to 8.3.36.
• PHP 8.2: update to 8.2.35. This branch is only supported until December 31, 2026.
• PHP 7.4, 8.0 and 8.1: there is no new official release, only a minimal fix published in the source code.
• PHP 5.4 to 7.3: there is no fix. These versions are unsupported.

A few important notes:

• Linux distributions and extended support vendors received the fixes in advance. In distribution packages, the fix may arrive keeping the old version number. That is why you should check your vendor's security bulletin (Ubuntu, Debian, Red Hat and others), and not just the version number.
• For PHP 7.4, 8.0 and 8.1, the PHP team published minimal fixes in the source code, aimed at people who build PHP themselves. Even so, the recommendation is to move to a supported version.
• PHP 8.2 stops receiving security fixes on December 31, 2026. If you use this branch, start planning the migration now.

Timeline

• August 2026: researchers at Calif and Wiz, working independently and with the help of artificial intelligence models, find the flaws and report them to the PHP security team.
• October 17: Amazon records the first exploitation attempt on its decoy servers (honeypots), four days before disclosure.
• October 20: the flaw identifiers leak online, along with a demonstration video published by mistake. PHP posts an advance notice, and CERT-EU, the European Union's incident response center, issues an alert.
• October 21, early hours: Cloudflare enables web application firewall (WAF) rules against the known attack methods, including for customers on its free plan.
• October 21, 14:00 UTC: PHP releases the fixed versions, one day earlier than planned because of the leak.
• October 22: CTIR Gov, the Brazilian federal government's cyber incident prevention and response center, instructs public administration bodies to update PHP immediately.

Is it already being exploited?

Yes. Several security companies report attack attempts:

• Amazon says PHP2Shell is already being broadly exploited and recommends investigating exposed systems from October 17 onward.
• Hadrian reported large-scale exploitation hours before the fix, mostly through the session upload progress path.
• Cloudflare, Patchstack and watchTowr have also recorded attempts.

According to an estimate cited by Tenable, more than 1.3 million internet-facing servers may be vulnerable.

Code claiming to exploit the flaws is circulating online. The PHP Foundation said that, when the fixes were released, none of the samples it reviewed actually worked. But be careful: unverified exploit code may contain malware and must not be run in any company environment.

The role of artificial intelligence in the discovery

PHP2Shell also stands out because of how it was found. PHP credited the discovery to researchers from Calif, Wiz and OpenAI, among others, and both Calif and Wiz say they used artificial intelligence models to analyze PHP's code.

Wiz described the flaws as being "among the most severe vulnerabilities discovered in PHP, and arguably in software history". OpenAI, for its part, said PHP2Shell is among several significant vulnerabilities it has found and that it expects similar findings to increase sharply in the coming months.

This cuts both ways. AI helps defenders find old flaws that went unnoticed for years in code used by millions of systems. At the same time, the same technology speeds up the work of attackers: only a few hours passed between the leak of the first details and the first mass exploitation attempts.

The window between the disclosure of a flaw and the attacks keeps shrinking, and the ability to update systems quickly is no longer a differentiator but a necessity. The topic connects with another discussion we recently brought to the blog: who oversees artificial intelligence.

What to do now

1. Find out where PHP is running

List every server, website, internal system and service that uses PHP, including the forgotten ones: old campaign websites, staging environments exposed to the internet, admin panels and intranets.

On shared or managed hosting, updating PHP is usually the provider's responsibility. Contact them and ask for confirmation that the fix has been applied.

To check the version on a server:

php -v

The version shown in the terminal may differ from the one used by the web server. Also check the installed packages, which include PHP-FPM and the Apache module:

# Ubuntu and Debian
dpkg -l | grep php

# Red Hat, Rocky Linux, AlmaLinux and similar
rpm -qa | grep php

2. Update and restart

Update to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or to your distribution's fixed package. Then restart every PHP process (PHP-FPM, Apache or equivalent). Without a restart, the old processes keep running with the vulnerable code in memory.

If you use the community repository rpms.remirepo.net, PHP itself recommends switching to distribution packages or building from source, because the repository would not have the update available on release day.

3. If you cannot update right now, reduce exposure

PHP is blunt about it: there are no complete mitigations, and updating is the only safe choice. The measures below reduce known attack paths, but they do not make an installation safe. Use them only as a bridge until the update.

; Blocks the confirmed session upload progress path (CVE-2026-109619)
session.upload_progress.enabled = 0

; PHP 8.5 only: blocks the fatal error backtrace path (CVE-2026-109619)
fatal_error_backtraces = 0

; Reduces the maximum request size (CVE-2026-109618)
; 8M for applications without file uploads, 32M if uploads are needed
post_max_size = 8M

Other precautions recommended by PHP and incident response bodies:

• Apply the settings in php.ini, in the PHP-FPM pool or in the web server configuration. Do not use ini_set() or the .user.ini file, which take effect too late.
• For CVE-2026-109618, PHP suggests memory_limit=-1, applied in a way the application cannot override (for example, with php_admin_value). This increases the risk of resource exhaustion, so combine it with memory limits per container or cgroup.
• Limit, at the web server or proxy, the request size and the number of fields, headers and upload parts. Block multipart requests where the application does not receive files.
• On PHP-FPM, pm.max_requests = 1 makes each process handle a single request, which removes state reuse at a performance cost.
• Restart every process after any change.
• Put applications behind a WAF with PHP2Shell rules or restrict internet access until the fix, as recommended by CTIR Gov and CERT-EU.

4. Check for compromise

Since there were attack attempts even before the fix, updating is not enough if you were exposed. It is worth:

• Reviewing access logs from October 17 onward, looking for unusual volumes of multipart requests, out-of-memory errors and unexpected process restarts.
• Looking for new or modified PHP files in public directories, a typical sign of webshells (files that give the attacker remote control of the server).
• Rotating passwords, tokens and API keys that were accessible to PHP on exposed servers, since the flaw allows reading the process memory.

5. Plan your way off unsupported versions

Unsupported versions receive no fixes and will remain vulnerable to this flaw and to the next ones. If your application still runs on PHP 8.1 or earlier, PHP2Shell is the argument you needed to prioritize the migration. And PHP 8.2 will be in the same situation on December 31, 2026.

Lessons for those who build and maintain systems

Episodes like PHP2Shell, just like Log4Shell in 2021, reinforce a few principles that apply to any technology:

• Inventory is the foundation of security. You cannot protect what you do not know exists.
• Updating needs a process. A routine, clear owners and defined maintenance windows make the difference between fixing in hours or in weeks.
• Defense in depth. A WAF, network segmentation, least privilege for the web server user and secrets kept out of the code reduce the damage when a flaw appears.
• Unsupported versions are security debt. Every month the migration is postponed increases the risk.

To go further, also read our posts on web platform security best practices and secure hosting on AWS.

If your company needs help mapping PHP applications, planning the update or reviewing the security of its systems, get in touch.

---

Sources:

• PHP: Security advisory: critical remote code execution vulnerabilities, update now, October 21, 2026.
• PHP on GitHub: technical advisories GHSA-w8hw-w9fx-j79w and GHSA-6wmf-4rv5-p3rp.
• Tenable: php2shell (CVE-2026-109618, CVE-2026-109619): frequently asked questions.
• SecurityWeek: PHP2Shell patches land as first exploitation attempts hit sensors.
• Qualys: Two critical PHP flaws could hand attackers your web servers.
• Convergência Digital (in Portuguese): Governo manda fazer atualização urgente e até tirar do ar sites por conta das vulnerabilidades no PHP, October 22, 2026.