The PHP project has released the emergency fixes it announced yesterday. 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 (RCE), meaning a remote attacker may be able to run code on a server without logging in. PHP’s security advisory says all PHP installations that serve web requests are at risk, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed, and that it considers the risk highest for mod_php, where it has a demonstrated exploit in which an unauthenticated request triggers the attack before any application code runs.
The two flaws are CVE-2026-109618, where out-of-memory handling can interrupt PHP while internal request data is only partly set up, so that cleanup treats invalid data as valid; and CVE-2026-109619, where request-owned internal state can survive after its memory has been freed and be reused by a later request handled by the same worker. This follows our earlier post on the advance warning, which could not yet say which versions were affected.
How to check if you’re affected
Affected products are PHP installations on versions older than 8.5.12, 8.4.27, 8.3.36 or 8.2.35 within their release branch. Check the version in use with php -v on the command line, or with the version shown in your hosting panel, and do the same for the PHP inside any container image you run.
- PHP 8.1 and older no longer receive updates from the PHP project. Some distributions and long-term-support vendors provide backported fixes, so ask your vendor. As an exception, the PHP security team published minimal source backports for PHP 7.4, 8.0 and 8.1 for people who build from source.
- Linux distributions and LTS vendors received the patches in advance, so check your vendor for updated packages. PHP urges users of the volunteer-maintained rpms.remirepo.net repository to switch to distribution packages or build from source, because that repository will not have updates today.
- If you use shared hosting or a managed platform, ask the provider whether the fixed version is deployed.
PHP says only an update is a complete solution. If you cannot update right away, its advisory lists measures that reduce exposure to specific attack paths without making an installation safe:
- For CVE-2026-109618: set
memory_limit=-1in a way applications cannot override (for examplephp_admin_valuein the FPM pool or Apache configuration); set a lowpost_max_size(PHP suggests 8M for applications that do not need uploads, 32M if they do) and keepupload_max_filesizebelow it; enforce request-size, field-count and nesting limits at the web server or proxy; and use a container or cgroup limit that kills only the affected worker. PHP warns not to useRLIMIT_ASorRLIMIT_DATA, which can cause the vulnerable allocation failure. - For CVE-2026-109619: set
session.upload_progress.enabled=0inphp.ini, the FPM pool or server configuration (not viaini_set()or.user.ini) and restart every worker. On PHP 8.5, also setfatal_error_backtraces=0. PHP says these block only the confirmed paths, not other variants.
In the news up to this release, researchers at watchTowr had claimed different version ranges and a higher severity score than PHP; treat the version list in PHP’s own advisory as the authoritative one.