CVE-2026-109618 in PHP: critical memory failure, real risk and urgent update

Published on 2026-10-27 by frfrand

CVE-2026-109618 explained: discovery, affected PHP versions, RCE risk due to OOM memory, and official measures from October 21, 2026.

CVE-2026-109618 in PHP: critical memory failure, real risk and urgent update

What is CVE-2026-109618 and why is it being discussed?

On October 21, 2026, the PHP team announced two critical flaws in its engine. One is CVE-2026-109618, related to how PHP handles memory errors during request processing. Its potential consequence is serious: in certain situations, a request sent from the Internet could cause memory corruption and remote code execution without logging in.

This flaw does not originate from a WordPress plugin. It is in the PHP platform on which WordPress, Drupal, Joomla, and many custom applications run. That is why reviewing only the plugins is not enough.

Who found the vulnerability?

The research was disclosed by Wiz Research in coordination with the PHP security team. Wiz's technical publication and vendor advisories describe the discovery, reporting, and patch preparation work. It is an example of how in-depth research into the language engine can detect problems that do not appear in a website code audit.

What happens technically?

When an application receives a request, PHP reserves memory to interpret internal data. If an out-of-memory (OOM) error occurs during that process, a certain structure could remain partially initialized. Later, during cleanup, the program could interpret those incomplete data as if they were valid. That difference opens a possibility of memory corruption.

How could it be exploited?

The general idea is to trigger conditions that lead to memory failure during request processing and alter the behavior of the PHP worker. In an exploitable scenario, the attacker manages to make the process execute code with the permissions assigned to it. This does not mean that any request takes control of the operating system: feasibility depends on integration, configuration, memory protections, and the execution path.

Which servers are affected and which is most at risk?

PHP warned about installations serving web requests: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, and LiteSpeed. It expressed special concern about mod_php, with a demonstrated exploitation scenario without authentication before application code starts. Other integrations may have different requirements and should be evaluated individually.

What are the fixed versions?

The manufacturer published the following first patches on its branches: - PHP 8.5.12 - PHP 8.4.27 - PHP 8.3.36 - PHP 8.2.35

Previous versions of those branches require review. PHP 8.1 and earlier are outside the project's main support. Some distributions and LTS vendors have incorporated their own patches or backports; check their exact bulletin if you use system packages. The PHP team also offered minimal code backports for certain old branches, which does not make them general support branches.

How do I check if my WordPress or my PHP API are exposed?

Identify all environments: production, staging, scheduled tasks, containers, and forgotten servers. php -v helps, but note: the CLI version may differ from PHP-FPM or Apache, so contrast the actual web server configuration. Check the package version and vendor revision, how traffic reaches PHP, and which workers continue running after an update.

How is it resolved and what do I do while updating?

The complete solution is to install the patch and restart or redeploy all relevant processes. PHP published temporary measures to reduce specific vectors, such as adjusting input limits and certain memory parameters under technical supervision. These are changes that can affect availability and do not make an installation secure without updating; it is not advisable to copy them without analyzing resources and configuration. Make a backup, staging, update, restart, and check application response.

Quick questions

Does updating WordPress fix the CVE? No. The fix is for the PHP runtime, although you must then validate WordPress.

Is a WAF enough? No: it is an additional barrier, not the engine repair.

How do I know if my site was already exploited? Check for signs of unexpected processes, file changes, and access, but do not claim compromise just for using an affected version. In case of indicators, preserve evidence and follow an incident response process.

Verifiable sources: PHP Notice of 10/21/2026 · AWS Bulletin · Google Cloud Response · CVE Record.

Where is the information updated and how to request guidance?

At ArduMaker — CVE and support we maintain information to review incidents and channel inquiries, especially in WordPress and the technologies that run it. To evaluate a specific case, provide technology, version, operating system, deployment mode, and relevant error messages without publishing credentials. An announced CVE does not mean that all systems are compromised.

Editorial review: October 27, 2026. Recommendations may change with new manufacturer publications.

Practical example: updating PHP in a WordPress with PHP-FPM

Situation: the administrator updates WordPress, but the website continues to use PHP 8.4.26. This does not fix CVE-2026-109618, because the flaw is in the PHP engine. The first fix for branch 8.4 was 8.4.27.

On an Ubuntu VPS with PHP-FPM, start by identifying services and installed version:

php -v
systemctl list-units --type=service 'php*-fpm.service'

Also check which FPM socket Nginx/Apache uses and the version of the worker serving the website; the CLI may be different. Install the fixed package from the trusted repository, restart all affected workers and validate critical functions.

Before: apparently updated website, vulnerable PHP runtime. After: patched runtime, Docker image or package rebuilt if applicable, new workers and smoke tests for login, forms and payments.

What specific risk is reduced? The memory failure during an HTTP request that could open a path to code execution with the process permissions. It is not necessary to "test the exploit" against production to confirm that you installed the fixed version.

CVE-2026-109618 in PHP: critical memory failure, real risk and urgent update
  • PHP
  • CVE-2026-109618
  • PHP2Shell
  • RCE
  • Seguridad WordPress

On ArduMaker

  • WordPress and WooCommerce: Sites, WooCommerce stores and Elementor on your VPS, with one-click backups and moving in from your current host.

Keep reading

All articles · VPS plans