PHP released versions 8.5.12, 8.4.27, 8.3.36, and 8.2.35 on October 21 to address CVE-2026-109618 and CVE-2026-109619, two vulnerabilities rated 9.2 out of 10 that allow unauthenticated remote code execution.

The vulnerabilities prompted Finland, the Netherlands, and France to take government websites offline as a precaution after details emerged ahead of schedule. Cloudflare also reported attacks several hours before the patch was released. The U.S. National Security Agency recommended that organizations using PHP shut down their sites, while agencies in Australia, Japan, and the U.K. issued similar guidance.

Most internet users do not need to install anything. The responsibility for applying the fix rests with website operators, hosting companies, and organizations that maintain PHP servers. PHP 8.1 and older do not receive regular official releases, although the PHP security team published limited source-code patches for some older versions because of the severity of the issue.

PHP runs about 70% of websites whose server-side language is known, according to W3Techs. The programming language operates on servers, where it helps store websites and generate the pages requested by visitors. WordPress sites, for example, commonly rely on PHP servers, according to WordPress security firm Wordfence.

The two bugs can allow an attacker to execute commands on a PHP server without logging in. This type of flaw is known as unauthenticated remote code execution. Depending on the server and the data it stores, a successful attack could expose account information, addresses, order histories, or other sensitive material.

Web host GoDaddy warned that the vulnerabilities could allow attackers to steal data, deface websites, or take complete control of affected servers.

“A flaw like this could let an attacker run their own code on an affected server over the internet, which can lead to stolen data, a defaced site, or a full takeover,” GoDaddy said in its security update.

PHP’s security announcement

The PHP Foundation, the nonprofit that funds development of the language, issued an advance warning on October 20. In a statement shared on X, it said:

“The PHP security team is giving advance notice: Upcoming security release Wed, Oct 21st 2026, 14:00UTC, two critical vulnerabilities, both rated CVSSv4 9.2. PHP users are encouraged to prepare to update. Earlier release if details become public or active exploit evidence.”

The PHP security team is giving advance notice: Upcoming security release Wed, Oct 21st 2026, 14:00UTC, two critical vulnerabilities, both rated CVSSv4 9.2. PHP users are encouraged to prepare to update. Earlier release if details become public or active exploit evidence. — The PHP Foundation (@ThePHPF) October 20, 2026

The Common Vulnerability Scoring System, or CVSS, rates vulnerabilities from 0 to 10 based on factors including how easily they can be exploited over the internet and the potential impact. Scores of 9.0 or higher are classified as critical.

PHP released the fix at approximately 13:35 UTC on October 21, about 25 minutes before the announced time. The security advisory said: “All PHP users are strongly encouraged to update immediately.” The release was moved forward by one day after information about the vulnerabilities began circulating publicly and evidence of attacks emerged.

How the vulnerabilities work

CVE-2026-109618 occurs when PHP runs out of memory while processing a request and later treats partially constructed data as complete. CVE-2026-109619 allows remnants of one visitor’s request to remain in memory after they should have been discarded, enabling a subsequent request to interact with those remnants.

The risk is highest on servers using mod_php, a common Apache configuration. PHP said a demonstrated exploit works “before any application code runs,” meaning defenses implemented by the website itself—such as login screens and WordPress security plugins—may not have an opportunity to intervene.

Researchers at the PHP Foundation identified PHP’s upload-progress feature as one confirmed path into the vulnerability. The feature tracks the progress of a file upload, has been enabled by default for more than a decade, and is not used by many websites.

Further technical information is available in the PHP security archive, the watchTowr analysis, and the NVD entry for CVE-2026-109619. PHP’s documentation also describes the relevant session configuration.

Details leaked before the patch

The disclosure was not initially expected to occur before the scheduled release. On Tuesday, a user posted on the Hacker News forum that two PHP vulnerabilities would be disclosed on Thursday, while acknowledging that the claim had “no evidence beyond ‘source: trust me, bro.’” The post is available here.

Security firm watchTowr later confirmed that the vulnerabilities were real and covered by an embargo, an agreement intended to keep technical details confidential until a fix was ready. PHP then accelerated the release.

Cloudflare CTO Dane Knecht said on X early Wednesday that attacks had already begun, nearly six hours before the patch was released. Cloudflare deployed emergency web application firewall rules to its customers, including customers on free plans, but Knecht described the rules as only a temporary measure.

“PHP sites behind Cloudflare already have an initial set of WAF rules deployed for the known exploit vectors in these vulnerabilities. The rules are available to all customers, including free. We are seeing early attacks emerging and are updating mitigations as new vectors show… — Dane Knecht 🦭 (@dok2001) October 21, 2026”

