PHP is an invisible component of much of the modern Web.

Visitors generally do not install it, interact with it directly or even know when a website depends on it.

Nevertheless, the language powers millions of websites and web applications, from smaller business sites to large online services.

When a security vulnerability affects the PHP runtime itself, the implications extend far beyond one application or content management system.

Since October 20, PHP maintainers and national cybersecurity agencies have been responding to two critical flaws.

Emergency releases were published on October 21.

On October 23, the PHP team disclosed a third vulnerability, while CERT-EU and the Dutch National Cyber Security Centre updated their advice.

TechCrunch also examined the crisis in an Equity podcast episode describing PHP's Black October.

The situation remains serious, but the latest information provides a more precise picture of the different vulnerabilities and their practical implications.

Two critical vulnerabilities in the PHP runtime

The original vulnerabilities are tracked as CVE-2026-109618 and CVE-2026-109619.

Both have a CVSS v4.0 severity score of 9.2.

They involve PHP's internal behavior rather than a programming mistake exclusive to WordPress or another application.

Under exploitable conditions, the vulnerabilities can allow an unauthenticated remote attacker to execute code on an affected server.

That possibility explains the urgency surrounding the disclosure.

Code execution in the context of a PHP worker may allow an attacker to interact with resources accessible to that process.

The eventual impact depends on system permissions, isolation mechanisms and other defensive controls.

Remote code execution does not automatically grant unlimited administrative privileges.

It nevertheless represents a serious breach of a fundamental security boundary.

CVE-2026-109618: memory limits become an attack surface

The first vulnerability involves PHP's handling of out-of-memory conditions.

PHP allows administrators to limit the amount of memory available when processing a request.

When a request exceeds that limit, the runtime may interrupt execution.

The discovered weakness concerns interruptions that occur while internal structures are only partially initialized.

Subsequent cleanup operations may then treat invalid or incomplete data as legitimate.

That behavior can result in memory corruption.

The PHP security advisory explains that the problem can arise during the processing of certain incoming request data.

It is not limited to applications that explicitly invoke a dangerous PHP function.

The flaw exists within the runtime and may be reached before the application's main code executes.

That is why the official guidance addresses exposed PHP installations broadly rather than a single framework or library.

CVE-2026-109619: stale internal state crosses request boundaries

The second critical vulnerability also involves memory safety, but through a different mechanism.

Internal state associated with one request can remain accessible after its underlying memory has been released.

A later request handled by the same worker may interact with that stale state before normal initialization restores the expected conditions.

This is described as stale global state.

The problem may occur after fatal errors or unusual interruptions disrupt ordinary processing.

Like the first flaw, successful exploitation can lead to remote code execution.

However, the two vulnerabilities are not technically identical.

Their different mechanisms also explain why temporary mitigations target different runtime behaviors.

Which PHP versions contain the fixes?

The PHP project released four security updates on October 21, 2026.

PHP 8.5 users should run version 8.5.12 or later.

PHP 8.4 users should update to version 8.4.27 or later.

For PHP 8.3, the corrected release is 8.3.36.

For PHP 8.2, the corrected release is 8.2.35.

These versions address the two critical vulnerabilities disclosed earlier in the week.

Older versions require special attention.

PHP 8.1 and earlier branches no longer receive regular security updates from the PHP project.

Some Linux distributions and long-term support vendors provide backported fixes.

The PHP team also released minimal source-code backports for PHP 7.4, PHP 8.0 and PHP 8.1 because of the exceptional severity.

These measures do not restore full regular support to obsolete branches.

Administrators should consult their vendors for verified fixes and plan migration toward a supported PHP release.

A third vulnerability was disclosed on October 23

The newest issue is identified as CVE-2026-115560.

PHP disclosed it through an informational advisory published on Friday, October 23.

The flaw also presents a potential remote code execution risk, but only under an unusual configuration.

Several conditions must be satisfied.

An application must initially configure its session serialization handler as php_binary or php_serialize.

It must then change the handler to php during execution, before starting a session.

Session upload progress functionality must also remain enabled.

The maintainers consider this combination uncommon.

They have therefore chosen to address CVE-2026-115560 in the next regular bugfix release rather than issuing another emergency release.

This is a meaningful distinction from the previous vulnerabilities.

The original flaws prompted emergency updates on October 21.

The third has a documented temporary mitigation while the regular fix is prepared.

A targeted temporary measure for the new issue

For CVE-2026-115560, the PHP team advises disabling session.upload_progress.enabled until the next regular release.

This setting normally controls the collection of upload progress information through PHP sessions.

Disabling it removes a condition required by the vulnerable configuration described in the October 23 advisory.

The change should be applied through the PHP configuration used by the affected workers.

Those workers must be restarted for the change to take effect.

The project notes that administrators who already applied the same mitigation following the October 21 advisory do not need to repeat it.

However, this targeted protection must not be confused with a complete fix for the two original critical vulnerabilities.

The PHP maintainers explicitly warn that temporary mitigations do not make affected installations fully safe.

Updating remains the required response to CVE-2026-109618 and CVE-2026-109619.

Which web servers and applications are affected?

The original critical vulnerabilities concern PHP installations handling web requests.

The PHP project identifies PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed among the relevant environments.

Actual exposure depends on the PHP version, server configuration and applied security updates.

The maintainers consider mod_php a particularly high-risk configuration.

Researchers demonstrated an unauthenticated attack reaching the vulnerable behavior before application code execution.

