On 21 October 2026, the PHP project released security updates for two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, also known as PHP2Shell. Both can allow remote code execution, and both are rated critical with a CVSS score of 9.2. Because Plesk ships PHP for hosted websites and uses its own PHP engine to run the Plesk interface, Plesk Obsidian servers are affected until they are updated.
Plesk has released fixed PHP builds and Plesk Obsidian updates. This post explains what is affected, what to update, and how to confirm your server is protected. For the full list of versions, see the Plesk security advisory.
What the vulnerabilities are
- CVE-2026-109618 is remote code execution through memory corruption during out-of-memory handling. PHP can be interrupted while internal request data is only partly initialized, and request cleanup may then treat that invalid data as valid.
- CVE-2026-109619 is remote code execution through stale global state. Request-owned internal state can survive after its memory is freed, and a later request handled by the same worker may use that stale state before normal initialization resets it.
The PHP project advises that all PHP installations serving web requests are at risk, and rates mod_php as the highest-risk setup. Details are in the PHP security announcement.
Which Plesk components are affected
Two things need patching on every Plesk server: the PHP versions used by your customers’ websites, and the PHP engine used by Plesk itself.
PHP versions shipped with Plesk for Linux
| PHP Version | Affected | Fixed |
| PHP 8.5 | 8.5.11 and below | 8.5.12 |
| PHP 8.4 | 8.4.26 and below | 8.4.27 |
| PHP 8.3 | 8.3.35 and below | 8.3.36 |
| PHP 8.2 | 8.2.34 and below | 8.2.35 |
| PHP 8.1 (EOL) | 8.1.34 built before 21st Oct 2026 | 8.1.34 built on 21st Oct 2026 |
| PHP 8.0 (EOL) | 8.0.30 built before 21st Oct 2026 | 8.0.30 built on 21st Oct 2026 |
| PHP 7.4 (EOL) | 7.4.33 built before 21st Oct 2026 | 7.4.33 built on 21st Oct 2026 |
PHP versions shipped with Plesk for Windows
| PHP Version | Affected | Fixed |
| PHP 8.5 | 8.5.11 and below | 8.5.12 |
| PHP 8.4 | 8.4.26 and below | 8.4.27 |
| PHP 8.3 | 8.3.35 and below | 8.3.36 |
| PHP 8.2 | 8.2.34 and below | 8.2.35 |
The PHP engine used by Plesk itself (sw-engine on Linux, plesk-engine on Windows)
| Release Line | Affected | Fixed |
| Plesk Obsidian 18.0.80 | 18.0.80 Update 10 & below | 18.0.80 Update 11 |
| Plesk Obsidian 18.0.81 | 18.0.81 through Update 3 | 18.0.81 Update 4 |
Note that the end-of-life PHP 7.4, 8.0 and 8.1 builds keep the same version number. The fix is identified by the build date, not the version string.
What to do now
- Update Plesk. Install the latest available updates, which include the fixed PHP packages and the Plesk Obsidian 18.0.81 Update 4 or 18.0.80 Update 11 engine fix. See how to update Plesk.
- Confirm your Plesk version. Not sure which release you run? Follow how to find the Plesk version installed on a server.
- Verify PHP versions. In Plesk, go to Tools & Settings > PHP Settings. The version appears in each handler name.
- Check the build date on Linux. Connect over SSH and run the command below, adjusting the version. A fixed 8.3 build reports 8.3.36 and a build date of 21 October 2026 or later.
/opt/plesk/php/8.3/bin/php -v - Check older PHP builds by date. For PHP 7.4, 8.0 and 8.1, confirm the build date is 21 October 2026 or later.
If an update on Ubuntu or Debian fails with a NO_PUBKEY 5B6AB2160B50DB96 error, see Unable to update Plesk: the public key is not available.
Release details are in the PHP updates change log and the release notes for Plesk Obsidian 18.0.81 Update 4 and 18.0.80 Update 11.
If you cannot update immediately
Only an update fully resolves these vulnerabilities. The PHP project lists the measures below as ways to reduce exposure to specific attack paths. They do not make an installation safe, so treat them as a short-term step and verify them in your own environment.
For CVE-2026-109618
- Set a memory limit of -1 in a way applications cannot override, and confirm no pool, directory or application setting puts a finite limit back.
- Set a low post_max_size, for example 8M, or 32M where uploads are required, and keep upload_max_filesize below it.
- Enforce request size, field count and multipart limits at the web server or proxy.
For CVE-2026-109619
- Set session.upload_progress.enabled=0 in php.ini or the server configuration, then restart every PHP worker. Do not rely on ini_set() or .user.ini.
- On PHP 8.5, set fatal_error_backtraces=0 and restart every worker.
- Fix attacker-reachable fatal errors and execution timeouts in your applications.
The PHP announcement and the linked advisories have the full technical detail.
Running older PHP versions
PHP 8.1 and older no longer receive updates from the PHP project, but Plesk has published fixed builds of PHP 7.4, 8.0 and 8.1 for Plesk for Linux. The best long-term step is to move sites to a supported PHP version. For PHP 5.6, 7.2 and 7.3, Plesk recommends paid extended support.
See TuxCare Extended Lifecycle Support for PHP in the Plesk extensions catalog.
Next steps
Read the Plesk security advisory and update to the applicable fixed Plesk and PHP build today. We will keep the advisory current as further releases become available, so check it for the latest coverage.
