PHP's October 21 security releases remain the only fix for PHP2Shell, a pair of vulnerabilities that can allow an unauthenticated attacker to take control of a vulnerable server. The patches protect a server only after its owner installs them and restarts PHP.

Cloudflare CEO Matthew Prince said exploit attempts across the company's network climbed from thousands to millions. Germany's federal cybersecurity agency, the BSI, and Japan's government said they had not confirmed any successful break-ins. The PHP Foundation, which funds work on PHP itself, said it first identified signs of one flaw in 2024 and described the delay in resolving it as “a structural failure.”

The developments came a day after the two PHP bugs prompted governments and organizations to take websites offline. The immediate question for internet users is whether it is safe to browse normally. The short answer is that the internet itself did not break, and that most users face the risk through the websites they visit rather than through their own phones or computers. However, many servers still need to be patched.

PHP, an open-source server-side language, is used behind the scenes by about 70% of websites whose server-side programming language is known. That reach is why a flaw in PHP itself becomes a web-wide patching event rather than a single company's problem. The two vulnerabilities, collectively nicknamed PHP2Shell, can allow a stranger to take control of a vulnerable server without logging in.

Is PHP2Shell fixed?

PHP released versions 8.5.12, 8.4.27, 8.3.36, and 8.2.35 on October 21, according to its release notes. The release states: “There are no complete mitigations, updating is the only safe choice.” As of October 22, PHP had not issued a follow-up patch.

The availability of a patch does not mean that every affected website is protected. PHP does not update itself, so hosting companies, IT departments, and individual website owners must install the relevant release on their own servers and restart the software for the change to take effect. In practice, protection spreads at the pace of server maintenance rather than at the moment of release, so how many servers remain exposed will be decided by how quickly operators complete those rollouts.

PHP 8.1 and earlier no longer receive official releases, making older servers a particular weak spot. PHP's security team did publish bare-bones patches for versions 7.4, 8.0, and 8.1 for users who compile the software themselves.

Were servers breached?

Attackers began probing for vulnerable systems quickly. Prince said Cloudflare saw thousands of exploit attempts during the 10 hours before the public announcement, tens of thousands during the following 45 minutes, hundreds of thousands within two hours, and millions afterward.

https://x.com/eastdakota/status/2113079352682570051?ref_src=twsrc%5Etfw

Amazon said its decoy servers recorded an attempt on October 17, four days before the vulnerabilities were publicly disclosed. Amazon CISO CJ Moses wrote that “it remains unclear how the actor acquired exploit information prior to disclosure,” and said PHP2Shell was “now being broadly exploited in the wild.”

In a security blog post, Amazon said the activity had been observed before public disclosure.

Governments, however, had not reported confirmed successful intrusions at the time. Thomas Caspers, vice president of Germany's federal cybersecurity agency BSI, said the agency had observed attacks but no successful exploitation of the flaws. He added: “It seems a little bit more complicated than expected to exploit.” Japan's Chief Cabinet Secretary, Minoru Kihara, likewise said no attacks exploiting the vulnerabilities had been confirmed.

An exploit attempt and a successful breach are different events. Millions of attempts can occur while no confirmed break-in has yet been identified, and successful intrusions may be discovered after the fact rather than in real time. For readers following the story, that means updates about confirmed breaches, if any, would arrive through later investigations and official disclosures rather than real-time announcements.

Why was the problem not fixed sooner?

The PHP Foundation said its security work in 2024 “found the first signs of the OOM problem behind CVE-2026-109618,” referring to the out-of-memory bug at the center of one of the two vulnerabilities.

According to the foundation's account of the security release, the team developed “several competing approaches” but “struggled to choose between these and feared the repercussions of shipping the wrong choice.” The foundation said its funding made it possible for multiple people to work on the issue full time.

“We won't pretend otherwise: the delay was a structural failure, caused by both the security team's decision process and its lack of resources,” the foundation wrote. It said the security team had previously required consensus but would now make decisions by majority vote.

The foundation also said that security work on the software running much of the web “still depends on a small group of foundation-funded developers and a little volunteer help.”

Why did some websites go offline?

Patching takes time, and organizations that could not immediately apply the fix were advised to take systems offline. The UK's National Cyber Security Centre told organizations to consider “taking the system offline until it can be fully mitigated” in its guidance.

According to TechRadar, websites and services affected on October 21 included Wikimedia services, Orange websites and applications 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 online by October 22. Other services, including the Dutch anonymous crime-reporting website Meld Misdaad Anoniem, remained offline on Thursday morning, according to DutchNews.

Should users change their passwords?

Not solely because of PHP2Shell, at least based on the information available. No confirmed data breach had been tied to the vulnerabilities, and changing every password would not protect a website whose server remained unpatched.

Standard security measures remain useful: use a unique password for every account, enable two-factor authentication, and pay attention to notices from companies about possible breaches in the coming weeks. If a company confirms a breach, users should change the affected password and any other password that was reused.

Website owners have additional work to do because applying a patch closes the vulnerability but does not show whether an attacker accessed the server beforehand. Security firm Tag1 advises owners to look for PHP files they did not upload, new scheduled tasks, and newly created accounts. It also recommends rotating database passwords and API keys on any internet-facing server that ran a vulnerable version. Tag1's guidance is available here.

What does PHP2Shell mean for crypto users?

Binance founder Changpeng Zhao warned users on X: “Call me paranoid, but be extra careful visiting ANY web site in the next few days.”

https://x.com/cz_binance/status/2113029289155178716

A compromised web server can display a fake version of a legitimate website. In the crypto sector, such a page could ask a user to connect a wallet and approve a transaction that drains it. A blockchain network may remain unaffected while websites providing access to it are compromised.

Users should carefully check what they are signing, bookmark websites instead of following links, and use a hardware wallet if they have one. No crypto exchange had publicly reported a breach tied to PHP2Shell as of October 22.

Is it safe to browse?

Browsing the web was broadly as safe as it had been the previous week, although no internet activity is risk-free. The main exposure was on servers that had not been patched. Security company Mallory counted roughly 884,000 internet-facing hosts running PHP versions that no longer receive an official fix.

Amazon urged defenders not to assume that the public disclosure date was the earliest date of exploitation. “Defenders should not assume the public disclosure date is the earliest date of exploitation,” the company said. Any server that had run a vulnerable PHP version since at least October 17 should be investigated, not merely patchedn
Original source: Decrypt