A new PHP security update deserves immediate attention from companies, developers, and site owners. The PHP team announced fixes for two critical vulnerabilities, identified as CVE-2026-109618 and CVE-2026-109619, which may allow unauthenticated remote code execution under certain conditions. In practical terms, a flaw like this can open the door for an attacker to perform actions on the server without having a valid account.

What was fixed

The fixes were released in PHP versions 8.5.12, 8.4.27, 8.3.36, and 8.2.35. According to the official announcement, both issues are related to internal data and memory handling during request processing. One can be triggered when a memory allocation failure interrupts request data initialization; the other involves internal state that may remain accessible after the associated memory has been freed.

The potential impact is serious: an exposed PHP process may become vulnerable to remote code execution. The project’s recommendation is straightforward: updating is the only complete solution. Temporary measures can reduce specific exposure paths, but they do not make a vulnerable installation safe.

Why updating PHP is so important

PHP is used in web applications, online stores, admin panels, and custom-built systems. When the interpreter is outdated, the application may keep working normally while still missing the fixes already provided by the community. This increases operational risk, especially in internet-connected environments.

Keeping PHP on a version that still receives security updates is therefore essential. The official lifecycle states that each branch receives active support initially and then an additional period focused on critical security fixes. At the end of that cycle, the version reaches end of life and stops receiving patches. In that situation, new vulnerabilities may remain without an official fix.

Which versions need attention

As of the date of this publication, the 8.2, 8.3, 8.4, and 8.5 branches are listed as supported by the PHP project, with different schedules. The 8.2 branch is expected to end security support on December 31, 2026; the 8.3, 8.4, and 8.5 branches have later deadlines. This does not mean any version within a branch is protected: you must install the maintenance release that includes the fixes or confirm with your operating system vendor whether it applies backported patches.

Customers using PHP 7.4, 8.0, or 8.1 should treat migration as a priority. These branches are no longer part of regular support. The project provided minimal backports for this specific case, but they are intended for those compiling from source and do not replace an upgrade plan to a supported version.

How to act safely

The first step is to identify the version actually used in production, not just the version configured in the control panel. Next, validate site compatibility in a test environment and schedule the update to the fixed release. Back up, check extensions, themes, frameworks, and integrations, and monitor logs after the change.

For managed services, it’s worth opening a request with your provider to confirm which version is active and what the patching policy is. A routine of inventory, testing, and updating reduces exposure time and prevents security from depending on emergency interventions.

Conclusion

Updating PHP isn’t just technical maintenance: it’s a protective measure for the business, data, and site availability. Given the critical vulnerabilities that were fixed, the guidance is to review your environments now and keep each application on a version that receives security updates.

Source consulted: https://www.php.net/releases/8_4_27.php

MasterDaWeb Blog

1 article found

Critical PHP vulnerabilities: why you should update now

1 article found

Critical PHP vulnerabilities: why you should update now