Articles in this section

Vulnerability CVE-2026-109618 and CVE-2026-109619 (PHP2Shell): Remote code execution in PHP shipped with Plesk

kb: security kb: ai-created

Situation

Two security vulnerabilities were discovered in PHP. As a result, all PHP versions shipped with Plesk are also affected. These security vulnerabilities have been identified as CVE-2026-109618 and CVE-2026-109619 and are also known as PHP2Shell.

Affected product version

  • PHP on Plesk Obsidian for Linux:
Product Affected versions Patched versions
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 21 Oct 2026) 8.1.34 (built on 21 Oct 2026)
PHP 8.0 (EOL) 8.0.30 (built before 21 Oct 2026) 8.0.30 (built on 21 Oct 2026)
PHP 7.4 (EOL) 7.4.33 (built before 21 Oct 2026) 7.4.33 (built on 21 Oct 2026)
  • PHP on Plesk Obsidian for Windows:
Product Affected versions Patched versions
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
  • Plesk Obsidian (sw-engine component):
Product Affected versions Patched versions
Plesk for Linux (sw-engine, part of Plesk UI)
  • Plesk Obsidian 18.0.80 Update 10 and below 
  • Plesk Obsidian 18.0.81 through 18.0.81 Update 3
  • Plesk Obsidian 18.0.80 Update 11
  • Plesk Obsidian 18.0.81 Update 4
Plesk for Windows (plesk-engine, part of Plesk UI)
  • Plesk Obsidian 18.0.80 Update 10 and below 
  • Plesk Obsidian 18.0.81 through 18.0.81 Update 3
  • Plesk Obsidian 18.0.80 Update 11 
  • Plesk Obsidian 18.0.81 Update 4

Note: for older versions of PHP (5.6, 7.2, 7.3) it is recommended to use paid TuxCare Extended Lifecycle Support for PHP.

Impact

Both vulnerabilities are rated critical (CVSS scores of 9.2). Remote code execution (RCE) is possible on affected PHP versions.

Call to action

Update Plesk to the latest available version.

A fix is available for most affected versions. The PHP vendor released the fixed PHP versions on 21 October 2026 at 14:00 UTC (PHP News Archive | 21 Oct 2026). 

Fixes for Plesk for Linux are already available for PHP 8.2 (as 8.2.35), 8.3 (as 8.3.36), 8.4 (as 8.4.27) and 8.5 (as 8.5.12). 
Fixes for EOL PHP versions on Plesk for Linux 7.4.33, 8.0.30, 8.1.34 have the same version number, but different build date. Versions built on 21 October 2026 have fixes included.

Fixes for Plesk for Windows are available for PHP 8.2 (as 8.2.35), 8.3 (as 8.3.36), 8.4 (as 8.4.27) and 8.5 (as 8.5.12)

Fixes for sw-engine/plesk-engine (PHP engine used by Plesk itself) are already available in Plesk Obsidian 18.0.81 Update 4 and 18.0.80 Update 11 for both Plesk for Linux and Plesk for Windows. Check the Plesk version installed on the server. 

Additional Information:

If the update fails with The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 5B6AB2160B50DB96 error (on Ubuntu/Debian), check the Unable to update Plesk: The following signatures couldn't be verified because the public key is not available article.

How to check PHP version on Plesk server:

In Plesk UI:
  1. Log into Plesk.
  2. Navigate to Tools & Settings > PHP Settings menu. Versions should be reflected in handler names:

Plesk-php-handlers.png

In CLI (Linux):
  1. Connect to the server via SSH
  2. Execute the command below for corresponding PHP version (8.3 is used in this example):

    # /opt/plesk/php/8.3/bin/php -v
    PHP 8.3.36 (cli) (built: Oct 21 2026 08:04:57) (NTS)
    Copyright (c) The PHP Group
    Zend Engine v4.3.36, Copyright (c) Zend Technologies
    with Zend OPcache v8.3.36, Copyright (c), by Zend Technologies

Was this article helpful?

Comments

