The PHP team has released urgent security patches for two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, both rated CVSS v4.0 9.2. If your server or application runs PHP, this update should be treated as a top priority.
What is the risk?
According to PHP, these vulnerabilities can allow unauthenticated remote code execution (RCE). In practical terms, an attacker could run arbitrary code on an affected server without needing any login or credentials. Every PHP installation that serves web requests is potentially exposed.
Which versions fix the issue?
Update to the patched release for your current PHP series:
| Current series | Update to |
|---|---|
| PHP 8.5 | 8.5.12 |
| PHP 8.4 | 8.4.27 |
| PHP 8.3 | 8.3.36 |
| PHP 8.2 | 8.2.35 |
Installed PHP from your Linux distribution?
PHP notes that Linux distributions and LTS vendors received the patches in advance. If you installed PHP through your distribution’s package manager, check your vendor for updated packages. Keep in mind that distribution version numbers may differ from the official PHP versions listed above.
Behind Cloudflare’s WAF?
Cloudflare has deployed WAF mitigations against these vulnerabilities. This reduces exposure but does not remove the vulnerability itself. Updating PHP remains the only complete fix.
Can’t update right away? Check mitigation steps
PHP’s official security advisory outlines temporary measures to reduce exposure to specific attack paths. These should be seen as a short-term stopgap only, not a substitute for patching.
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.
Next Steps
- Identify every server and application running PHP in your environment.
- Apply the patched version (or your distribution’s updated package).
- Restart PHP-FPM / your web server so the new version is loaded.
- Confirm the running version with
php -vor your control panel.
For the full advisory and update instructions, visit php.net.
Need help? Contact Your Hosting Provider Today
If you’re a NetShop ISP Managed Services customer, please contact our support team to schedule the update. All PHP patching requests related to these vulnerabilities will be handled with high priority. If you manage your own server and need help applying the update, our support team is also available to assist.
