PHP Security Vulnerabilities Trigger Global Website Shutdowns and Emergency Patches

This article comes from:Decrypt

Compiled by Odaily Planet Daily (@OdailyChina); Translator | Moni

Editor’s Note: PHP has recently been found to have two critical security vulnerabilities, both rated 9.2 on CVSS v4. Attackers can execute malicious code—and even fully take over—affected servers without needing to log in. Multiple countries, including Finland, France, and the Netherlands, have taken preventive measures such as temporarily taking websites offline. The official PHP team has also urgently released patched versions. These vulnerabilities affect multiple older PHP versions, and security agencies warn that widespread attacks may rapidly follow the public disclosure of the patches.

Last night, Japanese Prime Minister Takichi Saionji posted a "major request for urgent action" on X regarding risks related to PHP.

This article outlines the vulnerability's mechanism, scope of impact, and recent developments, and analyzes the response measures that website operators and ordinary cryptocurrency users should take, translated by Odaily Planet Daily.

If you’ve been online these past two days, you’ve likely seen this wave of online panic: a critical vulnerability is threatening nearly all websites worldwide—Finland has shut down its government websites, the U.S. National Security Agency (NSA) has advised all organizations using PHP to take theirs offline, and the Netherlands and France have taken the same steps.

However, this is not a cyberwar, but rather two major security vulnerabilities in PHP being exposed.

PHP is backend software that runs on a website’s server. You can think of a server as a computer that stores website content and generates web pages in response to user requests. According to WordPress security company Wordfence, every WordPress website is powered by a server running PHP.

By the way, Wordfence's own website is also down.

Why are PHP vulnerabilities concerning? Actually, related vulnerabilities allow strangers to execute their own commands on the server without needing to log in. In the security industry, these types of vulnerabilities are known as "Unauthenticated Remote Code Execution" (RCE).

In simpler terms, it means “Now, someone else can control your server on your behalf.”

If the server stores your account information, addresses, or order history, this data could also fall into the hands of attackers. Web hosting provider GoDaddy warns that these vulnerabilities could be exploited to steal data, alter website pages, and allow attackers to execute their own code on affected servers over the internet, leading to data theft or even full server compromise.

The PHP Foundation, the nonprofit organization responsible for funding PHP language development, has issued an alert:

PHP Security Team Advisory: A security update is scheduled for Wednesday, October 21, 2026, at 14:00 UTC, addressing two critical vulnerabilities, both with a CVSS v4 score of 9.2. PHP users are advised to prepare for the update in advance. If details are disclosed prematurely or evidence emerges that the vulnerabilities are being actively exploited, the update may be released earlier.

The score of 9.2 here comes from the Common Vulnerability Scoring System (CVSS), which evaluates the severity of vulnerabilities based on factors such as whether they can be easily accessed over the internet and the potential damage they could cause. The scoring range is 0 to 10, and scores of 9.0 or higher are classified as critical vulnerabilities. Therefore, even without reaching the maximum score of 10, the severity of these two vulnerabilities is already very high.

On Wednesday, PHP released patch versions a few minutes early: PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35. The vulnerability affects PHP environments that handle web requests, including PHP-FPM, Apache mod_php, php-cgi, FrankenPHP, and LiteSpeed, with Apache mod_php posing particularly high risk, as exploitation can occur before application code runs.

However, the official security advisory explicitly emphasizes: "All PHP users are strongly advised to update immediately."

However, releasing a patch does not mean all users have completed the fix, so remain vigilant.

The first vulnerability, CVE-2026-109618, occurs when PHP runs out of memory while processing a request. Afterward, PHP may treat a partially constructed dataset as if it were fully completed.

The second vulnerability, CVE-2026-109619, causes residual data left by a visitor's request to remain in memory even after it should have been cleared, potentially affecting subsequent requests with this leftover data.

You can think of this situation as a chef who keeps reading order slips that have been thrown into the trash—but if someone slips a fake order slip into the bin, the chef will cook according to it. In this vulnerability, the “order slip” is the attacker’s malicious code, and the server executes it.

PHP indicates that servers using the common Apache configuration mod_php face the highest risk. With this configuration, the demonstrated attacks can be executed even "before any application code runs."

In other words, the website’s own defense mechanisms, such as the login page and WordPress security plugins, haven’t even had a chance to activate.

Researchers from the PHP Foundation have identified PHP's upload progress tracking feature as a confirmed attack vector. This feature, which tracks the progress of file uploads, has been enabled by default for over a decade, but in practice, very few websites actually use it.

Information about these vulnerabilities should not have been made public so early. In fact, on Tuesday this week, someone posted on the Hacker News forum stating that two PHP vulnerabilities were originally scheduled to be disclosed on Thursday of that week, while acknowledging they had “no evidence other than ‘trust me, bro.’”

