Vulnerabilities CVE-2026-109618 and CVE-2026-109619 have been disclosed, allowing unauthenticated remote code execution (RCE) during abnormal termination and request state management in the PHP core engine. These issues originate from memory corruption and Use-After-Free defects in the PHP execution engine itself, not from web applications such as WordPress or GNUBoard. To resolve the issues, immediately upgrade to a security-patched version such as PHP 8.5.12, 8.4.27, 8.3.36, or 8.2.35, and restart the worker processes.
PHP Engine Vulnerabilities That Cannot Be Prevented by Updating Only the Web Application
On October 21, 2026 (UTC), the PHP development team announced two security vulnerabilities rated 9.2 under CVSS v4.0. An attacker can execute arbitrary code on a server simply by sending a crafted HTTP request, without going through a separate login process.
These defects operate in the PHP core layer that parses web requests and cleans up memory. Therefore, even if a site's CMS and plugins are kept up to date, it remains exposed if the PHP runtime itself is outdated. In particular, under Apache's default mod_php configuration, a single request can reportedly enable code execution before the web application code even runs.
If the attack succeeds, the intruder gains the privileges of the system account under which the PHP process runs. This does not immediately grant root privileges, but the attacker can create a web shell in the web root directory or read database connection information stored in configuration files to exfiltrate or modify internal data. If multiple websites on a single server share the same PHP-FPM execution account, a compromise of one site may also spread to other sites on the server.
How Memory Corruption and Use-After-Free Occur During Abnormal Termination
Both vulnerabilities occur because memory is not safely cleaned up when an exceptional situation arises during request processing. Their triggering conditions and internal behavior differ.
CVE-2026-109618 (memory corruption during out-of-memory handling): When PHP exceeds the permitted memory limit (Out-Of-Memory) while processing a request, it calls longjmp() to immediately stop execution. If processing stops while an internal request data structure has not yet been fully initialized, the incomplete state may remain without being rolled back. A subsequent request cleanup routine then trusts and accesses this uninitialized memory as valid data, leading to memory corruption and remote code execution.
CVE-2026-109619 (Use-After-Free referencing memory released by a previous request): Some global states or error-handling states inside PHP temporarily point to memory areas owned by a single request. When a request terminates abnormally because of a fatal error or insufficient memory, the actual memory may be released while an internal pointer referencing it remains uninitialized. In environments that reuse worker processes, such as PHP-FPM or mod_php, when the same worker receives and processes the next HTTP request, it may read the already released memory area again (Use-After-Free), creating a code execution path.
The official security advisory identifies the session upload progress feature (session.upload_progress), configuration warnings output before request initialization, and fatal error backtraces in PHP 8.5 (fatal_error_backtraces) as confirmed paths for CVE-2026-109619. However, it states that other variant paths remain even if these paths are blocked.
Patch Status by PHP Version and Impact by Execution Environment
PHP 8.2 through 8.5 versions lower than the fixed versions are affected, while PHP 8.1 and earlier, which have reached end of support, are not covered by official updates from the PHP project. All installations that process web requests, including PHP-FPM, mod_php, php-cgi, FrankenPHP, and LiteSpeed, are in scope. The official advisory considers the risk highest for mod_php. Red Hat classifies PHP-FPM as conditionally affected through application-level paths.
| PHP Version Series | Vulnerable Version Range | Fixed Patch Version | Support Status and Notes |
|---|---|---|---|
| PHP 8.5 | 8.5.0 ~ 8.5.11 | 8.5.12 | Official security update released |
| PHP 8.4 | 8.4.0 ~ 8.4.26 | 8.4.27 | Official security update released |
| PHP 8.3 | 8.3.0 ~ 8.3.35 | 8.3.36 | Official security update released |
| PHP 8.2 | 8.2.0 ~ 8.2.34 | 8.2.35 | Official security update released |
| PHP 8.1 and earlier | Not covered by official updates | No official release | End of life (EOL). For 7.4, 8.0, and 8.1, only minimal backports for source builds are provided; check distribution and LTS vendor packages |
Test environment: As of October 22, 2026, in a Linux server environment using the Remi repository, PHP 8.4.26 was upgraded to 8.4.27, and PHP-FPM worker restarts and web request handling were verified.
Package Update and PHP-FPM Mitigation Configuration Procedures
The PHP development team advises that configuration changes alone cannot block all attack paths and that updating to a patched version is the only complete solution. To reduce the attack surface even after updating, you can also apply mitigation measures that disable unnecessary features.
-
Install PHP package updates
Upgrade the packages through the operating system's package manager to the fixed version for the PHP series in use (8.4.27 for the 8.4 series). After installation, first check the CLI version in the terminal.php -vRunning the command displays the updated version number and build date, such as
PHP 8.4.27 (cli). However, the CLI version may differ from the version of the PHP process actually connected to the web server, so you must complete the next steps. -
Adjust PHP-FPM settings to reduce the attack surface (optional and temporary mitigation)
If applying the update immediately is difficult or you want to add another defensive layer, back upphp.inior the PHP-FPM pool configuration file (for example,/etc/php-fpm.d/www.conf) and adjust the items below.php_admin_value[session.upload_progress.enabled] = Off php_admin_value[post_max_size] = 32M php_admin_value[upload_max_filesize] = 30MDisabling
session.upload_progress.enabledblocks the confirmed session-based attack path. Loweringpost_max_size(to8Min environments that do not need file uploads, or32Mwhere they are needed) makes it more difficult to induce memory exhaustion with large requests. Because multipart overhead headers must be considered, setupload_max_filesizeslightly lower thanpost_max_size. In PHP 8.5 environments, also applyfatal_error_backtraces = 0. -
Check PHP-FPM configuration syntax and restart the processes
After saving the configuration, test for syntax errors and restart the PHP-FPM service.php-fpm -t systemctl restart php-fpmIf there are no configuration problems when
php-fpm -truns, the messageNOTICE: configuration file ... test is successfulappears on the screen. Worker processes must be restarted so that existing outdated workers residing in memory are terminated and the new patch and settings take effect. -
Verify the effective version through a web request
Open the information tab in WordPress's 'Site Health' or a diagnostic page for the web server integration, and verify that the PHP-FPM worker handling web requests responds with a patched version such as8.4.27. If you created a temporary PHP diagnostic file for verification, delete it immediately afterward so that system information is not exposed externally.
What to Do When Updates Are Delayed or Configuration Changes Cause Side Effects
When package downloads fail because third-party repository mirrors such as Remi are slow to update
Immediately after an urgent security patch, concentrated traffic or synchronization delays may prevent update packages from appearing immediately in third-party repositories such as rpms.remirepo.net, or may result in slow download speeds. The official advisory states that updates are not posted to this volunteer-operated repository on the day of the announcement and recommends switching to distribution packages or source builds.
In this case, you can directly specify a mirror server address with normal speed and completed synchronization in the repository settings, then proceed with the update. Even when changing the mirror manually, keep GPG signature verification (gpgcheck=1) enabled to prevent package tampering. If mirrors cannot be used, use official backport packages from the OS distribution or compile and apply the source code directly.
When mitigation settings raise concerns about out-of-memory (OOM) errors or rejected uploads
When an immediate update is not possible, the official advisory proposes memory_limit = -1 (unlimited) as a mitigation for CVE-2026-109618 and recommends imposing container or cgroup memory limits at the same time. However, removing the memory limit on a server with limited physical memory may allow a single request to consume all server memory, causing the operating system's OOM Killer to forcibly terminate critical daemons. This setting is a temporary measure until the update is applied, and it is safer to restore the original memory limit after updating to a patched version.
Also, when lowering post_max_size below its existing value (for example, 64MB), first check how the site transfers files. A site that directly uploads large backup files or plugins through an administrator web page may have its requests blocked. On the other hand, if large files are transferred through SFTP or rsync, or if the application itself is already limited to 30MB or less, lowering PHP's upload limit to 32MB will not affect the service.
If PHP-FPM workers terminate abnormally from time to time after a PHP version upgrade, consider checking the OPcache JIT (Just-In-Time) compilation setting. The JIT feature (for example, opcache.jit=1255) is not directly related to this security vulnerability, but if it has previously caused stability problems after version changes, you can disable it with opcache.jit=off in the configuration file to prevent crashes.
Frequently Asked Questions
Will updating WordPress or its plugins to the latest versions resolve the issue?
No. This vulnerability occurs in the PHP core engine, before WordPress or security plugins run. A web application firewall such as Cloudflare or AWS WAF can temporarily block known attack patterns, but the PHP version on the server itself must be updated through the hosting provider or server administrator for a fundamental resolution.
Is it safe to skip the update if session.upload_progress.enabled is disabled?
No. The official advisory states that this setting blocks only the confirmed session path and cannot block other variant paths. In addition, the setting must be placed where it is applied before request interpretation, such as php.ini, the FPM pool, or the server configuration—not in ini_set() or the FPM .user.ini—and all workers must be restarted. Installing the patch is the only complete solution.
Can the system be put directly into production without additional checks after applying the patch?
Updating prevents future attacks but does not reveal whether the system was previously compromised. It is advisable to perform a separate check for prior compromise after completing the update. Check for recently and abnormally created or modified PHP files, such as web shells, in web directories, and investigate web server access logs and PHP error logs for abnormal large POST requests or repeated memory error records.
How should container or cloud image environments be handled?
Updating packages on the host server does not automatically change the PHP runtime included inside a container. Therefore, rebuild and redeploy the container image using a base image that includes a patched version (8.5.12, 8.4.27, 8.3.36, or 8.2.35).