Critical php2shell vulnerabilities: What you need to know

On October 21, 2026, the PHP project published fixes for two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, both rated CVSS 9.2 and collectively known as php2shell. Since then, we have received questions about what to do.

The flaws are in the PHP engine. A WordPress, Drupal, Magento or Laravel site is exposed even if every plugin and theme is current, because updating the application does nothing to the engine underneath. An attacker with no account can execute code on the server or read data from its memory.

Fixes appeared at 14:00 UTC on October 21; details reportedly leaked the day before. The Acronis Threat Research Unit (TRU) reports that several vendors observed exploit attempts beginning October 17, with activity increasing after the leak. As of October 22, no successful compromise has been publicly confirmed, and CISA has not added the CVEs to its Known Exploited Vulnerabilities catalog. That status may change. Two earlier PHP vulnerabilities, CVE-2024-4577 and CVE-2019-11043, were later associated with ransomware campaigns.

Acronis Cyber Protect does not use PHP, so there is nothing for customers or partners to patch.

A small number of Acronis web properties do run on PHP. We took those offline the moment the fixes were published, before patching, which is the safe order when exploit attempts are already in the wild. Our engineers ported both applications to PHP 8.5 and brought them back the same day. The community forum was updated by its external vendor and is back online as well.

If you host PHP — on client websites, cPanel or Plesk servers, ticketing or billing portals, appliances that bundle PHP, or Windows servers running PHP under IIS, XAMPP or WAMP — take action. TRU recommends the following order:

1. Inventory every copy of PHP, including containers and third-party software that bundles it. Most people are surprised by what they find.
2. Update to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or to your distribution’s fixed package. Distributions often keep the old version number after backporting a fix, so check the package changelog for the CVE IDs rather than trusting php -v.
3. Fully restart every PHP process afterwards: Apache, PHP-FPM, IIS application pools. Rebuild container images. A running process keeps the old code until it is restarted, and updating the website or its plugins changes nothing.
4. PHP 8.1 and older have no official upstream releases. Use a vendor-provided fix where available or upgrade. For PHP 7.3 and older, restrict internet access until you can upgrade.
5. If you cannot update today, consider a web application firewall with php2shell-specific rules and the proposed interim PHP settings (session.upload_progress.enabled=0, memory_limit=-1 at the server level with a container memory limit, a low post_max_size and fatal_error_backtraces=0 on 8.5), followed by a restart. These measures may reduce exposure but do not replace patching.

Do not download “proof-of-concept” exploits to test your own servers. Some are fake, and some carry malware.

Exploit attempts started around October 17, four days before the fix, so a server that was patched on October 21 may already have a visitor. Look at internet-facing PHP servers for activity from October 17 onward:

• Web server processes (apache2, httpd, php-fpm, php-cgi, or w3wp.exe and php-cgi.exe on Windows) launching shells or tools such as curl, wget, cmd.exe or powershell.exe.
• New or changed .php files in web directories.
• New cron jobs, scheduled tasks or user accounts.
• PHP error logs showing memory exhausted “in Unknown on line 0”, or bursts of segmentation faults.
• Web logs with multipart POST requests containing PHP_SESSION_UPLOAD_PROGRESS, or user agents starting with php2shell-.

One variant of the attack leaks server memory and leaves almost nothing in the logs. If a server ran unpatched Apache mod_php on the internet, rotate the credentials it held in memory: database passwords, API keys — anything in configuration files.

Acronis MDR detection rules have been updated for this attack and related PHP vulnerabilities, and TRU is running a threat hunt across MDR customers and will raise findings as top priority.

Consider Acronis MDR to help your team investigate and respond to this and future security incidents.