Sanae Takaichi Sounds the Alarm Over the PHP Crisis—What Should Ordinary Users Do to Protect Themselves?
Source: Decrypt
Compiled by Odaily (@OdailyChina); Translator: Moni
Editor's Note: Two critical security vulnerabilities have recently been disclosed in PHP, both with a CVSS v4 score of 9.2. Attackers can execute malicious code on affected servers without logging in, and even take full control of servers. Finland, France, the Netherlands, and other countries have taken precautionary measures such as temporarily taking websites offline, and PHP officials have urgently released patched versions. The vulnerabilities affect multiple older PHP versions, and security agencies warn that large-scale attacks may erupt quickly once the patches are made public.
Last night, Japanese Prime Minister Sanae Takaichi posted an "urgent request requiring everyone's immediate response" on X, flagging PHP-related risks.
This article outlines the principles behind the vulnerabilities, the scope of impact, and the latest developments, and explains the measures website operators and ordinary crypto users should take. Compiled by Odaily.
If you've been online at all over the past two days, you've probably already seen this wave of internet panic: a critical vulnerability is threatening virtually every website on the planet—Finland announced the shutdown of government websites, the U.S. National Security Agency (NSA) advised all organizations using PHP to shut down their websites, and the Netherlands and France took the same measures.
However, this is not a cyberwar—it's two major security vulnerabilities exposed in PHP.
PHP is the backend software that runs on web servers. You can think of a server as a computer that stores website content and generates web pages based on user requests. According to WordPress security firm Wordfence, every WordPress website is backed by a server running PHP.
Incidentally, Wordfence's own website also went down.
Why are the PHP vulnerabilities so concerning? In practice, the flaws allow strangers to execute their own commands directly on a server without logging in. The security industry calls this class of vulnerability "Unauthenticated Remote Code Execution" (RCE).
In plainer terms, it means "someone else can now control your server for you."
If the server stores your account information, addresses, or order history, that data could also fall into attackers' hands. Web hosting provider GoDaddy warned that these vulnerabilities could be used to steal data and tamper with website pages, allowing attackers to execute their own code on affected servers over the internet, leading to data theft and even full server takeover.
What has PHP officially announced?
The PHP Foundation, the nonprofit organization that funds the development of the PHP language, has issued an alert:
The PHP security team gives advance notice: a security update is scheduled for release on Wednesday, October 21, 2026, at 14:00 UTC, containing two critical vulnerabilities, both with a CVSS v4 score of 9.2. PHP users are advised to prepare for the update in advance. If the relevant details are made public ahead of time, or if evidence emerges that the vulnerabilities are being actively exploited, the update may be released earlier.
The score of 9.2 comes from the Common Vulnerability Scoring System (CVSS), which rates the severity of vulnerabilities based on factors such as how easily they can be reached over the internet and how much damage they could cause. Scores range from 0 to 10, and anything 9.0 or above is classified as critical. So even without reaching a perfect 10, these two vulnerabilities are already extremely dangerous.
On Wednesday, PHP released patched versions a few minutes early—PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35—while confirming that the vulnerabilities affect PHP environments that process web requests, including PHP-FPM, Apache mod_php, php-cgi, FrankenPHP, and LiteSpeed. Apache mod_php is particularly at risk, as attacks can be triggered before application code even runs.
Yet the official security advisory was unequivocal: "All PHP users are strongly urged to update immediately."
But releasing a fix does not mean all users have already patched, so vigilance is still required.
How do these vulnerabilities work?
The first vulnerability, CVE-2026-109618, occurs when PHP runs out of memory while handling a request. Afterwards, PHP may treat data that has not been fully constructed as if it were complete.
The second vulnerability, CVE-2026-109619, causes residual data left behind by a visitor's request to remain in memory after it should have been cleared, allowing subsequent requests to be affected by that residual data.
You can think of this as a chef who keeps reading order slips that have already been thrown into the trash. If someone slips a forged menu into the trash, the chef will cook whatever is on it. In this case, the "menu" is the attacker's malicious code, and the server will execute it.
PHP said servers using mod_php, a common Apache configuration, are at the highest risk. Under this configuration, demonstrated attacks can execute "before any application code runs."
In other words, the website's own defenses, such as login pages and WordPress security plugins, haven't even had a chance to start up.
Researchers at the PHP Foundation noted that PHP's upload progress tracking feature is a confirmed attack vector. The feature, used to track file upload progress, has been enabled by default for over a decade, but very few websites actually use it.
Vulnerability details leaked, attacks followed
Information about these vulnerabilities was not supposed to be made public so early. In fact, someone posted on the Hacker News forum on Tuesday claiming that the two PHP vulnerabilities were originally scheduled for disclosure that Thursday, while admitting they had "no evidence other than 'source: trust me, bro.'"
As it turned out, the poster was right.
Security firm watchTowr confirmed that the two vulnerabilities were real and were still under embargo at the time—meaning parties had agreed not to disclose details until fixes were ready. PHP subsequently moved the update release forward by a day.
Cloudflare CTO Dane Knecht posted on X early Wednesday: "We are already seeing early attacks and are continuously updating mitigations as new attack paths emerge."
At the time of that post, the patch was still nearly six hours away from release.
Cloudflare promptly pushed emergency firewall rules to all customers, blocking known attack patterns through filters. However, Dane Knecht emphasized that these measures "can only serve as a temporary stopgap."
Governments hit the shutdown button
According to Finnish public broadcaster Yle, Finland's national IT center Valtori began taking public network services offline as a precaution. The Dutch national cybersecurity agency also shut down its own website.
In France, the Ministry of the Interior said provincial government websites had been "temporarily taken offline" until the publisher of the relevant framework released a security patch.
The EU's cyber emergency response team CERT-EU advised organizations unable to install patches immediately to "consider isolating internet-facing applications from public networks until fixes are available."
Subsequently, agencies in Australia, Japan, and the UK issued broadly similar advice.
In plain language: "pull the plug."
Some popular posts on X claimed that PHP has been vulnerable in "all versions since 2004."
That claim stems from early estimates that all versions from PHP 5 onward were affected. But CERT-EU acknowledged that the estimate was based on social media posts.
E-commerce security firm Sansec believes the affected range starts at PHP 5.4 and includes later versions. That means the vulnerabilities could date back to 2012, not 2004. Still, that covers some very old software versions.
PHP officially provides formal releases only for PHP 8.2 and newer. So the claim that "there is no fix for older versions" is partly true.
Given the severity of the vulnerabilities, the PHP security team also released stripped-down source code patches for PHP 7.4, 8.0, and 8.1. Linux distributions are also backporting the fixes into the versions they maintain.
Security firm Mallory counted approximately 884,000 internet-facing hosts publicly displaying PHP 8.1 or earlier as of October 20. These hosts account for about 59% of the 1.5 million hosts that publicly disclose version information.
Since a single shared host can serve many websites, the actual number of affected websites could be even higher.
Some online posts also lumped Node.js into the affected scope. Node.js is a different web technology that merely happened to schedule an unrelated security update on the same day. The timing collision caused confusion.
Even with patches released, it doesn't mean all servers will be updated immediately.
The PHP Foundation said in a statement: "If you rely on the volunteer-maintained https://rpms.remirepo.net, we strongly recommend switching now to your Linux distribution's official packages, or building from source yourself, so you can apply updates immediately. That package repository will not publish updates today."
The statement refers to a popular package source maintained by volunteers, aimed primarily at Red Hat-style Linux servers.
Should crypto users be worried?
Frankly, ordinary users don't need to panic right away, but they shouldn't dismiss it either.
For example, a compromised website doesn't need to directly attack a blockchain to get your wallet assets stolen.
In 2024, attackers redirected the front-end pages of DeFi protocols Compound and Celer to malicious pages, tricking users into connecting their wallets and stealing assets. In 2025, Curve Finance suffered a similar attack.
However, those incidents were DNS hijacking rather than PHP vulnerabilities, though the attack methods share similarities: the website looks normal, the URL is normal, but the "approve" button you click may send tokens to another address.
If a server is compromised, attackers can likewise serve users such a malicious page. When exploiting zero-day vulnerabilities, hackers are often quick to devise various attack methods.
Meanwhile, discovering such vulnerabilities is becoming easier. Advanced AI models are increasingly being used to find software vulnerabilities. In June, experts told Decrypt that more vulnerabilities may emerge in the future as these tools become more widespread.
What happens next? What should users do?
Should ordinary users panic?
Your phone, browser, and laptop don't all need PHP patches—the people who need to act are those running the websites you visit. If you operate a website, contact your hosting provider to confirm whether PHP has been updated. Don't assume WordPress will do it for you automatically: Wordfence has warned that automatic update mechanisms will not automatically apply this fix, and advises website owners to find out who is responsible for updating PHP on their servers.
If you're on PHP 8.2, the fix you just received may be one of your last: that version reaches end-of-life on December 31, 2026, after which it will no longer receive security patches. Additionally, users still on PHP 8.1 or earlier need to plan an upgrade.
The PHP Foundation's publication of patches helps to some extent, but the problem is that once patches are public, attackers can compare the code before and after the fix to pinpoint exactly what was fixed. The forensics team at security firm Sansec said it expects "large-scale attacks to begin within 15 minutes of the patch release."
In June 2024, after another PHP vulnerability was disclosed, Akamai detected exploitation attempts against its honeypot servers within 24 hours.
As PHP core developer Gina Peter Banyard said on Mastodon: "The only thing I can say is that the only mitigation is to install the patch or upgrade PHP. Unfortunately, I know too much."
