"Unconfirmed Damage" Doesn't Mean Safety - PHP Vulnerability Halts Sites, What's Happening Now

The website you always use suddenly won't open. But what if the reason isn't destruction from a cyberattack, but a temporary halt to protect against an attack? How would you perceive it?

A critical vulnerability in PHP, the programming language that supports websites and web applications, has been revealed, leading administrative bodies in Germany to preemptively shut down their sites.

According to an AFP article published by BUSINESS-PANORAMA on October 22, the German Federal Office for Information Security (BSI) stated that, at that time, no cases of exploitation of this vulnerability had been confirmed. However, they did not rule out the possibility that attacks might have succeeded.

The important point to note when reading this news is that "unconfirmed damage" and "confirmed safety" are not the same.

BSI's Announcement Is Not a "Declaration of End"

According to the original article, BSI issued a warning about the PHP vulnerability on the afternoon of October 21 and announced that a security update was scheduled for 4 PM that day.

The concern was that attacks might spread after the update details were made public. If the location of the problem became clear through the fix, attackers might analyze that information and target unpatched systems. The article also expressed concern that AI could facilitate such analysis.

On the following day, October 22, BSI explained that most of the federal administrative agency sites that had been preemptively shut down had been restored. They suggested that the absence of reports of compromised systems might indicate that many operators had followed the recommendations and completed the updates.

However, this evaluation is based on the information they were able to gather. It does not guarantee that all sites have been investigated and that no intrusions occurred.

While the restoration of sites is good news for users, it's too early to conclude that the entire issue has been resolved based solely on that.

The Problem Lies in the "Foundation" of Websites

This time, PHP addressed two critical vulnerabilities known as "PHP2Shell." The identification numbers are CVE-2026-109618 and CVE-2026-109619. Both have a CVSS v4.0 severity rating of 9.2, classified as "Critical."

On October 21, the PHP Foundation announced that they had fixed an issue where, under certain conditions, an unauthenticated attacker could execute code on a server running PHP.

For general users, PHP is something they usually don't think about. It handles processes behind the scenes, not the design of the screen or the articles themselves.

Therefore, when considering the response this time, it's not enough to just focus on the appearance of the site or the management screen. It's necessary to check the status of the foundational updates that run the applications.

The PHP Foundation has released updated versions: PHP 8.2.35, 8.3.36, 8.4.27, and 8.5.12. Operators need to verify the status of these updates, including guidance from their service providers.

Don't Confuse "Attempted Attacks" with "Successful Intrusions"

Alongside the original article about BSI, it's important to note the observation report by AWS.

AWS announced that their system "MadPot," designed to observe attacks, confirmed attempts to exploit PHP2Shell dating back to October 17. This was before the details of the vulnerability were publicly disclosed.

However, AWS stated that it is unknown whether the observed attempts succeeded on actual systems.

In other words, the report about BSI's "no confirmed cases of exploitation" and AWS's "observed attack attempts" refer to different subjects and confirmations. Highlighting only one side cannot lead to the conclusion that "there were no attacks" or "widespread intrusion damage has been confirmed."

Both users and operators need to separately understand the existence of vulnerabilities, the observation of attacks, the success of intrusions, and the confirmation of information leaks.

On Social Media, Voices Also Praise the Swift Fixes

On social media and online communities, opinions are seen not only about the sense of crisis but also about how the reports are perceived.

In the Reddit PHP community post "Has PHP2Shell borne fruit?", opinions can be found that, while touching on fear-inducing articles and criticism of PHP, praise the swift fixes and responses of major Linux distributions.

This reflects a perspective that, apart from the severity of the vulnerabilities, the responses of developers and distributors should also be noted. However, the evaluation of damage by the poster does not directly indicate the safety of the entire world.

Meanwhile, a Reddit post about the email alias service addy.io shared that their web system was temporarily halted in response to PHP2Shell. It explained that email delivery continued, and later announced that the system was restored after applying the fixes.

Rather than ending with just "the service is unavailable," it communicates what was halted, what is available, and when it was restored. Such information sharing can help reduce user anxiety.

It should be noted that the posts introduced here are individual posts that could be confirmed and do not represent the majority opinion or a public survey of social media as a whole.

The Decision to Halt a Site Also Requires Explanation

Preventive shutdowns cause inconvenience to users. If they can't make inquiries, proceed with procedures, or purchase products, it also burdens the operators.

Nevertheless, restricting external access until the fixes are complete serves to reduce exposure to attacks. CERT-EU also advises considering isolating internet-exposed applications from public networks if immediate fixes cannot be made.

Therefore, it's difficult to judge the quality of operations based solely on whether a site was halted.

