Is the Internet Safe Again After PHP2Shell? Here Is What Users and Website Owners Need to Know

Table of Contents

• You might want to know
• What PHP2Shell means and whether the web is safe
• Key Insights Table
• Afterwards...

You might want to know

• Does the release of PHP security updates mean every vulnerable website is now protected?
• Should ordinary users change passwords or avoid cryptocurrency websites because of PHP2Shell?

What PHP2Shell Means and Whether the Web Is Safe

The PHP security crisis has moved from emergency disclosure to the difficult work of installing updates and checking for intrusions. Two flaws, collectively nicknamed PHP2Shell, can allow an attacker to take control of a vulnerable server without logging in. PHP released security updates, and organizations have responded by patching systems or temporarily taking some websites offline. Yet a published fix does not automatically protect every server: the people and organizations responsible for those systems must install the relevant release and restart PHP before the fix takes effect.

For everyday internet users, this does not mean the internet itself has stopped working or that personal phones and laptops are automatically exposed. The main risk is to websites and online services whose servers have not been secured. The distinction matters: a vulnerable server may host a site that people visit, while the visitor’s own device is not necessarily affected by the flaw. That is reassuring, but it does not make the event irrelevant. A compromised website could potentially mislead visitors, expose information, or serve harmful content.

PHP is a programming language and runtime used behind the scenes by websites. The source reports that it powers about 70% of websites for which the server-side language is known. Because of its widespread use, weaknesses in PHP can affect a broad range of organizations, from private websites to government services. PHP2Shell refers to two separate vulnerabilities, identified as CVE-2026-109618 and CVE-2026-109619. The reported impact is particularly serious because an attacker may be able to take control of an affected server without first authenticating.

PHP’s October 21 releases remain the only complete fix described in the source. The project released versions 8.5.12, 8.4.27, 8.3.36, and 8.2.35 on Wednesday, according to its release notes. The project’s guidance was direct: “There are no complete mitigations, updating is the only safe choice.” As of Thursday, PHP had not issued a follow-up patch. Installing the update and restarting PHP are necessary steps; merely knowing that the fix exists does not change a server’s software.

Updates are not applied automatically in the circumstances described. Hosting companies, business IT teams, public-sector technology departments, and individual website owners each need to update the systems they operate. Some organizations may manage many servers or depend on testing procedures before deploying changes, which can slow the process. A site can therefore remain vulnerable even after a fix has been announced. PHP 8.1 and earlier no longer receive official releases, creating an additional challenge for older systems. PHP’s security team did post bare-bones patches for 7.4, 8.0, and 8.1 for people who compile the software themselves, but those patches do not amount to the normal official release support described for current versions.

The scale of attack activity has been striking, though attempts are not the same as successful compromises. Cloudflare CEO Matthew Prince said the company’s network saw thousands of exploit attempts in the 10 hours before the public announcement. Activity rose to tens of thousands in the 45 minutes after the announcement, reached hundreds of thousands within two hours, and later amounted to millions. Those figures show that attackers moved quickly to test the weakness. They do not, by themselves, establish how many servers were successfully taken over.

Amazon reported an even earlier sign of activity. The company said its decoy servers logged an attempt on October 17, four days before the flaws became public. Amazon Chief Information Security Officer CJ Moses said it remained unclear how the actor obtained exploit information before disclosure, and described PHP2Shell as “now being broadly exploited in the wild.” The timing means defenders should not assume that the public announcement marked the beginning of all exploitation. A server that ran a vulnerable version before disclosure may need a review for signs of earlier access, in addition to an update.

Government statements in Germany and Japan offered a more reassuring, but carefully limited, picture. Thomas Caspers, vice president of Germany’s federal cybersecurity agency BSI, said the agency had observed attacks but no successful use of the flaws. He added that exploitation seemed “a little bit more complicated than expected.” Japan’s Chief Cabinet Secretary, Minoru Kihara, also said that no attacks exploiting the vulnerabilities had been confirmed. These statements do not prove that no organization anywhere was breached. They report that the named authorities had not confirmed successful attacks at the time of their comments.

A useful way to understand the difference is to imagine someone trying a doorknob. An exploit attempt is like rattling the door; a breach means getting inside. Millions of attempts can occur without a confirmed break-in, so the reported figures are not necessarily contradictory. At the same time, intrusions are not always discovered immediately. A lack of confirmed incidents at a particular moment is encouraging, but it cannot substitute for checking affected systems and monitoring them over time.

The PHP Foundation’s account also raised questions about how the vulnerability was handled. In a blog post published Wednesday, the foundation said security work in 2024 had found the first signs of the out-of-memory problem behind CVE-2026-109618. The team considered “several competing approaches” but struggled to choose among them and feared the consequences of selecting the wrong fix. The foundation said its funding made it possible for multiple people to work on the issue full time, while acknowledging that the response still took too long.

