PHP: PHP2Shell – CVE-2026-109618 and CVE-2026-109619, Temporary Fix
0 (0)

By | 10/21/2026
0 Comment
Click to rate this post!
[Total: 0 Average: 0]

UPD: The official patch is already out, see PHP 8.5.12 Release Announcement. But it’s not available in the Amazon Linux repositories yet.

I barely had time to recover from the issue with Updraft and the RTFM hack the day before yesterday – and here we go again. But this time, I’d really like to avoid any more trouble with RTFM.

See RTFM: TeamUpdraft (UpdraftPlus) hack and the WordPress blog RTFM.

I guess everyone has already heard about the new critical vulnerabilities in PHP – CVE-2026-109618 and CVE-2026-109619, which could potentially allow unauthenticated remote code execution on a server.

The new attack takes advantage of multipart request processing and the file upload progress tracking mechanism, session.upload_progress.

And the main problem is that multipart request processing happens before the PHP script itself starts running – so even websites that don’t directly use file uploads or PHP sessions may be vulnerable.

Until the patch is available and installed, the temporary mitigations are to disable session.upload_progress.enabled and block multipart requests at the web server level. Disabling upload progress reduces the attack surface, but it isn’t enough to address both vulnerabilities on its own. Blocking multipart requests temporarily breaks file uploads, but closes off the known attack vectors.

I won’t go into the attack details, but I’ll quickly document the changes I made on my RTFM server, which is (still) running WordPress, while waiting for a patched package.

I’m using NGINX as the web server, so that’s what I’ll use in the examples.

See:

PHP-FPM and disabling upload_progress

The current version is the latest one available to me, but it doesn’t include the official patch yet, so it’s vulnerable:

root@ip-10-0-3-146:~ # php -v
PHP 8.5.11 (cli) (built: Sep 22 2026 13:32:06) (NTS gcc x86_64)
Copyright (c) The PHP Group
Built by Amazon Linux
Zend Engine v4.5.11, Copyright (c) Zend Technologies
    with Zend OPcache v8.5.11, Copyright (c), by Zend Technologies

Let’s check which configuration files are being used and the current value of session.upload_progress:

root@ip-10-0-3-146:~ # php-fpm -i | grep -E 'Loaded Configuration File|Scan this dir for additional .ini files|session.upload_progress.enabled'
Loaded Configuration File => /etc/php.ini
Scan this dir for additional .ini files => /etc/php.d
session.upload_progress.enabled => On => On

Create the /etc/php.d/99-disable-session-upload-progress.ini file and override session.upload_progress.enabled, setting it to off:

; Temporary mitigation for CVE-2026-109618/CVE-2026-109619
session.upload_progress.enabled = Off

Check whether PHP-FPM sees these changes:

root@ip-10-0-3-146:~ # php-fpm -i | grep -E 'Additional .ini files parsed|99-disable-session-upload-progress|session.upload_progress.enabled'
Additional .ini files parsed => /etc/php.d/10-opcache.ini,
/etc/php.d/99-disable-session-upload-progress.ini
session.upload_progress.enabled => Off => Off

Check the syntax:

root@ip-10-0-3-146:~ # php-fpm -t
[21-Oct-2026 14:36:12] NOTICE: configuration file /etc/php-fpm.conf test is successful

Reload the PHP-FPM configuration:

root@ip-10-0-3-146:~ # systemctl reload php-fpm

And one more small change – this time in NGINX.

NGINX and blocking multipart uploads

Edit /etc/nginx/conf.d/rtfm.co.ua.conf and add the following at the beginning of the file:

map $http_content_type $block_multipart {
    default       0;
    "~*multipart" 1;
}

Here, map checks the Content-Type header of each request. If it contains the word “multipart”, for example “multipart/form-data” during a file upload, the $block_multipart variable gets the value 1. For other requests, the default is 0.

Then add a check to the server {...} block that returns 403 if $block_multipart == 1:

server {
    listen 80;
    server_name rtfm.co.ua;

    root /var/www/rtfm/rtfm.co.ua;

    ...

    if ($block_multipart) {
        return 403;
    }
   
    ...

This may break file uploads – but for now, it’ll have to do.

Check the syntax:

root@ip-10-0-3-146:~ # nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

Reload the configuration:

root@ip-10-0-3-146:~ # systemctl reload nginx

Now let’s test it – first a normal request, then one with multipart:

root@ip-10-0-3-146:~ # curl -sS -o /dev/null -w 'GET: %{http_code}\n' https://rtfm.co.ua/
GET: 200
root@ip-10-0-3-146:~ # curl -sS -o /dev/null -w 'multipart POST: %{http_code}\n' -F 'a=b' https://rtfm.co.ua/
multipart POST: 403

Done.

The official PHP security release was scheduled for October 21, 2026. Now I just need the patched package to become available for Amazon Linux.

Once it’s available, I’ll upgrade with dnf (I’m using Amazon Linux):

root@ip-10-0-3-146:~ # dnf upgrade 'php8.5*' --releasever=2023.12.20261016 -y

“Done” – but only as a temporary measure.

Loading