What is more questioned is whether the reason for the shutdown was explained, whether the affected functions were specified, and where the next announcement could be confirmed.

A site that disappears without explanation and a site that communicates measures to protect users will be perceived differently, even if both are halted.

For Japanese Operators, This Is Not Just "Overseas News"

The PHP issue is not just related to German-language sites. If the same technology is used, Japanese businesses also need to verify their environments.

In that case, the initial challenge might be clarifying who manages their site rather than making specialized configuration changes.

Is it handled by a production company? Does the rental server company update the infrastructure? Or does someone in-house need to respond?

The points to confirm can be organized as follows:

• Is PHP used in the operating environment of the site?
• Have the fixes for this vulnerability been applied?
• Are the person responsible for updates and the method for confirming the completion of responses decided?
• If immediate fixes cannot be made, who will decide to restrict public access?

There is a significant difference between "the contractor should be handling it" and "confirmed that it has been handled."

Additionally, CERT-EU indicates that for series like PHP 8.1 and earlier, which have ended support, updates will not be provided by the PHP project. If using an older environment, it's necessary to confirm whether fixes are provided by the environment's provider and whether migration is needed.

Defensive Measures Are Not Necessarily a Substitute for Updates

There are situations where one might want to believe that having mechanisms to prevent attacks is sufficient.

However, AWS clearly states that in this case, WAF measures are supplementary to reduce the range of exposure to danger and are not a substitute for PHP updates.

What matters is not just the fact that some defensive product is being used, but how much that measure covers the current issue.

The original article also introduces BSI's call for general users to avoid making routers accessible from outside and to be cautious about downloads and providing confidential information.

This does not mean that all users' devices or routers are directly affected by this vulnerability. The responses by operators and the daily precautions by users should be understood separately.

There Is Work Behind "Nothing Happened"

If no significant damage is reported after a major warning, some might feel it was overblown.

However, the reason for the unseen damage might be due to early updates or preventive shutdowns, or it might still be unknown. It's impossible to conclude either way based solely on current information.

What this PHP vulnerability shows is that continuing to publish a site is not the only responsibility of operators. Stopping when necessary, fixing, checking the status, and explaining to users—this series of responses is also part of the work that supports the service.

The news of "unconfirmed damage" is not a reason to stop responding. Only after confirming the status of one's own environment can reading the news translate into actual preparedness.

Source

1. BUSINESS-PANORAMA/AFP (October 22, 2026)
   BSI's statement that no exploitation cases were confirmed, the exclusion of intrusion possibilities, the restoration status of administrative sites, and the basis for general user advisories.
   https://business-panorama.de/news.php?newsid=6715602

2. PHP Foundation "Today's PHP Security Release, and How We're Strengthening PHP Security"
   Official explanation of the release of updated versions on October 21 and the dangers posed by the vulnerabilities.
   https://thephp.foundation/blog/2026/10/21/todays-php-security-release-and-how-were-strengthening-php-security/thephp.foundation

3. CERT-EU "Critical Vulnerabilities in PHP"
   CVE numbers, severity, affected environments, end-of-support series, and official advice on fixes and isolation.
   https://www.cert.europa.eu/publications/security-advisories/2026-018Critical Vulnerabilities in PHP

4. AWS Security Blog: MadPot's PHP2Shell Observation Report
   Explanation that attempts to exploit before public disclosure and the success in real environments are unknown. The basis for distinguishing "observation of attacks" and "confirmation of damage."
   https://aws.amazon.com/blogs/security/amazon-threat-intelligence-identifies-php2shell-exploitation-prior-to-public-disclosure-in-madpot/aws.amazon.com

5. AWS Security Blog: WAF Mitigation Measures for PHP2Shell
   Official document explaining the position of WAF and the necessity of PHP updates.
   https://aws.amazon.com/blogs/security/using-aws-waf-to-apply-mitigations-for-php2shell-rce-vulnerabilities-cve-2026-109618-and-cve-2026-109619/aws.amazon.com

6. Reddit・r/PHP "Has PHP2Shell borne fruit?"
   Individual reactions questioning the reports and praising the swift fixes. The damage evaluation in the post is not adopted as a confirmed fact.
   https://www.reddit.com/r/PHP/comments/1xchgrv/has_php2shell_borne_fruit/reddit.com

7. Reddit・r/addy_io "Service Update 🚨PHP2Shell vulnerability"
   Example of information sharing on preventive shutdowns of web systems, continuation of email delivery, and restoration after fixes.
   https://www.reddit.com/r/addy_io/comments/1xbkaeb/service_update_php2shell_vulnerability/