Two Critical PHP Vulnerabilities Put Websites Worldwide at Risk

Two critical security flaws in PHP could allow attackers to execute malicious code remotely on a web server without authentication. The vulnerabilities, both rated 9.2 out of 10 on the CVSS scale, affect one of the most widely used technologies powering websites and web applications. PHP developers therefore released emergency security updates on October 21, 2026. Organizations should deploy these patches as soon as possible and investigate whether their systems may already have been compromised.

PHP underpins numerous corporate websites, e-commerce platforms, customer portals, and internal applications. It is also used by popular content management systems such as WordPress, Drupal, and Joomla. A security flaw in PHP itself therefore poses a particularly serious risk, potentially affecting even applications whose own source code contains no known vulnerabilities.

The latest security issue involves two vulnerabilities identified as CVE-2026-109618 and CVE-2026-109619. Both stem from improper memory management during request processing and, under certain conditions, could allow remote code execution (RCE).

A successful attack could result in unauthorized server access, modification of application files, or exposure of sensitive information. The extent of the damage also depends on the privileges of the PHP process and the security of the surrounding infrastructure.

How Do the Two Critical PHP Vulnerabilities Work?

Although both flaws can lead to similar outcomes, their underlying technical causes differ. What they share is improper handling of memory and PHP's internal state when processing web requests.

CVE-2026-109618: Out-of-Memory Handling Flaw

The first vulnerability occurs when PHP runs out of available memory while processing a request, a condition known as Out of Memory (OOM).

PHP uses a mechanism that allows it to interrupt the current operation in such situations. However, some internal operations may not properly account for this abrupt termination, potentially leaving memory in an uninitialized or inconsistent state.

During subsequent cleanup, PHP may handle this memory incorrectly. An attacker capable of deliberately triggering the necessary conditions could exploit the flaw to corrupt process memory and, under certain circumstances, achieve remote code execution.

CVE-2026-109619: Access to Previously Freed Memory

The second vulnerability affects PHP's internal global data, which may temporarily reference memory associated with a particular request.

If these references are not properly cleared, they may persist even after the corresponding memory has been freed. When processing a subsequent request, PHP may then attempt to access memory that is no longer valid.

This type of vulnerability is known as Use-After-Free. Successful exploitation could disrupt the process and, under certain conditions, allow an attacker to execute arbitrary code.

Both vulnerabilities received a CVSS v4.0 score of 9.2, indicating critical severity. Their exploitability depends on the specific configuration and conditions, but the potential consequences are serious enough for PHP developers to recommend immediate updates.

Which Websites and Servers Are Affected?

The risk is not limited to a particular content management system or framework. Because the vulnerabilities exist within PHP itself, various web applications may be affected, whether they are public websites, online stores, customer portals, or internal information systems.

Affected environments include PHP installations that process web requests, such as PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, and LiteSpeed.

However, this does not mean every installation is equally vulnerable to attack. The actual risk depends on the PHP version, server configuration, and whether the conditions required to exploit the flaw can be triggered.

Which PHP Versions Include Security Fixes?

PHP developers released the following patched versions on October 21, 2026:

Organizations using older, unsupported PHP versions should consider migrating to a supported branch. Some vendors provide security backports for older versions, but their availability must be verified with the relevant provider.

It is also important to review products that include PHP as part of their software. These may include administration interfaces, network devices, and other systems where security fixes are delivered through vendor-specific updates.

Have Exploitation Attempts Already Been Observed?

In an advisory published on October 22, 2026, New Zealand's National Cyber Security Centre (NCSC) reported receiving information about active exploitation of the vulnerabilities.

Security researchers have also demonstrated how the flaws could be exploited to achieve remote code execution. However, publicly available information does not yet provide a reliable picture of the overall extent of successful compromises.

Organizations should therefore not treat this issue as a purely theoretical threat. The availability of technical information about the vulnerabilities could make it easier for attackers to develop further exploits, while unpatched servers remain potential targets.

Simply monitoring security advisories is not enough. What matters is how quickly an organization can identify vulnerable systems, deploy patches, and investigate any potential signs of compromise.

What Should Organizations Do Immediately?

Updating PHP is the highest priority. PHP developers have warned that there are no complete workarounds that can reliably eliminate the risk without applying the security fixes.

IT and security teams should take several steps.

Identify all systems running PHP. The assessment should cover public websites, e-commerce platforms, internal applications, administration interfaces, testing environments, and products operated by third-party providers. Particular attention should be paid to legacy applications that may fall outside regular patch management processes.

Deploy security patches without delay. PHP should be upgraded to a patched version or a distribution package containing the relevant security fixes. Teams should then verify that the updated version is actually running. Depending on the environment, restarting PHP processes or related services may be necessary.

Investigate potential indicators of compromise. Particular attention should be paid to unusual HTTP requests, recurring out-of-memory errors, unexpected PHP process crashes, suspicious file modifications, and unknown processes running on the server. These events do not necessarily confirm an attack, but they may warrant further investigation.

Assess the security of the surrounding infrastructure. Even after a specific vulnerability has been fixed, other weaknesses may remain. These could include misconfigured access permissions, vulnerable application components, insufficiently protected APIs, or server configuration errors.

If there is reason to suspect that an attacker has already exploited the vulnerability, the organization should follow its established incident response procedures.

Updating PHP Is the First Step. What Comes Next?

Applying security patches removes known vulnerabilities, but security verification should not end there. If an attacker exploited the flaw before the update, they may have gained access to the server, modified files, or established a mechanism for persistent access. In such cases, the extent of the compromise must be investigated and its consequences remediated.

The overall resilience of the web application is a separate concern. Even after updating PHP, attackers may still exploit authentication weaknesses, insufficiently secured APIs, server misconfigurations, or vulnerabilities in other components.

This is where penetration testing plays an important role. Security specialists assess applications and infrastructure from an attacker's perspective, verify whether identified weaknesses can actually be exploited, and evaluate their potential impact on the organization.

The critical PHP vulnerabilities are another reminder that security cannot depend on a single update. It requires continuous oversight of deployed technologies, timely vulnerability remediation, and regular validation of security controls.