Critical PHP Vulnerabilities: Who Is Affected, What Could Happen, and How to Patch Safely

TechiesJournal illustration of the idea in the article. Both stacks run an up-to-date application. Only the right-hand PHP layer has the fix, so only it stops the request.

Two critical security vulnerabilities in PHP have exposed websites and applications to possible remote code execution and sensitive-data disclosure. Security researchers have demonstrated exploitation, and active attacks have been observed. Here is what organizations need to understand before updating their systems.

A patched application can still run on a vulnerable runtime

Imagine your organization runs a customer website built on WordPress. Its plugins are current, access controls are enabled, and the development team regularly fixes security weaknesses in the application. Yet the website could still be exposed to an attack that bypasses these precautions.

The problem may not be in WordPress at all. It may exist in PHP, the software that runs the application and processes incoming web requests.

On October 21, 2026, the PHP project announced emergency security updates for two critical vulnerabilities. They show why application security must extend beyond application code. The vulnerabilities, collectively known as PHP2Shell, can allow unauthenticated remote code execution, which means an attacker with no login can run code on the server from the internet, or exposure of sensitive information from PHP process memory.

Two critical flaws sit in PHP itself

The vulnerabilities are tracked as:

• CVE-2026-109618: A memory-corruption problem associated with PHP’s handling of out-of-memory errors.
• CVE-2026-109619: A problem in which internal state from a previous request can remain accessible after its memory has been released.

Both are rated critical, with a CVSS 4.0 score of 9.2 out of 10 (CVSS is the standard severity rating for vulnerabilities) in the PHP security team’s pre-announcement.

In ordinary operation, PHP allocates memory while processing a request and releases it when that memory is no longer needed. These vulnerabilities concern situations in which PHP can attempt to use internal data that has not been safely initialized or that no longer belongs to valid memory. Under certain conditions, specially constructed web requests can trigger these weaknesses.

An attacker who successfully exploits them may execute code using the privileges of the PHP worker process, access sensitive process memory, or disrupt the application. These are vulnerabilities in PHP itself, so an application may be affected even when its own source code contains no corresponding security defect.

Several research teams found the flaws and PHP maintainers fixed them

The discovery involved multiple independent and collaborative security research efforts. Wiz Research publicly identifies Sagi Tzadik, Shir Tamari, Nir Ohfeld and Tomer Schwartz among its researchers. Its published disclosure timeline states that its team discovered the first vulnerability on August 19, 2026, verified remote code execution against Drupal and WordPress over the following days, and reported the findings to PHP maintainers on August 24.

Calif independently identified a critical PHP flaw as part of OpenAI’s Patch the Planet security initiative, using GPT-5.6 Sol. OpenAI’s coordinated disclosure report also credits Wiz with independently discovering and reporting both vulnerabilities. The disclosure additionally involved researchers and security providers, including Cloudflare and Quarkslab, and the PHP2Shell research website credits OpenAI’s Amy Burnett and Calif’s Ryan A. The PHP maintainers led the actual security fixes and releases.

AI tools played a documented role in the investigation. Wiz reports using Wiz Atlas, Gemini 4 Argon and GPT-5.6 Sol. The evidence supports describing AI-assisted security research, rather than suggesting that an autonomous AI system independently discovered, validated and repaired all the vulnerabilities.

The sequence also illustrates why coordinated disclosure matters. Researchers needed time to work with maintainers and security providers before releasing technical details that attackers could potentially use.

The affected systems run an unpatched PHP runtime

PHP is used by a substantial portion of the web. Common PHP-based software includes WordPress, Drupal, Joomla, Moodle, MediaWiki, Nextcloud and applications built with Laravel or Symfony. That does not mean every installation of those products is vulnerable. The relevant question is whether the deployed system uses an affected PHP runtime and whether an applicable security fix has been installed.

Wiz Research demonstrated remote code execution in controlled environments running WordPress, Drupal and Joomla. These demonstrations establish credible exploitability in representative deployments, but they are not evidence that the organizations behind those products were compromised.

The PHP security announcement lists the affected web-serving environments as Apache mod_php (PHP running inside the Apache web server), PHP-FPM, php-cgi, FrankenPHP and LiteSpeed. The PHP team considers the risk highest for mod_php, because the attack path can be triggered before any application code runs. The vulnerabilities can also affect custom business applications, cloud-hosted systems, container images and products that bundle PHP internally.

Patched PHP versions

The first fixed upstream PHP release for each branch

PHP branch	First fixed upstream release
PHP 8.5	8.5.12
PHP 8.4	8.4.27
PHP 8.3	8.3.36
PHP 8.2	8.2.35
PHP 8.1 and older	No regular upstream security release, so check vendor backports or migrate

The table lists the first fixed release for each branch, as given in the PHP announcement and the Canadian Cyber Centre alert. Older releases also contain affected code. Wiz states that every PHP version released in the last decade is affected by at least one of the flaws, and Cloudflare describes the issue as affecting web servers running PHP 5.4 or later.

