PHP2Shell: two critical flaws in the PHP engine

What happened

On October 21, 2026, the PHP security team issued emergency releases 8.2.35, 8.3.36, 8.4.27 and 8.5.12. They fix two vulnerabilities grouped under the name PHP2Shell: CVE-2026-109618 and CVE-2026-109619, both rated 9.2 out of 10 (CVSS 4.0). They allow code to be executed remotely on a server, with no account or password.

What makes PHP2Shell special is where it sits. The flaw is not in a plugin or an application, but in the PHP engine itself, in the way it manages a request's memory. And PHP runs nearly seven out of ten websites among those whose server-side language is known (W3Techs): WordPress, Drupal, Joomla, Laravel, Symfony, but also the cPanel and Plesk hosting panels and many network appliances.

Who found it, and how

The flaws were found in August 2026 by researchers from Wiz Research and the company Calif (including Ryan Austin, who was working under OpenAI's "Patch the Planet" program). The two teams disclosed them jointly. Their method: an AI-assisted audit of PHP's source code, followed by a demonstration of code execution against WordPress and Drupal. The report to the PHP team dates from August 24, and coordinated disclosure was set for October 22.

According to several sources, one of the errors had already been spotted during an audit in 2024, but was not fixed for lack of agreement on the solution and of any known exploit. In short, here is the mechanism:

• CVE-2026-109618: PHP runs out of memory in the middle of preparing a request and leaves half-built data behind. The cleanup code then treats it as valid.
• CVE-2026-109619: an internal state survives the end of a request even though the memory it points to has been freed. The next request, handled by the same process, can use it (use-after-free).

How it spread

The coordinated disclosure did not hold. Times are given in UTC, which is Conakry time.

• October 17: Amazon's honeypots record a first exploitation attempt, four days before the fix.
• October 20: the CVE identifiers circulate on social media and a demo video is published by mistake. It is taken down, but copies are already circulating. PHP brings the release forward to the next day.
• October 21: Cloudflare activates web application firewall rules even before the fix is out. PHP publishes the fixed versions around 2 pm. The US agency CISA calls for immediate patching and, failing that, for taking servers offline.
• October 22: Cloudflare reports millions of attempts, including unsuccessful tries at installing a variant of the Mirai botnet.
• October 23: PHP publishes an advisory on a related attack path, CVE-2026-115560 (session upload progress), with no fix as of that date.

As a precaution, several major organizations temporarily shut down services: the Wikimedia Foundation, the Internet Archive, government websites in France, the Netherlands, Finland and Canada. In Japan, the Prime Minister herself urged website publishers to check their servers.

An opportunistic ecosystem has also grown up around the flaw: fake "php2shell" websites, parody cryptocurrencies, so-called exploits sold for 150 dollars on Telegram, and hundreds of GitHub repositories, many of which contain non-working or even booby-trapped code. Never download an "exploit" to test your own server.

As of October 23, security vendors disagreed on the number of successful intrusions, and the two CVEs were not yet in CISA's catalog of known exploited vulnerabilities. But several teams, including CrowdStrike, have built working exploits: the question is no longer whether the attack works.

The risks

• Server takeover. The attacker runs commands with the privileges of the PHP process, drops a backdoor (webshell), installs a cryptocurrency miner or enlists the machine in a botnet.
• Theft of secrets. The researchers demonstrated reading the memory of PHP processes without authentication: passwords, session tokens, API keys, the contents of .env files.
• Data leaks. Everything the application can read becomes readable: customer files, orders, health or payment data.
• Lateral movement. From the web server, the attacker tries to reach the database, the internal network or the cloud accounts.

Why it is particularly dangerous

• No prerequisite on the victim's side. No authentication, no user click.
• An attack invisible to the application. It plays out beneath WordPress or Laravel, in the engine. According to CrowdStrike, a successful exploitation returns a normal HTTP 200 response and leaves clean application logs.
• Apache with mod_php on the front line. This is the most exposed configuration: a single anonymous POST request can be enough, before the application's code even runs. PHP-FPM, php-cgi, LiteSpeed and FrankenPHP are also affected, depending on the configuration and the application's behavior.
• An aging installed base. According to Qualys, 71% of the 156 million PHP installations observed among its customers run on end-of-life branches (5.4 to 8.1), which will not get an official fixed release.

An honest nuance: the CVSS score assumes high attack complexity, and exploitability varies with the configuration. That is no reason to wait.

Available fixes

• PHP 8.5: version 8.5.12
• PHP 8.4: version 8.4.27
• PHP 8.3: version 8.3.36
• PHP 8.2: version 8.2.35
• PHP 7.4, 8.0 and 8.1: no official release. PHP has published source patches, picked up by distributions and hosting providers (cPanel, CloudLinux, Ondřej Surý's repositories). Otherwise, migrate.
• PHP 7.3 and earlier, including PHP 5: no fix. Migration is the only way out.

Linux distributions (Debian, Ubuntu, Red Hat…) often ship the fix under the old version number. Rely on their security bulletin, not just on the number displayed.

How to apply them, step by step

• 1. Take inventory. List every server and container running PHP, including hosting panels and third-party software. Be careful: php -v on the command line may report a different version from the one serving your pages. Also check php-fpm8.3 -v (adjust the number) or your hosting provider's panel.
• 2. Update. On Debian or Ubuntu: sudo apt update && sudo apt install --only-upgrade 'php8.3*'. On Red Hat, Rocky or AlmaLinux: sudo dnf upgrade 'php*'. On cPanel: update the EasyApache ea-php* packages. With Docker: rebuild your images from a fixed base image (docker build --pull --no-cache), then redeploy. An image pinned to an old tag remains vulnerable.
• 3. Restart every PHP process. Without a restart, the old code stays in memory: sudo systemctl restart php8.3-fpm and, depending on your setup, sudo systemctl restart apache2 or httpd.
• 4. Check the version actually being served, for example with a temporary phpinfo() page, deleted right after the check.
• 5. Disable session upload progress, even after updating, until CVE-2026-115560 is fixed: session.upload_progress.enabled = 0 in php.ini or the FPM pool (not via ini_set() or .user.ini), then restart. Only progress bars that read the session are affected: test your upload forms.
• 6. Look for signs of compromise since October 17: PHP files created or modified (find /var/www -name "*.php" -newermt 2026-10-17), unknown cron jobs, new accounts, unusual outbound connections, "Allowed memory size" errors ending with "in Unknown on line 0", bursts of PHP process restarts.
• 7. If in doubt, rotate your secrets: database passwords, API keys, tokens in the .env file. For Laravel's APP_KEY (version 11 and later), use APP_PREVIOUS_KEYS so that data already encrypted does not become unreadable.

If you cannot update right away, these measures reduce exposure without eliminating it:

• restrict public access to the server, or take it offline, as recommended by CISA and the NSA;
• put the site behind a web application firewall: Cloudflare, Imperva and others have published rules;
• reduce post_max_size (8M without file uploads, 32M with) and limit request size at the proxy level;
• under PHP-FPM, consider pm.max_requests = 1 if performance allows.

PHP says it bluntly: no configuration change fully protects you. Only the update fixes it.

Our takeaways

The window is now counted in hours. These flaws were found by AI-assisted researchers. Attackers have the same tools, and the first attempt came four days before the fix.

An end-of-life version is not "stable", it has no safety net. Websites still on PHP 7 have received no official fixed release.

Security is a routine, not an event. An up-to-date inventory, automated updates, regularly rebuilt images and tested backups make the difference on the day the flaw drops.

You do not know which PHP version runs your website, or your application still runs on PHP 7? We audit your servers, apply the fixes, check for signs of compromise and plan the migration to a supported version. Tell us about your project.

Sources: PHP Security Team, CISA, Wiz, Qualys, watchTowr, Recorded Future, Imperva, Brandefense (advisories published October 20 to 24, 2026).