Fix CVE-2026-109618 and CVE-2026-109619

Start from a per-website inventory: SAPI, branch, extensions, package and origin. The php-cve-2026-109618-audit skill covers that diagnosis. Work only on authorized systems; a hosting account can change options without being able to update the engine.

The official fixed versions are 8.2.35, 8.3.36, 8.4.27 and 8.5.12. A distribution may keep an older base version and include a backport: require the revision and the vendor advisory. Only disabling session.upload_progress does not fix both vulnerabilities.

Preparation

Save the configuration you are going to change and record the initial health of each website. Review the package transaction before installing: do not change branches, remove packages or accept unexpected new dependencies. Check the syntax before restarting. Use a test environment and a maintenance window when the service requires it.

Mitigation while the patch arrives

Disable session.upload_progress.enabled in a configuration loaded before parsing the request. In an FPM pool:

php_admin_flag[session.upload_progress.enabled] = off

With Apache and mod_php, use a server configuration compatible with the installed module:

php_admin_flag session.upload_progress.enabled off

In other handlers or panels, first identify the INI files loaded by the website's PHP and the persistent mechanism supported by the vendor. Do not write to paths of versions or pools that are not in use. ini_set() and .user.ini are not useful for this mitigation.

Validate the configuration and restart or replace all affected workers. A reload only works if it is confirmed that it removed all previous processes; do not promise the absence of outages. In LiteSpeed, use the account's PHP restart, without restarting unrelated services.

The official advisory also proposes reducing the POST and file size, and memory_limit=-1 to reduce a memory exhaustion path. The latter measure requires external resource limits: do not apply it blindly, because it can exhaust the server's memory. None of these measures replaces the patch.

Update through the correct channel

• Ubuntu or Debian: identify the installed PHP packages and update that list with APT. Compare the revision with the distribution advisory; php -v may keep the base version. Simulate the transaction and keep or merge the configuration deliberately.
• Surý: Ubuntu uses its PPA; Debian uses packages.sury.org/php. Do not configure the Debian repository with an Ubuntu distribution. If the patch is missing, check the maintainer's current advisories; changing vendors requires a migration decision and testing.
• RHEL and derivatives: identify the AppStream module or repository and the active branch. Preview the update of the installed packages; avoid wildcards that could include another branch or affect different websites.
• cPanel, Plesk, DirectAdmin or CloudLinux: use the panel channel: EA-PHP, Plesk PHP, CustomBuild or alt-php, as applicable. Review all active handlers. In shared hosting, if no fixed version is available, keep the mitigation and document that the update depends on the vendor.
• Repositories with signature errors: verify the new key and its fingerprint through the current official documentation, keep the previous keyring and update the file indicated by signed-by. Do not disable signature checking or import a key just because its identifier appears in an error.
• Containers: update the base image or its packages, rebuild and replace the containers. Check the PHP inside the new containers, including workers and scheduled tasks. Updating the host does not update the image.
• VMs and cloud: apply the procedure inside each authorized guest that runs PHP; updating the hypervisor does not patch its virtual machines.

Activation and verification

For mod_php, restart Apache after validating the configuration: a gradual reload may keep the old module. With FPM, restart or replace all workers of the affected services. Follow the equivalent mechanism of the panel or LiteSpeed.Check the patched package and the runtime that serves requests, not just the CLI. If you need a temporary diagnostic, restrict access, return only the version and necessary options, avoid phpinfo(), and ensure it is removed even if the test fails.

Verify critical pages and operations, new errors, and 5xx responses during a window proportional to traffic, for example 30 minutes. A (deleted) mapping in /proc/<pid>/maps deserves review, but its presence or absence does not by itself prove which patch a worker is running.

Record via the web the installed revision, the verified restart, and the pending limitations. Do not re-expose a vulnerable version to resolve a regression: prepare containment and a data-compatible rollback. For unsupported branches, use php-version-upgrade or an equivalent guide and test the migration before the change. Do not suspend or delete domains as part of this patch without a specific assignment.

Sources

• Official PHP advisory and fixed versions.
• CVE-2026-109618.
• CVE-2026-109619.
• Ubuntu USN-8948-1.
• Surý's Debian and Ubuntu repositories.
• Restarting PHP in LiteSpeed.