PHP2Shell: What You Should Do Now If You Can't Patch Immediately

Not every organization can apply a patch immediately. Legacy systems, dependencies on vendors, a lack of testing windows, or approval processes can delay updates. It is crucial not to leave your systems unprotected while waiting for the patch.

If you are unable to update your systems in the short term, Myra can activate protection for your domains against attacks that attempt to exploit the PHP security vulnerabilities. This protection is intended as a short-term, temporary solution and does not replace patching your systems. Please contact us if you need assistance – our experts are happy to advise you at any time.

Notice for Myra Security Customers

The Myra infrastructure has been patched against CVE-2026-109618 and CVE-2026-109619. The updates were deployed on all affected systems on October 21, 2026, immediately after the vulnerability details were published. You can continue to use all Myra services without restriction.

Important for your own systems: The vulnerabilities affect the PHP runtime. If you are running your own PHP applications behind Myra, you must independently update your servers to a patched version of PHP: 8.2.35, 8.3.36, 8.4.27, 8.5.12, or the corresponding security backports for your distribution. If you have any questions, please contact your account manager.

What happened, and what are the general recommendations?

On October 21, 2026, the PHP project released patches for two critical vulnerabilities, also known as “PHP2Shell.” The first, CVE-2026-109618, allows code execution via an out-of-memory error. The second, CVE-2026-109619, allows malicious code to be executed via an outdated global state that can continue to be used after the associated memory has been freed. Neither authentication nor user interaction is required to exploit these vulnerabilities.

The Federal Office for Information Security (BSI) has classified the situation as Criticality 3/Orange in an IT security advisory (BITS-H 2026-297981-1132). This means that measures must be taken immediately. At the time of the advisory (Version 1.1, October 21, 2026), no confirmed attacks were known, but the BSI “expects exploitation on vulnerable systems in the near future.”
 

Who is affected, and how can you check your systems?

According to the BSI, any PHP installation that processes web requests is at risk: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, and LiteSpeed. The PHP Security Team assesses the risk as highest for mod_php. In that case, an unauthenticated request can trigger the attack before any application code even runs.

Since the vulnerabilities lie within PHP itself, they also affect applications such as WordPress, TYPO3, Drupal, Joomla, Magento, or Nextcloud if they run on unpatched PHP. Updating the application alone is not enough.

Here’s how to check your current patch status:

• Check the version: Run `php -v` on each web server.

• Check distribution packages: Linux distributions provide patched backports, some with different version numbers. The advisories from Ubuntu, Debian, and Red Hat are authoritative.

• Containers: You must rebuild images that contain PHP.

• Products and appliances: Check whether manufacturers provide patched firmware versions. NCSC-NL compiles a list of affected products in a GitHub repository.

What You Should Do Now

Step 1: Apply Patches

These versions address the vulnerabilities:

• PHP 8.5.12

• PHP 8.4.27

• PHP 8.3.36

• PHP 8.2.35

For the end-of-life versions 7.4, 8.0, and 8.1, the PHP Security Team provides backport patches. Details can be found in the PHP Advisory as well as in the GitHub Advisories GHSA-w8hw-w9fx-j79w and GHSA-6wmf-4rv5-p3rp.
 

Step 2: If you cannot apply the patch immediately

Legacy systems, a lack of testing windows, or dependencies on vendors often delay updates. In this case, the BSI recommends temporarily disconnecting the affected systems from the Internet, since only applying the patch provides complete protection.

If that is not possible either, the PHP team provides workarounds to use until a patch is available. They only work in combination:

• Set `memory_limit=-1` so that applications cannot override the value

• Keep `post_max_size` low by setting size limits at the web server or proxy level

• Limit memory at the container or cgroup level

• Set `session.upload_progress.enabled=0`; in PHP 8.5, also set `fatal_error_backtraces=0`, and restart all workers

• Remove outdated settings and fix fatal errors that attackers can trigger

The exact configuration is described in the PHP Advisory.

Important: These measures reduce the attack surface but do not eliminate it entirely. In addition, the BSI recommends making access to web applications as restrictive as possible.
 

Step 3: After the Patch

• Migrate: All PHP versions prior to 8.2 have reached end-of-life. PHP 8.2 will only receive security updates until the end of the year. The BSI recommends switching to a supported version.

• Hardening: Configure SELinux or AppArmor to mitigate the impact of remote code execution vulnerabilities.

• Monitor: According to the BSI, there are no definitive indicators of compromise yet. Keep a close eye on exposed PHP web servers.

PHP2Shell Action Checklist

• Have all PHP installations been inventoried, including containers and appliances?

• Has the version been verified using `php -v` and compared with the distribution advisories?

• Has the patch been applied (8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 or backport)?

• Have container images been rebuilt?

• If patching isn’t possible immediately: Have you considered disconnecting from the Internet or implemented all workarounds and restricted access?

• Is migration from EoL versions planned?

• Have you checked SELinux/AppArmor and enhanced monitoring?