# Critical PHP vulnerability (CVE-2026-109618): how to protect your site today

> PHP fixes two critical unauthenticated remote code execution flaws (CVE-2026-109618 and CVE-2026-109619). Which versions to update to and how to protect your site today.

URL: https://codegea.com/en/critical-php-vulnerability-cve-2026-109618-update-now
Servers · 2026-10-22 · Derian Pinto

On 21 October 2026 the PHP team published an emergency security update. It fixes **two critical vulnerabilities that allow unauthenticated remote code execution (RCE)**: an attacker needs no username or password, only the ability to send requests to your server. If your site runs PHP (WordPress, WooCommerce, Laravel, a custom system), this affects you.

> According to PHP's own announcement, "there are no complete mitigations, updating is the only safe choice."

## What was fixed

Both flaws score **CVSS v4.0 9.2** and affect how PHP handles the memory of each request internally:

| CVE | What happens | Reference |
| --- | --- | --- |
| CVE-2026-109618 | If out-of-memory (OOM) handling interrupts PHP while internal request data is only partially initialized, request cleanup may treat the invalid data as valid. | [GHSA-w8hw-w9fx-j79w](https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w) |
| CVE-2026-109619 | Request-owned internal state survives after its memory has been freed; a later request handled by the same worker may use it before it is reset. | [GHSA-6wmf-4rv5-p3rp](https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp) |

## Fixed versions

Update to the patched version of your branch:

- **PHP 8.5** → 8.5.12
- **PHP 8.4** → 8.4.27
- **PHP 8.3** → 8.3.36
- **PHP 8.2** → 8.2.35 (this branch reaches end of life on 31 December 2026)

PHP 8.1 and older **no longer receive official updates**. The project did publish patched branches for [PHP 7.4](https://github.com/php/php-src/tree/PHP-7.4-CVE-2026-109618-109619), [PHP 8.0](https://github.com/php/php-src/tree/PHP-8.0-CVE-2026-109618-109619) and [PHP 8.1](https://github.com/php/php-src/tree/PHP-8.1-CVE-2026-109618-109619), but they are not official releases: the real fix is to move to a supported branch.

## Who is at risk

The announcement says **all installations serving web requests** are affected: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. The risk is **highest with mod_php**.

In practice, that includes:

- WordPress sites and WooCommerce stores on shared hosting or a VPS.
- Laravel, Symfony or custom applications.
- Servers nobody has updated since they were set up.

## How to check your version

1. On a server with terminal access: `php -v` (also check the version used by PHP-FPM or Apache, which can differ from the command-line one).
2. In WordPress: **Tools → Site Health → Info → Server**.
3. On hosting with a control panel: look for "PHP version" or "PHP selector".

If you are below 8.5.12, 8.4.27, 8.3.36 or 8.2.35, you are exposed.

## How to update

1. **Back up** files and database before touching anything.
2. **Shared hosting:** change the PHP version from the panel and confirm with your provider that the patched packages are installed; if not, ask for a date.
3. **VPS or own server:** update the package with the system manager (`apt`, `dnf`) or your PHP repository and **restart PHP-FPM or Apache**. Without a restart, the old process stays in memory.
4. **Containers:** rebuild the image with the fixed tag (for example `php:8.4.27`) and redeploy.
5. **Test:** check forms, payments and checkout. A patch update within the same branch rarely breaks anything, but it is worth confirming.

If you run an unsupported version (8.1 or older), plan the migration as soon as possible. In the meantime, a firewall layer such as [Cloudflare](/en/services/servers-and-hosting) cuts the noise from automated attacks, but it **does not replace the update**.

## Frequently asked questions

**Are there attacks already?** PHP's announcement does not mention active exploitation. Even so, once a patch is public, attackers compare the changes and look for servers that have not updated: the window to act is short.

**Does my host do it for me?** It depends. Managed hosts usually apply the patch themselves; on a VPS or hosting without technical support, the responsibility is yours.

**Is a WordPress security plugin enough?** No. The flaw is in PHP, not WordPress, and a plugin runs on the same vulnerable PHP.

## References

- [Security advisory: Critical remote code execution vulnerabilities, update now](https://www.php.net/archive/2026.php#2026-10-21-5) (php.net)
- [Upcoming Critical PHP Security Release](https://www.php.net/archive/2026.php#2026-10-20-1) (pre-announcement of 20 October)
- [GHSA-w8hw-w9fx-j79w](https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w) and [GHSA-6wmf-4rv5-p3rp](https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp)
- [PHP downloads (source)](https://www.php.net/downloads.php?source=Y) · [Windows](https://www.php.net/downloads.php?os=windows)

---

Not sure which PHP version your site uses, or nobody to update it? At Codegea we review your server, apply the patch and set up [ongoing monitoring and maintenance](/en/retainer) so the next alert does not catch you off guard.