Updated October 23, 2026. Two critical PHP remote-code-execution bugs, CVE-2026-109618 and CVE-2026-109619, were addressed in releases published October 21. On October 23, the PHP project issued an informational advisory about CVE-2026-115560, a separate, unusual risk involving PHP session upload progress. A dedicated fix for this later issue had not yet been released as of October 23. These are two distinct actions: update for the first two vulnerabilities, and retain a temporary configuration mitigation for the third.

The official security timeline

October 21 fixes: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP 8.1 and older have no routine upstream security releases; distribution-maintained backports may exist and should be checked against vendor advisories. PHP-FPM, mod_php, CGI and other web-executed PHP runtimes warrant assessment. The initial flaws can permit unauthenticated RCE in relevant conditions; a WAF alone does not replace the runtime patch.

The October 23 advisory says the new issue requires an unusually specific combination: configuration sets session.serialize_handler to php_binary or php_serialize; application code changes it to php through ini_set() before session_start(); and session upload progress remains enabled. PHP describes the vector as unlikely and plans a fix in the next regular bugfix cycle. It recommends session.upload_progress.enabled=0 until then; applications that do not change the session serializer at runtime do not encounter this specific condition. Do not describe this new CVE as having the same demonstrated exploitability as the two earlier ones.

What should an Ubuntu VPS operator do?

First identify the installed versions and which runtime actually serves each site. The CLI version does not always match PHP-FPM.

php -v | head -1
dpkg -l | awk '/^ii +php[0-9.]+-(cli|fpm) /{print $2, $3}'
sudo apt update
apt-cache policy php8.3-fpm

Replace 8.3 with the installed branch. Check the package candidate and vendor changelog: a patched upstream release can precede downstream package availability, and distributions sometimes backport fixes without matching the upstream version number. Before upgrading, take a recoverable backup and inspect the list of installed branch-specific packages:

dpkg -l | awk '/^ii +php8\.3-/{print $2}'
# After reviewing the list:
dpkg -l | awk '/^ii +php8\.3-/{print $2}' | xargs -r sudo apt install --only-upgrade

Prefer vendor-supported updates over unreviewed package wildcards. Then restart affected services and verify they loaded the patched binary:

sudo php-fpm8.3 -t
sudo systemctl restart php8.3-fpm
sudo systemctl status php8.3-fpm --no-pager

For Apache mod_php, restart Apache. Persistent PHP workers or queues require their own controlled restarts. Check web responses and logs as well as package metadata.

Interim mitigation for CVE-2026-115560

Where appropriate, configure session.upload_progress.enabled = Off in the configuration applied before web request parsing — for example, the correct PHP-FPM version's configuration, or the Apache module's PHP configuration. Make a configuration backup, avoid duplicate contradictory overrides, test and restart the relevant PHP workers. One Ubuntu PHP-FPM example:

echo 'session.upload_progress.enabled = Off' | sudo tee /etc/php/8.3/fpm/conf.d/99-upload-progress.ini
sudo php-fpm8.3 -t
sudo systemctl restart php8.3-fpm
php-fpm8.3 -i | grep upload_progress.enabled

Expect the effective setting to show Off; confirm the actual runtime and pool configuration rather than trusting CLI alone. If it was already disabled in response to the October 21 advisory, do not enable it again until PHP ships the relevant correction.

Important: this setting does not disable file uploads

session.upload_progress.enabled = Off disables only PHP's legacy session-based mechanism that records an upload's progress in session data. It does not disable the HTTP multipart upload, PHP's normal file handling, or JavaScript progress indicators calculated in the browser with XMLHttpRequest or another client-side API. Forms can still submit images and documents. A rare application explicitly reading the session upload-progress key may lose its progress bar; test that workflow if your software depends on it. Do not confuse this with file_uploads=Off, which would disable PHP uploads.

What managed-hosting customers should know

A managed-hosting customer should consult their provider's current maintenance notice; a VPS administrator remains responsible for updating their own server. In MuseDock, a control panel can help select a supported PHP version per website, but a dashboard indicator does not replace verifying the deployed packages and live workers. PHP security-patch releases inside a supported branch ordinarily require no CMS code change; moving an old WordPress installation or custom application to a newer branch does require compatibility testing.

Monitoring and verification

Look for abandoned PHP branches, lingering old workers, unusual files, new scheduled tasks, and unexplained outbound traffic. One optional read-only check for outdated executable images is:

for p in /proc/[0-9]*; do exe=$(readlink "$p/exe" 2>/dev/null); case "$exe" in *php*deleted*) echo "$exe";; esac; done

An empty output does not itself prove that all hosts are patched. If you suspect compromise, preserve evidence and involve your incident response process rather than deleting files blindly.

Does this setting affect WordPress, CMS platforms or upload progress bars?

Usually not. Two distinct mechanisms may have similar names. session.upload_progress.enabled controls a PHP-server feature that stores upload progress in session state so another request can read it. Modern upload interfaces commonly measure transmitted bytes in the browser using events such as XMLHttpRequest.upload.onprogress. Disabling session-based PHP tracking does not disable uploads or browser-based JavaScript progress indicators.

WordPress and browser upload libraries

WordPress commonly uses libraries such as Plupload and Moxie to upload media and show progress in the browser, rather than relying on PHP session upload tracking. Custom or older plugins may work differently, so operators should test important upload forms rather than assume every possible extension behaves identically.

MuseDock CMS and MuseDock Panel

Documented media and content upload interfaces in MuseDock CMS (public repository) use browser-side upload progress events. Turning off PHP session upload progress should not interrupt uploads or those progress bars. The reviewed parts of MuseDock Panel (public repository) showed no dependency on PHP's session-upload-progress feature. This is not a comprehensive audit of third-party plugins or every installation.

Older applications and misleading matches

Legacy libraries may contain identifiers such as UPLOAD_IDENTIFIER or variables named upload_progress. A text search that finds these names does not prove that the application reads progress from PHP sessions. You need to inspect the actual server-side use. Where an application truly relies on session progress tracking, its progress bar may stop updating, while file transfer usually continues normally.

To confirm compatibility, test a representative upload, verify the saved file and check the progress indicator. Functional tests are more reliable than interpreting isolated variable names.

Frequently asked questions

Does the mitigation break uploads? No: it disables only PHP session-based upload-progress tracking. A custom progress bar using that specific session mechanism may stop updating; uploads remain functional.

Is PHP 8.4.27 enough? It patches the October 21 CVEs. Until a dedicated correction ships, follow the October 23 configuration advice for CVE-2026-115560 where applicable.

Do I need to update if my VPS does not use PHP? Not for PHP-specific vulnerabilities, but continue maintaining the remaining stack.

Sources