This explains why a well-maintained content management system may still depend on a vulnerable PHP runtime.

Updating WordPress or Magento alone does not necessarily replace the need to update PHP.

Conversely, using WordPress does not automatically mean a website is vulnerable.

A hosting provider may already have installed the necessary PHP security fixes.

The assessment must focus on the actual runtime environment rather than the software name visible to website visitors.

Claims of widespread successful exploitation need qualification

The severity of the disclosure prompted exceptional precautions.

In the Netherlands, the National Cyber Security Centre temporarily took its own website offline.

Other organizations also suspended selected web services while assessing their exposure.

However, the October 23 update provides important context about exploitation.

The Dutch NCSC says practical exploitation of the two critical flaws appears more complex than initially expected.

It is aware of one report of possible exploitation abroad, but had not confirmed that the reported attack succeeded.

Proofs of concept and attempted exploitation are being discussed.

Their existence does not establish that large numbers of servers have been successfully compromised.

The vulnerabilities remain serious enough to justify urgent patching.

The accurate distinction is between confirmed exploitable flaws, reported attack activity and an unverified number of successful compromises.

Artificial intelligence contributed to vulnerability research

Another significant aspect of the incident concerns the tools used by security researchers.

Google Cloud says Wiz researchers participated in identifying and investigating the PHP vulnerabilities.

AI models, including Gemini 4 Argon, contributed to discovery, exploit analysis, detection work and patch validation.

OpenAI also described its involvement through the Patch the Planet initiative.

According to the company, Calif identified a critical flaw using GPT-5.6 Sol.

OpenAI says Wiz independently discovered and reported both original vulnerabilities.

Those overlapping contributions are important.

The findings should not be credited exclusively to one model or company.

PHP maintainers remained responsible for preparing and releasing the fixes.

Researchers, security companies and other organizations supported the coordinated response.

AI therefore acted as a research tool rather than a complete replacement for human engineering expertise.

Old code can hide difficult security problems

TechCrunch's discussion of PHP's Black October highlights that some underlying weaknesses involve software behavior that has existed for many years.

That is not unusual for mature programming languages.

A runtime maintained over decades accumulates compatibility requirements, features and complex interactions.

Rare execution paths can remain difficult to test even in actively maintained projects.

PHP's broad use increases the potential consequences of vulnerabilities found in its core.

Many different applications depend on the same underlying interpreter.

A vulnerability in that shared component can therefore affect a very large theoretical population of systems.

However, potential exposure is not equivalent to confirmed victim numbers.

The proportion of websites using PHP does not reveal how many installations remain unpatched or have actually been compromised.

The crisis also highlights open-source maintenance

PHP maintenance depends on a community of developers supported by several organizations and funding initiatives.

The PHP Foundation provides financial support to contributors working on language development and security.

In May 2026, it announced an Ecosystem Security Team intended to strengthen vulnerability handling and security tooling.

The initiative also supports maintainers across the open-source PHP ecosystem.

The October incidents demonstrate why that work matters.

When a critical flaw is discovered in a foundational technology, maintainers must analyze it, prepare a fix, coordinate disclosure and inform users.

The process continues after a new version is published.

Operating system vendors, hosting providers and application owners must integrate the patches into their own environments.

That process can take time, especially when legacy infrastructure is involved.

The incident is a reminder that free-to-use software still requires substantial resources to maintain securely.

What administrators should do now

The immediate priority is identifying systems that execute PHP.

Organizations should not limit the inventory to their most visible public websites.

Administrative interfaces, internal applications, network devices and bundled software may also rely on PHP.

Internet-facing systems should receive priority.

Administrators should verify the running PHP version and the availability of appropriate vendor patches.

For officially supported branches, the October 21 releases provide clear version references.

For distributions using backported security fixes, the displayed PHP version alone may not prove whether the vulnerability has been corrected.

Vendor security advisories should be consulted.

After deployment, affected services should be restarted and application functionality verified.

Security logs can also be reviewed for suspicious behavior, without treating every PHP error as proof of an attack.

Finally, administrators using session upload progress functionality should review the October 23 advisory concerning CVE-2026-115560.

What if an immediate upgrade is impossible?

CERT-EU and the UK National Cyber Security Centre recommend considering temporary isolation of exposed applications when security fixes cannot be installed promptly.

Restricting public access can reduce opportunities for remote attacks.

The PHP project also documents temporary measures involving memory handling, request limits and selected session functions.

These changes should not be applied without considering their operational effects.

Adjusting memory limits or upload handling may affect application behavior.

Most importantly, the PHP maintainers say these measures do not completely address the original critical vulnerabilities.

They are risk-reduction options while a proper update is prepared.

An exposed installation does not become fully secure simply because an administrator changes one configuration parameter.

October 23 changes the assessment, not the priority

The third vulnerability adds a new consideration to the incident, but does not change the core advice.

The two original critical flaws have security updates available since October 21.

The newly disclosed issue requires an unusual configuration and has a documented temporary mitigation pending a regular release.

Cybersecurity authorities also suggest exploitation may be more complex than feared, while maintaining their recommendation to patch without delay.

PHP's Black October should not be described as proof that the entire Web has been compromised.

It is a serious security event involving a runtime shared by a vast number of websites and applications.

The correct priorities remain straightforward: identify affected systems, install appropriate patches, examine unusual configurations and distinguish confirmed findings from speculation.

The broader lesson is that much of the Web depends on the security work performed by maintainers of software that ordinary users rarely notice.