PHP2Shell: Critical vulnerabilities in the PHP core. Patch now.

Update box: As at 23 October 2026. New since the first version: active exploitation, BSI warning, fixed version numbers, detection guidance. We update this post on an ongoing basis.

Key points at a glance

• Two vulnerabilities in the PHP core: CVE-2026-109618 and CVE-2026-109619, both with a CVSS score of 9.2.

• Consequences: code execution without login and disclosure of memory contents such as passwords, tokens and API keys.

• The vulnerabilities are being actively exploited. The first known attack attempt dates from 17 October.

• Fixed in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. There is no official update for PHP 8.1 and earlier versions.

• The BSI advises: patch immediately; if necessary, take the web server offline.

What happened?

Wiz Research has discovered several memory errors in the PHP core. If PHP aborts a request due to a memory error, a corrupted internal state remains, which a subsequent request can exploit. Wiz has thus demonstrated code execution without login on current installations of WordPress, Drupal and Joomla. The application itself is irrelevant: the request is processed before your application even starts running.

The timeline shows just how critical the situation has become:

Who is affected?

Any organisation running PHP on systems accessible from the internet, in whatever form: PHP-FPM, Apache with mod_php, php-cgi, LiteSpeed or FrankenPHP. Typical examples include:

• Websites and online shops running on WordPress, Drupal, Joomla, TYPO3 or other PHP-based systems

• Customer portals, intranets and internal tools based on PHP

• Hosted websites where the host provides PHP

Which versions are secure?

Important: Some Linux distributions provide the fix under their own version numbers. Therefore, please check the instructions provided by your distributor.

What you should do now

1. Update PHP and then restart PHP-FPM or the web server. Otherwise, the old interpreter will continue to run.

2. Check the correct version. `php -v` displays the version on the command line. The version used by your website may be different.

3. Ask your hosting provider. For hosted websites, actively follow up to ensure the update has been applied and PHP has been restarted.

4. Buy time where necessary. WAF rules, such as those from Cloudflare, Akamai or AWS, reduce the risk but do not replace the update. Even the configuration change currently circulating – `session.upload_progress.enabled=0` – does not provide complete protection.

5. Rotate your secrets. For systems that were accessible from the internet prior to the patch: renew passwords, tokens and API keys.

If you’re running PHP 8.1 or older

That’s the real catch. Many legacy applications still run on 7.4, 8.0 or 8.1, and upgrading to 8.2 often breaks code, dependencies and drivers. This isn’t a project for this afternoon. Nevertheless:

• Check for a backport: Does your Linux distributor provide a dedicated fix for your version?

• Reduce exposure: If not, take the application offline or severely restrict access, for example, only via a VPN or a reverse proxy with strict limits. This is precisely what the BSI advises.

• Plan the upgrade now: Any further vulnerabilities in PHP will affect these systems again without a fix.

How to recognise an attack

Insights from our detection practice:

• Start searching from 17 October, not from the patch date. An attack may have taken place before the patch was released.

• Processes rather than signatures: Payloads are small and vary; with mod_php, everything runs before the application starts. Web server processes (Apache, php-fpm, lsphp) that launch a shell or tools such as curl and wget are more reliable.

• Memory errors: Memory limit errors on endpoints that would otherwise never reach the limit, and frequent HTTP 500 responses.

• Session cookies: Unusually large or incorrect PHPSESSID values in responses. One of the vulnerabilities exposes memory contents via this, leaving no traces on the server. Therefore: rotate secrets even if the scan comes back clean.

• Check telemetry: In many environments, process data from web servers and PHP error logs do not end up in the SIEM at all. This makes it almost impossible to prove an attack retrospectively.

Analysis

The faulty code has been present in PHP for over ten years. Exploiting it was, for a long time, too labour-intensive. Wiz discovered the vulnerability using AI models and built working exploits in a short space of time. Attackers can now do the same. Our conclusion: “There is no public exploit yet” is becoming an increasingly poor excuse for postponing an update.

Where exactly is PHP running in your environment?

This is often the most difficult question, particularly in cloud environments with numerous containers and VMs. Together with Wiz, the team that discovered PHP2Shell, we’re offering you a free quick check. Wiz scans your cloud environment (AWS, Azure, GCP) without requiring any installation and, within a few minutes, identifies all affected PHP workloads and which of these are accessible from the internet. Read-only access is sufficient for this. We’ll support you directly with the security remediation.

Interested or have any questions? Get in touch.

Sources

• Wiz Research: PHP2Shell

• Amazon Threat Intelligence: Exploitation prior to public disclosure

• watchTowr: PHP2Shell FAQ

• Datadog Security Labs: Detection and remediation

• PHP: Security release dated 21 October 2026

• BSI Cybersecurity Alert BITS-H No. 2026-297981-1032