Responding to core PHP vulnerabilities CVE-2026-109618 and CVE-2026-109619

This morning, a critical vulnerability in PHP was disclosed. It allows an attacker to run code on your server without logging in. On a default PHP install. That’s about as bad as it gets.

The PHP project has released PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35 to fix two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, that can allow unauthenticated remote code execution. The PHP project says all PHP users are strongly encouraged to update immediately. We recommend making sure every site you manage is running a patched version of PHP as soon as possible.

Remote code execution means an attacker could run their own code on your server. “Unauthenticated” means they would not need to log in first. In its advance notice on October 20, the PHP security team rated both vulnerabilities 9.2 on the CVSS v4.0 scale, which falls in the Critical range.

Every WordPress site runs on PHP. These are vulnerabilities in PHP itself, not in WordPress, a plugin, or a theme, so WordPress automatic updates will not fix them. PHP has to be updated on the server.

How we are handling it at WECAN

We manage dozens of websites and web applications for our clients, so we activated a step-by-step protocol to cover them from the first warning, without waiting for the patch:

1. Full inventory
   We reviewed every server and system we manage to know which ones use PHP, which version and how they are exposed to the internet. Without a clear inventory, it is impossible to know what to protect first.
   
2. Preventive protections before the patch
   While PHP prepared the fix, we applied two layers of protection: we turned off the PHP feature that reports pointed to as the attack path and, at the web server level, we temporarily paused file uploads, which is the type of request the attack uses. Pages, logins and forms kept working normally, and file uploads were only kept on systems where they are critical to daily operations, limited to each client’s known connections.
   
3. Monitoring attack attempts
   We reviewed server logs throughout the day. We detected automated scanners testing this type of request against the sites we manage, and they were blocked by the protections before reaching PHP.
   
4. Controlled updates, one system at a time
   We install the fixed PHP version one system at a time, checking before each change that the new version is the right one and afterwards that the site still responds the same way. If anything fails, the process stops before it affects the next one.
   
5. Communication with every client
   We told our clients what was happening, what they might notice that day (the pause on file uploads) and how to ask for an exception if they needed to upload something urgently. Once finished, we remove the temporary measures and confirm the close.

Critical vulnerabilities will keep appearing. What makes the difference is not avoiding them, but being able to react within hours: knowing which systems you have, protecting them while the fix arrives and updating without taking anyone offline.

If you are not sure who maintains your website or web application, or your PHP version is no longer supported, contact us and we will review it with you.