Log in 
By now, you’ve probably heard about the two critical PHP vulnerabilities announced this week. The fixes came out on October 21. The technical details are public too.
When PHP first announced the release, the full details were still under wraps. The published advisories now explain how the vulnerabilities work. They also identify the releases that contain the fixes.
In this article, we’ll bring together that information for Advanced Hosting clients. We’ll cover the affected setups, the patched releases and how PHP administration relates to our services.
How this relates to your Advanced Hosting service
If your agreement includes server administration, support can confirm the update status of your service. This includes work already completed, any remaining steps, and whether anything is needed from your team.
If you manage your own server software, your administrator or development team can confirm whether the PHP fixes are installed. Advanced Hosting Support can help with questions about your hosting service and the assistance covered by your agreement.
What PHP has confirmed
The vulnerabilities are tracked as CVE-2026-109618 and CVE-2026-109619. Both have a CVSS v4.0 severity score of 9.2, which puts them in the critical category.
They affect how PHP handles memory while processing requests. Under certain conditions, an attacker can use them to run code on a server without logging in.
- CVE-2026-109618 concerns what happens when PHP runs out of memory. It can leave internal data only partly prepared. PHP may later treat that incomplete data as valid during request cleanup.
- CVE-2026-109619 involves data left over from a previous request. A PHP worker can keep a reference to memory that has already been freed. A later request handled by that worker can then access it.
The technical advisories describe confirmed remote code execution scenarios involving Apache with mod_php and PHP-FPM. The exact conditions vary by vulnerability, application and server setup.
Which installations are covered
PHP’s advisory covers installations serving web requests. It includes PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed.
This also matters for PHP running inside virtual machines and containers. Some applications come with their own copy of PHP. A server can therefore have several installations, even if only one is normally visible to the team managing a website.
The scope is broader than websites with file upload forms. Although upload processing features in some confirmed attack paths, the vulnerabilities concern PHP’s underlying memory and request handling.
Which versions contain the fixes
The PHP project released the following versions with fixes for both vulnerabilities. Each row applies to the branch shown.
| PHP branch | Earlier PHP project releases | First release with both fixes |
| 8.2 | 8.2.0–8.2.34 | 8.2.35 |
| 8.3 | 8.3.0–8.3.35 | 8.3.36 |
| 8.4 | 8.4.0–8.4.26 | 8.4.27 |
| 8.5 | 8.5.0–8.5.11 | 8.5.12 |
Vendor packages can look different. Linux distributions and support vendors may add the fixes to an older PHP package while keeping its base version number. This is called backporting.
That means a lower version number does not always mean the fixes are missing. The vendor’s security advisory and package details establish whether a build addresses both CVEs.
For PHP 8.1 and older, options depend on the distribution or support vendor. Some offer patched packages. Moving to a supported PHP branch is another option. PHP has also published limited source patches for PHP 7.4, 8.0 and 8.1 for teams building from source.
Why update status can differ between projects
Different applications on the same server can use different PHP versions. Containers may have their own packages too. As a result, the update status can differ from one project to another, even when they share the same hosting infrastructure.
A patched package takes effect when the processes running PHP load it. Existing workers can continue using the previous version until they restart. These may be PHP-FPM workers, Apache with mod_php, another application server or containers. Restarting a reverse proxy alone does not replace those PHP processes.
This also explains why a command-line version number may differ from the PHP version serving a website. They can refer to separate installations. Runtime and application checks are part of establishing the status of a specific project.
Where temporary protections fit
Where temporary protections fit
PHP’s maintainers describe installing the fixes as the only complete way to address both vulnerabilities. Their advisory also outlines temporary controls for environments where an update is not immediately possible.
For Apache with mod_php, one example is enforcing an unlimited PHP memory setting in the Apache server configuration:
php_admin_value memory_limit -1In KVS setups where the application overrides ordinary php.ini memory settings, this administrator-level directive prevents runtime changes. It belongs in the Apache configuration, not .htaccess. PHP-FPM uses different configuration syntax.
The value -1 removes PHP’s per-request memory cap. This reduces one controllable trigger for CVE-2026-109618, but underlying memory allocation failures remain possible. Request-size controls and container memory limits remain relevant.
For confirmed session-related paths in CVE-2026-109619, PHP also describes disabling upload progress in the server’s php.ini:
session.upload_progress.enabled=0The setting takes effect before request parsing, with all affected PHP workers restarted afterward. It blocks the confirmed session paths, not every variant.
These settings do not establish that existing upload-blocking rules can safely be removed. Cloudflare and web-server filtering remain supplementary controls. Filtering can also affect application behavior, including normal forms and file uploads.
Our response procedure
For services that include server administration, our response procedure covers:
- Checking which projects use PHP and identifying the relevant installations.
- Reviewing existing protections, including whether all domain traffic passes through Cloudflare.
- Installing available fixes on supported systems and restarting the processes that run PHP.
- Checking that web requests use the patched version and that the application works as expected.
Where an update is not immediately available, the procedure includes assessing temporary controls. These may involve PHP configuration changes or Nginx request filtering while a suitable patched package or upgrade is arranged.
Our Support team is available for questions about your hosting service and the assistance covered by your agreement.