The original post is also available from Dane Knecht’s X account.

Governments take websites offline

Finland’s state IT center, Valtori, began taking public web services offline as a precaution, according to public broadcaster Yle. The Netherlands’ national cybersecurity agency also took down its website.

France’s Interior Ministry said that prefecture websites had been “temporarily taken offline pending the release of a security patch by the framework’s publisher.”

The European Union’s cybersecurity emergency team, CERT-EU, told organizations that could not apply the patch to “consider isolating internet-facing applications from public networks until a fix is available.”

Reuters reported that agencies in Australia, Japan, and the U.K. issued similar guidance. The Reuters report also said that websites could need to be taken offline while operators prepared to install the fixes.

Claims about affected PHP versions

Posts circulating on X claimed that PHP versions dating back to 2004 were vulnerable. That claim came from early estimates that every version since PHP 5 was affected, an assessment that CERT-EU said was based on social media posts.

E-commerce security firm Sansec estimated that PHP 5.4 and later were affected, which would extend the range back to 2012 rather than 2004. PHP officially provides current releases only for versions 8.2 and newer. However, because of the severity of these vulnerabilities, the security team also published basic source-code patches for PHP 7.4, 8.0, and 8.1, while Linux distributions began backporting fixes independently.

Security firm Mallory counted approximately 884,000 internet-facing hosts advertising PHP 8.1 or older on October 20. That represented 59% of the roughly 1.5 million publicly visible hosts that identified their PHP version. The number of affected websites is higher because a single shared-hosting server can support many sites. Mallory’s research is available here, while Sansec’s analysis is available here.

Some online posts also included Node.js in the discussion. Node.js is a separate web technology that happened to have its own unrelated security update scheduled for the same day.

The PHP Foundation warned that patched versions would not become available everywhere at the same time. It said: “If you rely on the volunteer maintained we urge you to move to distro packages or building from source now, so you can immediately apply updates. The repo will not have updates today,” referring to a volunteer-run source of PHP packages for Red Hat-style Linux servers. The package repository is available at

Potential impact on websites and digital assets

A compromised website does not need to interact directly with a blockchain to put users’ digital assets at risk. In 2024, attackers redirected the front ends of DeFi protocols Compound and Celer to pages designed to drain connected wallets. Curve Finance suffered a similar attack in 2025. Those incidents involved DNS hijacking rather than PHP vulnerabilities, but the result can look similar to a visitor: the website and URL appear legitimate while an approval action sends tokens elsewhere.

A compromised PHP server could be used to serve a fraudulent page of that kind. The relationship between vulnerable web infrastructure and cryptocurrency theft was also discussed by entrepreneur @levelsio, who said on X that he had disconnected his sites and virtual private servers while waiting for the patch.

“I pre-emptively disconnected ALL my sites / VPS servers from the web I'll wait for the patch to hit at 2 PM UTC If you have a PHP website, probably good to take them down until you patch PHP 69.3% of the web runs on PHP so this is going to be intense! Good time maybe to buy… — @levelsio (@levelsio) October 21, 2026”

The post is also available on X. The earlier Decrypt reports on the Compound and Celer incident and the Curve attack are available here and here.

The vulnerabilities also come as frontier artificial intelligence models are increasingly being used to identify software flaws. Experts told Decrypt in June that the spread of such tools could lead to the discovery of many more vulnerabilities. Decrypt’s report is available here.

What website operators should do

Once a patch becomes public, attackers can compare the vulnerable and patched code to determine what changed. Sansec’s forensic team said it expected “mass attacks to start within 15 minutes of the release.” When another PHP vulnerability was disclosed in June 2024, Akamai recorded exploit attempts against its decoy servers within 24 hours. Akamai’s analysis is available here.

Phones, browsers, and personal laptops do not need a PHP update. The work falls to the organizations that operate websites and servers. Website owners should ask their hosting providers whether PHP has been updated and identify who is responsible for maintaining the server.

Wordfence warned that WordPress automatic updates would not apply this fix. Site owners therefore need to confirm that PHP itself has been patched rather than assuming that updating WordPress will address the issue.

PHP core developer Gina Peter Banyard said on Mastodon: “The only thing I can say is that the only mitigation is patching / upgrading PHP,” adding, “I sadly know too much.” The post is available here.

Organizations running PHP 8.1 or older need to plan an upgrade because those versions do not receive regular official releases. PHP 8.2 users also face an approaching deadline: PHP 8.2 reaches end of life on December 31, 2026, after which it will no longer receive security patches.