It turns out the netizen was right.

The security firm watchTowr confirmed that both vulnerabilities were real and still under embargo, meaning all parties had agreed not to disclose details until a fix was ready. Subsequently, PHP moved up its update release by one day.

Cloudflare Chief Technology Officer Dane Knecht posted on X early Wednesday: “We have observed the early stages of attacks and are continuously updating our mitigation measures as new attack vectors emerge.”

When this message was posted, there were still nearly six hours until the patch was officially released.

Cloudflare immediately rolled out emergency firewall rules to all customers, using filters to block known attack patterns. However, Dane Knecht emphasized that these measures “can only serve as a temporary response.”

According to Finland’s public broadcaster Yle, Finland’s national IT center, Valtori, has begun taking down public web services as a precautionary measure. The Dutch national cybersecurity agency has also shut down its website.

In France, the Ministry of the Interior stated that government websites have been "temporarily taken offline" until a security patch is released by the provider of the relevant framework.

The EU Computer Emergency Response Team, CERT-EU, recommends that organizations unable to install patches temporarily “consider isolating internet-facing applications from the public network until a fix is available.”

Subsequently, the relevant authorities in Australia, Japan, and the UK issued similar recommendations.

In simple terms, it’s like “pulling the plug.”

Some popular posts on the X platform claim that PHP has vulnerabilities in "all versions since 2004."

This claim originated from early estimates that all versions of PHP 5 and later were affected. However, CERT-EU acknowledges that this estimate was based on posts from social media.

The e-commerce security company Sansec believes the affected versions begin with PHP 5.4 and include all subsequent versions. This means the vulnerability could date back to 2012, rather than 2004. However, these are still very old software versions.

The official PHP team currently provides official updates only for PHP 8.2 and later versions. Therefore, the statement that "there are no fixes available for older versions" is partially correct.

Due to the severity of this vulnerability, the PHP security team has also released minimal source code patches for PHP 7.4, 8.0, and 8.1. Various Linux distributions are now backporting the fixes to their maintained versions.

Security firm Mallory found that, as of October 20, approximately 884,000 hosts exposed to the internet displayed PHP 8.1 or earlier versions. These hosts account for about 59% of the 1.5 million hosts publicly displaying version information.

Since a shared host can host many websites, the actual number of affected websites may be higher.

Some online posts also included Node.js in the affected scope. Node.js is a different web technology that just happened to release a security update on the same day, unrelated to this incident. The timing overlap caused confusion.

Even though a patch has been released, it does not mean all servers will be updated immediately.

The PHP Foundation stated in its announcement: "If you rely on the volunteer-maintained https://rpms.remirepo.net, we strongly recommend that you switch immediately to your Linux distribution's official packages or build from source yourself to apply updates right away. This repository will not release updates today."

This statement refers to a popular software package repository maintained by volunteers, primarily targeting Red Hat-style Linux servers.

To be frank, ordinary users don’t need to panic immediately, but they shouldn’t ignore it either.

For example, a website breach does not require directly attacking the blockchain to steal assets from your wallet.

In 2024, attackers redirected the frontend pages of the DeFi protocols Compound and Celer to malicious pages, tricking users into connecting their wallets and stealing their assets. In 2025, Curve Finance suffered a similar attack.

However, these incidents are DNS hijacking, not PHP vulnerabilities, but the attack methods are similar: the website appears normal and the URL looks legitimate, but the “approve” button you click may send tokens to a different address.

If the server is compromised, attackers can also serve this malicious page to users. When exploiting zero-day vulnerabilities, hackers often quickly devise various attack methods.

Meanwhile, discovering such vulnerabilities is becoming increasingly easier. Advanced AI models are being used more frequently to identify software vulnerabilities. In June, experts told Decrypt that as these tools become more widespread, more vulnerabilities are likely to emerge in the future.

Should ordinary users panic?

You don’t need to install PHP patches on your phone, browser, or laptop—the people operating the websites you visit are the ones who need to take action. If you operate a website, contact your hosting provider to confirm that PHP has been updated. Don’t assume WordPress will handle this for you automatically: Wordfence has warned that the automatic update mechanism will not apply this fix, and recommends website owners determine who is responsible for updating PHP on their servers.

If you are using PHP 8.2, the fix you just received may be one of the last: this version will reach end-of-life on December 31, 2026, and will no longer receive security patches afterward. Additionally, users still on PHP 8.1 or earlier versions should develop a plan to upgrade.

The PHP Foundation's announcement of patches will provide some assistance, but the issue is that once the patches are made public, attackers can compare the code before and after the fix to accurately identify which vulnerabilities were addressed. The forensic team at cybersecurity company Sansec stated that "large-scale attacks are expected 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 stated on Mastodon: "The only thing I can say is that the only mitigation is to patch or upgrade PHP. Unfortunately, I know too much."