Critical PHP updates

There're suggestions to use the following settings in php.ini for a temporary mitigation. But there're no evidences it helps:

- PHP:

Code: 
session.upload_progress.enabled = Off
session.use_strict_mode = 1

Other sources suggest blocking multipart requests:

- Apache with a help of mod_rewrite:

Code: 
RewriteCond %{HTTP:Content-Type} multipart [NC]
RewriteRule ^ - [F,L]

- Nginx:

Code: 
if ($http_content_type ~* "multipart") {return 403;}

An HTTP multipart request is an HTTP request that HTTP clients construct to send files and data over to an HTTP Server. It is commonly used by browsers and HTTP clients to upload files to the server.

All POST requests and file-uploads might stop working after applying the patch to NGINX/Apache.
 
Last edited:
Cloudflare has rules in place to mitigate known attacks. Does modSecurity with owasp or comodo rules do anything good on DirectAdmin?
 
Jo from Hosted Power here (we run a fair number of DirectAdmin servers).

@brinkie @adam12: for the 7.x boxes that won't get an upstream fix, we wrote a small PHP extension this morning and open-sourced it, in case it helps anyone here.

It switches off the session upload-progress handler (where the researchers who reproduced the bugs placed them) at PHP startup. So it targets the same thing as session.upload_progress.enabled = Off, with two differences: a user's .user.ini or .htaccess can't turn it back on, and it covers every PHP version on the box (5.6 to 8.5). Uploads keep working. The repo has the DirectAdmin steps, including a CustomBuild post-hook so a PHP rebuild doesn't drop it. You can check it per version, e.g.: /usr/local/php74/bin/php --ri hp_uploadprogress_guard

github.com

GitHub - HOSTED-POWER/php_uploadprogress_guard

Contribute to HOSTED-POWER/php_uploadprogress_guard development by creating an account on GitHub.
github.com github.com

To be honest about its limits, in line with what @zEitEr and @Freddy said: there's no evidence yet that upload-progress mitigations are enough, and if the bug turns out to be reachable outside that handler, ours won't cover that part either. It's a few hours old, and it doesn't replace the new PHP builds @fln mentioned; install those as soon as they're out. We'll check it against the official advisory at 16:00 CEST and report back here either way.
 
mcormick said:
https://www.aikido.dev/blog/critical-vulnerabilities-in-php-php2shell : Exploitation has been reported in the wild, and the previously suggested configuration mitigations do not protect against these vulnerabilities.
You can check whether your website is affected via aikido.io .
Click to expand...
I ran the test with all the checkboxes on and it failed on a PHP 8.4 website. The technical details say it got a 403 header but my modSecurity log doesn't show anything. So is the test really working?
 
Had some fun, together with Gemini, forcefully migrating old joomla and wordpress sites which where not governed by installatron on da.
It scared me a bit trusting an AI but I have to say it came through with a big W :-) Now all is 8.3 and the wait starts...
 
mcormick said:
https://www.aikido.dev/blog/critical-vulnerabilities-in-php-php2shell : Exploitation has been reported in the wild, and the previously suggested configuration mitigations do not protect against these vulnerabilities.
You can check whether your website is affected via aikido.io .
Click to expand...

Tested some sites after applied both fixes in PHP and Nginx and some without fixes in Nginx here:

- https://php2shell.aikido.io/

and it reports:

2026-10-21_195358_php2shell.png


So can not confirm anything either.
 
Freddy said:
I ran the test with all the checkboxes on and it failed on a PHP 8.4 website. The technical details say it got a 403 header but my modSecurity log doesn't show anything. So is the test really working?
Click to expand...
I've seen the requests come in, one of them being a really long array in the query string. In my case ModSec blocked the requests.
If you have Cloudflare on your domain, I read they updated their WAF rules. In that case requests might not reach your server.

Edit: To clarify, we blocked all multipart-formdata requests via ModSec on all servers until the patches are made public.
 
Last edited:
mcormick said:
I've seen the requests come in, one of them being a really long array in the query string. In my case ModSec blocked the requests.
If you have Cloudflare on your domain, I read they updated their WAF rules. In that case requests might not reach your server.
Click to expand...
So your ModSec works? Do you use the default owasp rules or something specific?
My test was on a site that doesn't use Cloudflare, so that didn't block it either.
 
SecRule REQUEST_HEADERS:Content-Type "@contains multipart" "id:1900001,phase:1,deny,status:403,log,msg:'Multipart Content-Type blocked'"
Click to expand...
or
<IfModule security2_module>
SecRule ARGS_NAMES "@streq PHP_SESSION_UPLOAD_PROGRESS" \
"id:1096181,phase:2,deny,status:403,log,t:none,msg:'PHP upload progress request blocked'"
</IfModule>
Click to expand...
might be options for /etc/httpd/conf/extra/httpd-includes.conf until we know more.
 
Remember when you could update just PHP, without having to wrestle with changes that other updates may make? Oh... those were the days.
 
21 Oct 2026

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.
 
  • 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.
 
Code: 
cd /usr/local/directadmin/custombuild/
./build update

sed -i 's/php85:8.5.11:/php85:8.5.12:/g' versions.txt
sed -i 's/php84:8.4.26:/php84:8.4.27:/g' versions.txt
sed -i 's/php83:8.3.35:/php83:8.3.36:/g' versions.txt
sed -i 's/php82:8.2.34:/php82:8.2.35:/g' versions.txt

./build php

Good luck!
 
You must log in or register to reply here.
Back
Top