Certain Linux distributions and long-term-support providers may backport the necessary fixes without changing the visible upstream PHP version number. Administrators should therefore confirm patch status through their software provider rather than relying entirely on php -v. For PHP 7.4, 8.0 and 8.1, the PHP security team also provided minimal source backports for people building from source or without access to a long-term-support vendor. According to the PHP announcement, PHP 8.2 reaches upstream end of life on December 31, 2026, so organizations updating that branch should also plan a supported-version migration.

Attackers were probing PHP2Shell before the patches shipped

There is documented evidence of active attempts, including activity before the vulnerabilities were publicly disclosed. Amazon Threat Intelligence reported detecting a PHP2Shell exploitation attempt against its MadPot honeypot infrastructure on October 17, 2026, four days before the public disclosure. On October 21, AWS observed additional attempts with different payloads and infrastructure, and stated that PHP2Shell was being broadly exploited in the wild. AWS also noted that technical analysis was ongoing and that it was unclear whether any of the attempts would have succeeded against real systems.

Cloudflare also reported attack traffic targeting its customers during the disclosure period. It described how attackers changed their payloads in attempts to bypass its newly deployed protections. These are important findings because they show that the threat is not limited to a laboratory proof of concept.

Reports differ on timing. The Canadian Cyber Centre alert of October 21 said that no active exploitation had been identified at that time, but that this could change quickly, while AWS and Cloudflare reported attack traffic. There is still a distinction between detecting an exploit attempt and confirming that an organization’s production systems were compromised. At the time of this source review, the public reports examined did not establish a verified list of named organizations successfully compromised through these vulnerabilities. The appropriate conclusion is that active attacks have been observed, while the number and identity of successfully compromised organizations remain uncertain. Organizations should not use the absence of a published victim list as evidence that their systems are safe.

Successful exploitation could reach well beyond the web server

The consequences depend on the vulnerable configuration, the attack path and the privileges available to the PHP process. Successful exploitation can have several consequences.

Unauthorized code execution. An attacker may execute commands as the account running PHP. Depending on that account’s permissions, this could allow modification of website files, installation of malicious code, or access to connected systems.

Sensitive-memory disclosure. PHP process memory may contain authentication tokens, passwords, API keys or information from other requests. Some attack paths can expose memory without first achieving general remote code execution.

Website disruption. Memory corruption or deliberate exhaustion can cause workers to fail, interrupt processing or reduce service availability.

Data exposure and further compromise. If an attacker gains access to database credentials, application secrets or privileged integrations, the consequences may extend beyond the original web server.

These are potential outcomes, not evidence that every affected installation has suffered them. The actual damage depends on configuration, permissions, network access and successful exploitation.

The right patch source depends on how PHP was installed

For PHP installations managed directly, official releases and installation information are available from the PHP downloads page, the PHP 8 changelog and, for Windows, windows.php.net. For Linux servers, administrators should normally obtain security updates through their operating-system distribution or the trusted PHP package provider already maintaining the installation.

For containerized systems, teams should select an updated official or vendor-supported base image, rebuild the application image and deploy the corrected runtime. For managed hosting, shared hosting or SaaS environments, the provider may control the update, so customers should obtain confirmation that the affected PHP runtime has been patched.

Do not download unofficial patch binaries simply because they claim to resolve PHP2Shell. Verify the source, release information and package integrity.

A safe update starts with an inventory

The remediation process should start with an inventory rather than an immediate, unverified production change. First, identify where PHP runs, including public websites, APIs, internal applications, application containers, virtual machines, web-hosting panels and third-party appliances. Next, determine the installed PHP version, the vendor providing it and whether the necessary security fix is included.

Prioritize internet-facing systems. The PHP security team lists settings that reduce exposure to specific attack paths, but says they do not make an installation safe and that only an update is a complete solution. Installing a corrected runtime is therefore the required remedy. Before modifying production systems, preserve necessary configurations, take verified backups and record the existing deployment state.

Apply the updated packages or deploy new container images through the appropriate management process. Restart or replace PHP worker processes so the corrected code is actually running. Finally, verify the PHP version or vendor patch status from the operational environment, confirm the application works, and investigate relevant logs for signs of exploitation.

An updated package on disk is not sufficient if the running service still uses the old PHP process.

Same-branch updates carry the lowest compatibility risk

For an application already using a supported PHP branch, applying the corrected patch release within that same branch will generally present less compatibility risk than moving immediately to a newer major or minor PHP version. Lower risk does not mean zero risk. The security releases contain changes to PHP’s internal runtime behavior, and release changelogs may include additional bug fixes. Applications that depend on particular extensions, legacy functionality or unusual runtime behavior may require testing.

Administrators should check several areas before declaring the update successful.