The foundation described the delay as “a structural failure,” attributing it to both the security team’s decision-making process and a lack of resources. Previously, the security team required consensus; the foundation said it would move to majority decisions. This is significant because PHP supports a substantial part of the web, while security work depends on a small group of foundation-funded developers and some volunteer assistance. The episode illustrates how the security of widely used infrastructure can depend on limited development capacity and governance processes, not only on the technical quality of a patch.

Some websites went offline because taking a vulnerable service out of public reach can be a temporary protective measure when an organization cannot patch it immediately. The UK’s National Cyber Security Centre advised organizations to consider “taking the system offline until it can be fully mitigated.” Sites reported as unavailable on Wednesday included Wikimedia services, Orange websites and apps across dozens of countries, 32 UK government services, Dutch hospitals, and Germany’s federal IT provider, ITZBund. The UK’s Office for Budget Responsibility and Edinburgh’s council website were back by Thursday. The Dutch anonymous crime-reporting site Meld Misdaad Anoniem was still offline Thursday morning, according to DutchNews. These examples show that outages can be a deliberate response to risk, rather than proof that every offline service was successfully attacked.

For the general public, the available information does not support changing every password solely because of PHP2Shell. No confirmed data breach had been tied to the vulnerabilities at the time described. Changing a password does not protect an account if the service’s server remains unpatched, and it cannot establish whether an attacker accessed information. More useful baseline practices remain important: use a unique password for each account, enable two-factor authentication, and pay attention to notices from companies. If a service reports a breach, change the password for that account and for any other account where the same password was reused.

Website operators have additional responsibilities. Applying a patch closes the known weakness, but does not establish whether an attacker entered before the update. Security firm Tag1 advised checking for PHP files that the organization did not upload, newly created scheduled tasks, and unfamiliar accounts. It also recommended rotating database passwords and API keys on internet-facing servers that ran a vulnerable version. These checks address the possibility of persistence or stolen credentials, rather than treating the software update as proof that a system is clean.

Cryptocurrency users face a related risk through the websites they visit, not necessarily through the underlying blockchain networks. Binance founder Changpeng Zhao advised users on X to be especially careful visiting websites because some administrators may not apply security patches promptly. A compromised web server could display a convincing imitation of a legitimate site. In a cryptocurrency context, a fake page might ask a user to connect a wallet and approve a transaction that transfers funds away. The chain itself may remain operational while a website used to interact with it is compromised.

For the next few days, users can reduce avoidable risk by entering familiar sites through bookmarks rather than following unexpected links, checking website addresses carefully, and reviewing every transaction or wallet approval before signing it. A hardware wallet may provide additional protection for users who have one, but it does not make it safe to approve an unfamiliar or suspicious transaction. The source reported that no cryptocurrency exchange had publicly reported a breach tied to PHP2Shell at that time. That is a statement about public reporting, not a guarantee that every related service was unaffected.

The broader risk remains concentrated in servers that have not been patched. Security company Mallory counted roughly 884,000 internet-facing hosts running PHP versions that receive no official fix. That figure emphasizes the persistence of older systems and the difficulty of achieving universal patching. Amazon’s advice to defenders was to avoid assuming the public disclosure date was the earliest date of exploitation. In practical terms, organizations that operated vulnerable versions since at least October 17 should investigate those systems, not simply install updates and move on.

Overall, browsing is not described as categorically unsafe, and the incident does not mean that all websites or personal devices have been compromised. The situation is better understood as an active security response: fixes are available for supported releases, attackers have attempted to exploit the flaws at large scale, and some organizations have not yet completed remediation. Individual users should remain alert without making unsupported assumptions, while server operators should prioritize updates, investigations, and credential rotation where warranted.

Key Insights Table

Afterwards...

The next phase depends on how quickly organizations update exposed systems and whether investigations uncover evidence of access before patching. Website operators should treat the release as the beginning of remediation, not its conclusion: install the appropriate update, restart PHP, inspect potentially affected servers, and follow incident-response procedures if anything suspicious appears. Users can continue browsing with ordinary caution, particularly when visiting services that handle sensitive information or cryptocurrency transactions.

The incident also leaves a longer-term question about maintaining critical open-source software. The PHP Foundation’s account points to the importance of sufficient security funding, clear decision-making, and timely escalation when developers discover warning signs. Since older PHP versions no longer receive official releases and many internet-facing hosts remain on them, organizations will need plans for upgrading legacy systems rather than relying indefinitely on temporary measures. The internet is not “safe again” simply because a patch exists; risk declines as fixes are installed, systems are checked, and the people who maintain essential software receive the resources and processes needed to respond effectively.