71 comments
Date Votes
  • https://www.php.net/

    Security advisory: Critical remote code execution vulnerabilities, update now​

    PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 fix two critical vulnerabilities that can allow unauthenticated remote code execution. All PHP users are strongly encouraged to update immediately.

    Who is at risk: all PHP installations serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. We consider the risk highest for mod_php, with a demonstrated exploit where an unauthenticated request can trigger the attack before any application code runs.

    The vulnerabilities:

     

    • RCE via OOM corruption, CVE-2026-109618 (GHSA-w8hw-w9fx-j79w): out-of-memory handling can interrupt PHP while internal request data is only partially initialized. Request cleanup may then treat the invalid data as valid.
    • RCE via stale global state, CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp): request-owned internal state can survive after its backing memory has been freed. A later request handled by the same worker may use that stale state before normal initialization resets it.

    How to update:

     

    • Update to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35. Source downloads are on our downloads page. Windows source and binaries are on the same page.
    • Linux distributions and LTS vendors received the patches in advance, so check your vendor for updated packages.
    • PHP 8.1 and older no longer receive updates from the PHP project. Some distributions and LTS vendors provide backported fixes, so contact your vendor for details, or upgrade to a supported version.
    • If you rely on the volunteer-maintained rpms.remirepo.net, we urge you to switch to distribution packages or build from source, so you can immediately apply updates. The repo will not have updates today.
    • Given the severity of these vulnerabilities, the PHP security team provided minimal source-backports for PHP 7.4, PHP 8.0, and PHP 8.1 to help people building from source or without access to an LTS vendor.

    If you cannot update immediately: while only an update is a complete solution, the following measures reduce exposure to specific attack paths but do not make an installation safe.

    RCE via OOM corruption (CVE-2026-109618):

     

    • Set memory_limit=-1, preferably in a way applications can't override, such as php_admin_value in the FPM pool or Apache configuration, and check that no pool, directory or application setting puts a finite limit back. This removes the controllable PHP memory limit failure, but an underlying allocation failure can still reach the vulnerable path.
    • Set a low post_max_size. For applications that don't require file uploads, set post_max_size = 8M. If file uploads are necessary, set post_max_size = 32M. Keep upload_max_filesize below post_max_size. Consider enforcing limits at the web server or proxy level for decoded request size, input field count, multipart part count, header count, and nesting depth. These limits must also cover requests without a usable Content-Length.
    • Use a container or cgroup limit as an availability boundary, preferably with a policy that kills only the affected worker. Do not substitute RLIMIT_AS or RLIMIT_DATA, as these can cause the vulnerable allocation failure.

    RCE via stale global state (CVE-2026-109619):

     

    • Set session.upload_progress.enabled=0 and restart every worker. Use php.ini, an FPM pool or server configuration that applies before request parsing. Do not rely on ini_set() or FPM .user.ini. This blocks the confirmed session paths but not other variants.
    • On PHP 8.5, set fatal_error_backtraces=0 and restart every worker. This blocks the confirmed fatal backtrace path only.
    • Remove invalid or deprecated settings applied per request that emit diagnostics before initialization. Hiding diagnostics with error_reporting, display_errors or @ does not help.
    • Fix attacker-reachable fatal errors and execution timeouts, including failures in callbacks, upload or import processing and cleanup.

    The advisories linked above have the full technical details.

    2
  • I updated PHP 8.5 on my server, running Debian 12.15, per the instructions at php.net. php --version now reports 8.5.12. What to I need to do on the Plesk end to be protected?

    1
  • Vladimir Levchuk 
    Does not work as expected I think … (apt on Ubuntu 24.04.5)
    Err:8 http://autoinstall.plesk.com/PHP83_17 noble InRelease
     The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 5B6AB2160B50DB96
    Err:9 http://autoinstall.plesk.com/PHP84_17 noble InRelease
     The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 5B6AB2160B50DB96
    Err:10 http://autoinstall.plesk.com/PHP85_17 noble InRelease
     The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 5B6AB2160B50DB96

    … maybe add instructions as follows to get APT working on Ubunto/Debian:
    plesk installer update
    apt clean all
    apt update
    apt upgrade
     

    0
  • yum update is not showing any new php packages yet.  (This is on an alma9 and rocky 8 server)

     

    Update: 

    yum clean metadata
    yum makecache
    yum check-update 'plesk-php*'

    However, now I am getting public key for <package> not installed

    1
  • When will the update be visible in Plesk?

    2
  • Great to see you will also support older PHP versions. I know it is early to say, but is there any timeframe in mind?

    1
  • how can you support php7.4 → 8.1 if php itself is not supporting it?

    0
  • where to find the security patch for Plesk Obsidian 18.0.81 Update #3 (Ubuntu 20.04.6 LTS) ? nothing is available via apt update/upgrade :-(

    [UPDATE: update has been release thru apt and successfully applied. Thanks]

    1
  • Older PHP versions (7.4, 8.0, 8.1) don't have fixes yet?!
    Why not? We need to pay even more for our Plesk licenses?

    -4
  • In case someone else is getting an error like “public key for <package> not installed”:

    Running “plesk installer install-all-updates” fixed this for me and applied the PHP patches correctly.

    0
  • Older PHP versions will come, but needs time a bit, I am sure Plesk team is working hard on it.

    2
  • yum update reports this. How to resolve?:

    …

    Public key for plesk-php85-xdebug-3.5.3-0redhat.8.261021.1135.x86_64.rpm is not installed
    Public key for plesk-php85-xml-8.5.12-0redhat.8.261021.1135.x86_64.rpm is not installed
    The downloaded packages were saved in cache until the next successful transaction.
    You can remove cached packages by executing 'yum clean packages'.
    Error: GPG check FAILED

    0
  • However, now I am getting public key for <package> not installed

    If the PHP updates do not install via yum, they will via Plesk update (GUI or CLI) as that will install the necessary keys.

    1
  • Can you tell in which order you plan to release the missing fixes? Would be interesting also when new sw-engine can be expected? Thanks.

    0
  • Michel vd Lingen : "Older PHP versions (7.4, 8.0, 8.1) don't have fixes yet?!
    Why not?" --→ please read the main post above you are commenting on before complaining. 
    a.) because they are EOL, the current versions are patched first (every other way to handle this would cause delays)
    b.) but even the EOL versions will receive updates, see above
    c.) If you chose to use outdated software, you can also choose to book additional maintenance services. Your freedom, your choice, your responsibility

    @plesk team: Thanks to everyone at Plesk team for doing such a great job, keeping us posted and fixing SEVERAL PHP versions even for EOL Ubuntu releases that fast :-) You rock!

    4
  • Assuming everyone is hogging the Plesk network but are you guys facing Gateway issues and having to log in as root (compared to it was auto logging you in before)?
    Tx
     

    0
  • Will the update be avaliable in GUI, if not please post procedure to update !

    0
  • SSH run:

    plesk installer update

    will also fix the apt key issues in previous messages

    3
  • At DirectAdmin they provide excellent support! They will even provide fixes for older PHP-version e.g. PHP 5.6, PHP 7.0, PHP 7.1, PHP 7.2 and PHP 7.2!

    Quote by DirectAdmin employee fln:
    PHP versions 7.3 - 5.6 does not yet have a patch, we wanted to release what we have as soon as possible. Once we have patches for older PHP we will release them.

    Why can't Plesk do this for their customers? Weird. We are paying enough as it is!

    -5
  • warning: /var/cache/yum/x86_64/7/PLESK_17_PHP82/packages/plesk-php82-opcache-8.2.35-1centos.7.261021.0737.x86_64.rpm: Header V4 RSA/SHA256 Signature, key ID 0b50db96: NOKEY


    Public key for plesk-php82-opcache-8.2.35-1centos.7.261021.0737.x86_64.rpm is not installed
     

    Didn't work via updates GUI either.

    0
  • Is there an ETA available for 7.4, etc.?

    0
  • via SSH, the PHP update deployed fine an hour ago already. 
    Be aware Plesk GUI also uses php and needs to be patched separately (as mentioned in the original post), 18.0.81#4 was not visible for me so far.

    Until it's patched, IMHO it's better to turn the Plesk Panel (GUI) off - took me about 15 to 30 minutes to figure that out, so I'll hope this will save you others some time:
    1.) Make sure you have external SSH access that's working (e. g. via PuTTY)
    2.) SSH
    ---
    systemctl stop sw-cp-server
    systemctl is-active sw-cp-server
    ----
    should show “inactive”
    3.) periodically check for 18.0.81.4:
    ---
    plesk installer --select-release-current --upgrade-installed-components
    plesk version | head -1
    /usr/local/psa/admin/bin/php -v | head -1
    ---
    4.) Once that returned version 4, restart panel:
    ----
    systemctl start sw-cp-server
    systemctl is-active sw-cp-server
    ---
     

    2
  • Rainer Z if I was to update just the PHP 8.X via the Plesk updater GUI - what are the chances Plesk GUI going mental and screwing up? thanks Raj

    0
  • Rainer Z you are really short sighted? How many server do you have active? Probably less than 100 or perhaps even less than 10? Compare that situation to ours (over 1200 servers; not all Plesk luckily). And do the math on the amount of hosting accounts and think again on how many people do NOT update their website (Wordpress, custom PHP, whatever). Oh well. You are clearly shortsighted. Haha. 

    -6
  • Vladimir Levchuk : Thanks a lot for keeping us posted here and the great article above, clearly showing what to do, what it already patched, what is planned to be released soon and even mentioning an option for PHP version hat have been EOL for years. 
    You made my day, helped me solve this fast and you + your team totally rock! Kudos to you and keep up the great work.

    1
  • Completely agree with Rainer Z comment!

    2
  • In regards to Rainer Z's remark: 

    c.) If you chose to use outdated software, you can also choose to book additional maintenance services. Your freedom, your choice, your responsibility

    You are really short sighted aren't you?! Like I chose what our hosting customers are running? Really…

    Rainer Z member since 32 minutes ago hahahaha. Byebye.

    -5
  • Keith Dawson “what Do I need on the Plesk end to be protected” (after updating php 8.5 to 8.5.12): 
    Make sure the plesk panel is also updated, see https://support.plesk.com/hc/en-us/articles/44397729587351/comments/44415621939991
    And kudos to you for being the first of the commenters to update your server

    0
  • Update, applying a Plesk update worked.

    2
  • Please release the update for Windows soon. 

    3

Please sign in to leave a comment.