Application functionality. Verify login, authentication, important business transactions, API endpoints, file uploads, background jobs and database interactions.

PHP extensions. Confirm that extensions such as database drivers, caching modules, image-processing libraries and third-party binary modules remain available and compatible.

Sessions and request processing. Because the vulnerabilities involve request-related state, test session behavior, file uploads and request handling in applications that rely heavily on them.

Containers and infrastructure. Confirm that rebuilt images include the corrected PHP version and that deployed services actually use those images.

Performance and stability. Watch application errors, PHP worker crashes, memory usage, latency and service availability after deployment.

Production changes should follow a controlled deployment or maintenance procedure with monitoring and a recovery plan. If the application fails after updating, rolling back to an affected runtime and exposing it publicly is not a safe permanent solution. The team should instead resolve the compatibility problem, use a supported vendor-fixed package or isolate the system while remediation continues.

No credible evidence from the reviewed sources establishes that these particular PHP security releases generally cause application failures or substantial performance degradation across existing deployments. Any specific regression claim should be supported by release notes, reproducible testing or a documented vendor incident.

A patch closes the hole but does not remove an existing compromise

A security update closes the affected vulnerability path. It does not automatically remove malicious files, undo unauthorized changes, revoke stolen credentials or establish that earlier activity was harmless. Because exploitation attempts were observed before public disclosure, organizations with previously exposed systems should review their security evidence. AWS advises starting such investigations from at least October 17 rather than from the disclosure date. TechiesJournal’s related article, “Patched” Is Not “Clean”, covers the recovery problem in more depth.

Security teams can investigate unusual PHP memory errors, abnormal worker exits, unexpected child processes, modified application files, suspicious outbound connections and unusual HTTP requests. An alert or suspicious request alone is not proof of compromise, so findings should be investigated in context and correlated with other available evidence.

Where compromise is established or reasonably suspected, the response may require isolation, evidence preservation, credential rotation, rebuilding affected systems and an incident investigation.

Firewall and CDN rules reduce exposure but do not replace the patch

Security providers such as Cloudflare deployed protections against known PHP2Shell attack patterns. Cloudflare states that its free and paid web application firewall (WAF) customers were protected by default from 3:02 a.m. UTC on October 21, about nine hours before the public disclosure. These protections can help reduce exposure while organizations install the necessary updates.

However, WAF rules do not guarantee that every possible exploit path is blocked. Attackers may modify requests, discover alternative techniques or reach systems through routes that bypass the protection layer, and Cloudflare itself observed attackers changing payloads. For this reason, firewall rules should be treated as additional defensive controls, not replacements for fixing the PHP runtime.

The lesson reaches beyond PHP

PHP2Shell illustrates a security problem that extends beyond PHP. Modern applications depend on software layers that development teams may not directly maintain. An application can follow sound security practices while depending on a vulnerable runtime, operating system, library or hosting component. That creates responsibilities across development, operations, infrastructure and security teams.

Organizations need to know what software is running, where it came from, who maintains it, and how rapidly a verified security update can reach production. For PHP2Shell, the immediate priorities are to identify affected systems, install verified fixes, confirm the corrected runtime is operating and investigate potential compromise.

The broader lesson is that securing application code is essential, but it does not replace securing the software that executes it.

Go deeper

Research reviewed October 22, 2026. Threat activity, patch availability and vendor guidance can change quickly, so check the primary sources before acting.

Vendor, government and research sources

• PHP Security Team, official security announcement, October 21, 2026, the source for the security fixes, affected runtime environments and official update guidance.
• Canadian Centre for Cyber Security, AL26-026, October 21, 2026, Canadian government assessment and recommended actions.
• Wiz Research, PHP2Shell investigation, October 21, 2026, discovery history, technical research and controlled demonstrations.
• OpenAI, coordinated disclosure of critical vulnerabilities, October 21, 2026, independent discovery, AI-assisted research and response coordination.
• PHP2Shell, joint research resource, research credits, technical overview and demonstration scope.

Observed attacks and protections

• AWS Security Blog, early exploitation attempts, October 21, 2026, evidence of observed attacks, including activity before disclosure.
• Cloudflare, PHP2Shell mitigations, October 21, 2026, observed malicious traffic and the deployment of protective controls.

Getting the fix

• PHP downloads and installation, official download and installation resources.
• PHP 8 changelog, detailed release changes for compatibility and regression review.

Organizations assessing possible exposure should consult current vendor advisories and their own incident-response procedures. The public reports reviewed do not establish that every installation was compromised.

Related reading on TechiesJournal

• “Patched” Is Not “Clean”: What to Do After an Exploited Edge Device Fix, TechiesJournal, October 2026, why fixing a vulnerability does not automatically remove an existing compromise.
• When a Trusted Cloud Application Becomes an Attack Path for another case where a trusted component, rather than the defenders’ own code, became the way in.