Two critical PHP security flaws have triggered emergency responses across multiple countries, with some government and public-facing websites temporarily taken offline while patches were being prepared or deployed. According to the PHP Foundation, both vulnerabilities carry CVSS v4 scores of 9.2 and can let attackers execute code on affected servers without authentication.
The report, translated by Odaily from Decrypt, said Japanese Prime Minister Sanae Takaichi posted an urgent message on X calling for immediate attention to the PHP-related risk. The incident is not a cyberwar event. It stems from two severe flaws in PHP itself, a server-side technology used widely across websites.
WordPress security company Wordfence said every WordPress site relies on a server running PHP. The concern here is unauthenticated remote code execution, or RCE. In plain terms, an outsider may be able to run commands directly on a server without logging in first. GoDaddy warned that the flaws could be used to steal data, alter website content, and execute attacker-controlled code over the internet on affected servers, potentially leading to data theft or full server compromise.
PHP moved up its security release
The PHP Foundation, the nonprofit that funds development of the language, had warned in advance that the PHP security team planned to release updates at 14:00 UTC on Oct. 21, 2026, covering two critical vulnerabilities with CVSS v4 scores of 9.2. It also said the release could be moved forward if details leaked early or if there was evidence of active exploitation.
That is what happened. PHP published fixes slightly ahead of schedule on Wednesday, releasing PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35. It said the flaws affect PHP environments that handle web requests, including PHP-FPM, Apache mod_php, php-cgi, FrankenPHP, and LiteSpeed. Apache mod_php was singled out as especially exposed because exploitation can happen before application code starts running.
The official security notice left little room for interpretation: all PHP users were strongly advised to update immediately. Even so, a patch release does not mean every server has already been fixed, and that gap is where the risk sits.
How the two bugs work
The first flaw, CVE-2026-109618, appears when PHP runs out of memory while processing a request. In that state, PHP may treat partially built data as if it were complete.
The second, CVE-2026-109619, involves leftover request data that should have been cleared from memory but remains there, allowing later requests to be influenced by stale data.
The article compares the situation to a chef reading order slips that were already thrown in the trash. If someone slips a fake order into the bin, the chef may still follow it. In this case, the fake order is malicious code, and the server may execute it.
PHP said servers using the common Apache mod_php setup face the highest risk. Demonstrated attacks can run before any application code executes. That means site-level defenses such as login pages or WordPress security plugins may not even get a chance to start.
Researchers at the PHP Foundation also identified PHP's upload progress tracking feature as one confirmed attack path. The feature has been enabled by default for more than a decade, though relatively few websites actually use it.
Leak concerns turned into early attack activity
Details of the vulnerabilities were not supposed to surface this early. On Tuesday, a post on Hacker News claimed that two PHP flaws were scheduled to be disclosed later that week, while admitting there was no proof beyond "source: trust me bro." The claim turned out to be directionally correct.
Security company watchTowr confirmed that the vulnerabilities were real and still under embargo at the time, meaning details were meant to stay private until fixes were ready. PHP then moved the release forward by one day.
Cloudflare CTO Dane Knecht wrote on X early Wednesday: "We have observed early attacks beginning and are continuously updating mitigations as new attack paths emerge." His post came nearly six hours before the official patch release.
Cloudflare then pushed emergency firewall rules to all customers to block known attack patterns. Knecht said those measures could only serve as a temporary response.
Governments and agencies pulled sites offline
Finnish public broadcaster Yle reported that Finland's state 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 Interior Ministry said prefecture websites had been temporarily taken offline until the relevant framework publisher released a security patch. CERT-EU, the European Union's cyber emergency response team, advised organizations that could not patch right away to consider isolating internet-facing applications from public networks until a fix was available.
Authorities in Australia, Japan, and the U.K. later issued broadly similar guidance. In practical terms, some organizations were told to disconnect exposed services first and restore them later.
Which PHP versions are affected
Some widely shared posts on X claimed that every PHP version since 2004 was vulnerable. That line came from an early estimate suggesting all versions from PHP 5 onward were affected. CERT-EU acknowledged that estimate was based on social media posts.
E-commerce security company Sansec gave a narrower range, saying affected versions start at PHP 5.4 and continue through later releases. That would push the exposure window back to 2012 rather than 2004, though it still covers very old software.
PHP currently provides official release updates only for PHP 8.2 and newer. So the claim that older versions have no standard fix is partly true. Because of the severity of the issue, the PHP security team also published slim source-code patches for PHP 7.4, 8.0, and 8.1, while Linux distributions have been backporting fixes into the versions they maintain.
Mallory estimated that as of Oct. 20, about 884,000 internet-facing hosts were publicly showing PHP 8.1 or older. That represented 59% of the 1.5 million hosts exposing version information. Since one shared host can serve many websites, the number of affected sites could be higher.
Some online posts also dragged Node.js into the story. The article said that was a mix-up. Node.js is a different web technology that happened to have an unrelated security release on the same day.
Why the patch window matters
Publishing a patch helps defenders, but it also gives attackers a roadmap. Once the fix is public, they can compare old and new code to identify exactly what changed.
The PHP Foundation said users relying on the volunteer-maintained repository at https://rpms.remirepo.net should switch to official Linux distribution packages or build from source to apply updates immediately, because that repository would not publish updates that day. The repository is a popular package source for Red Hat-style Linux servers.
Sansec's forensics team said it expected large-scale attacks to begin within 15 minutes of patch release. There is precedent. After another PHP vulnerability was disclosed in June 2024, Akamai said it saw exploitation attempts against its honeypot servers within 24 hours.
PHP core developer Gina Peter Banyard wrote on Mastodon: "The only thing I can say is that the only mitigation is to patch PHP or upgrade PHP. Unfortunately I know too much."
What this means for crypto users
For ordinary crypto users, the immediate threat is not that a blockchain gets hacked through PHP. The more realistic risk is that a compromised website serves a malicious front end that looks legitimate and asks users to connect wallets, sign messages, or approve transfers.
The article points to earlier examples. In 2024, attackers redirected the front ends of DeFi protocols Compound and Celer to malicious pages that tricked users into connecting wallets and losing funds. Curve Finance saw a similar incident in 2025. Those cases involved DNS hijacking rather than PHP flaws, but the user-facing effect can look similar: the site appears normal, the URL may not look suspicious, and the approval button can still send tokens somewhere else.
If a server is compromised through a zero-day flaw, attackers can deliver the same kind of malicious page directly from the legitimate site. The article also notes that advanced AI models are increasingly being used to find software vulnerabilities. In June, experts told Decrypt that broader access to those tools could lead to more vulnerabilities being discovered in the future.
What operators and users should do now
Most users do not need to install a PHP patch on their phones, browsers, or laptops. The people who need to act first are the operators of the websites they visit. Site owners should contact their hosting providers and confirm whether PHP has been updated.
Wordfence warned that automatic update systems will not automatically apply this fix. Website owners need to find out who is actually responsible for updating PHP on the server rather than assuming WordPress will handle it.
For sites still on PHP 8.2, this patch may be among the last they receive, because support for that branch ends on Dec. 31, 2026. Users still running PHP 8.1 or earlier need an upgrade plan.
For crypto users, the practical advice is simple. There is no reason for immediate panic, but there is also no reason to be casual. Treat wallet connection prompts and token approval requests carefully, especially on sites handling DeFi, trading, or wallet access. In incidents like this, the first break does not have to happen on-chain. It can start with the webpage in front of you.