The PHP security crisis has pushed government websites offline and prompted urgent U.S. warnings about flaws that could let attackers take control of vulnerable servers. Emergency patches are available, but the scramble has exposed a deeper problem: warning signs behind one vulnerability surfaced in 2024.

The PHP project released security updates Oct. 21 for two critical vulnerabilities. Under certain conditions, attackers can exploit them without a password or an account on the targeted website.

The PHP Foundation has acknowledged that technical disagreements and limited resources delayed a fix. Meanwhile, security companies have reported attack attempts, including activity Amazon traced to four days before the patches became public.

Government websites go offline as agencies sound alarms

The Associated Press reported that the FBI’s cyber division urged operators to update immediately or take websites offline. The Finnish government’s website was partly unavailable Wednesday, displaying a notice about temporary disruptions affecting government websites.

Those disruptions illustrate the immediate consequences for people trying to access public information and services. They do not, by themselves, establish that hackers successfully breached the affected systems.

The Netherlands’ National Cyber Security Centre confirmed that it temporarily removed its own website from service as a precaution. Other organizations, including government agencies, also shut down websites preventively.

In an Oct. 22 update, the Dutch agency said several websites had returned online following the availability of patches. It continued to urge organizations to keep vulnerable systems offline until they installed the updates.

The agency also said it had no indications of successful exploitation in the information available to it. That assessment is limited to its observations; it does not establish that every affected system worldwide escaped attack.

In the United States, the National Security Agency recommended taking systems offline when an immediate update is not feasible. Its guidance also calls for identifying services that depend on vulnerable PHP versions, monitoring vendor updates and considering enhanced logging.

The NSA’s warning concerns systems operated by organizations using PHP. It does not establish that the agency took its own website offline.

Why the PHP security crisis reaches so widely

PHP is a programming language used on web servers to power websites and applications. Visitors generally interact with the resulting pages, forms and services without seeing the software underneath them.

That makes PHP an easily overlooked dependency with an enormous footprint. W3Techs’ Oct. 22 measurements show PHP on 69.3% of websites whose server-side programming language it can identify.

The qualification matters. That figure measures PHP usage within the sites the service can classify. It is not a count of compromised websites, nor does it mean that roughly 70% of the internet has been hacked.

The vulnerabilities, collectively called PHP2Shell, are tracked as CVE-2026-109618 and CVE-2026-109619. They involve the way PHP handles memory and errors, placing the weakness beneath the individual website application.

PHP’s advisory identifies all installations serving web requests as potentially at risk. It considers the risk highest for Apache configurations using a component called mod_php, where researchers demonstrated an attack before the website’s application code begins running.

In practical terms, a website can have carefully maintained application code and still depend on a vulnerable underlying PHP installation. The security of that lower layer requires its own attention.

Amazon detected an attempt before the public release

The attack timeline adds urgency to the response.

Amazon Threat Intelligence reported an exploitation attempt dated Oct. 17, four days before public disclosure and the release of patches. Its MadPot monitoring system detected the activity against a honeypot, a decoy system designed to observe attackers.

Amazon said the attempt came from infrastructure associated with a commercial anonymization network. It remains unclear how the actor obtained exploit information before disclosure.

The company also identified additional attempts before the coordinated release on Oct. 21. Different attack payloads and infrastructure suggested multiple actors.

However, Amazon explicitly said its technical analysis was continuing and that it was unclear whether those early attempts would have succeeded against real-world systems. It described broader exploitation after disclosure, when additional demonstration exploits appeared and quickly reached its sensors.

That distinction leaves organizations with two separate responsibilities: close the vulnerability and investigate whether anyone already used it. The public announcement date cannot safely serve as the starting point for every investigation.

Cloudflare also reported attack traffic targeting its customers. The company said attackers changed their requests in attempts to evade its protections.

Together, those accounts establish hostile activity around the vulnerabilities. They do not provide a verified global total of organizations breached or records stolen.

The warning signs appeared in 2024

The PHP Foundation’s account of the delayed fix traces the memory-exhaustion problem behind one vulnerability to work following a 2024 security audit. A developer identified warning signs, but researchers had not established a concrete route to exploitation.

Proposed fixes carried difficult trade-offs, including compatibility problems and the potential to introduce other failures. A small group of developers with competing responsibilities struggled to reach agreement, and work repeatedly stalled.

The foundation called the delay a “structural failure,” attributing it to decision-making and insufficient resources.

On Aug. 11, 2026, researchers demonstrated remote code execution tied to the same underlying problem. The foundation said resolving it then became its security team’s highest priority.

Its response includes changes to decision-making and an appeal for sustained funding from businesses, hosting providers and governments that depend on PHP.

That chronology documents a failure to resolve a known concern promptly. It does not establish that maintainers understood the full exploitability in 2024 and deliberately chose to leave users exposed.

AI helped researchers demonstrate the danger

Artificial intelligence played a significant role in the research, according to Wiz’s technical account of PHP2Shell.

Wiz said advanced models helped researchers work through complex steps needed to demonstrate exploitation of longstanding weaknesses. The company described a collaborative effort involving vulnerability discovery, defensive measures and verification of the patch.

The distinction between a flaw’s age and its discovery is essential. Software can contain a weakness for years before researchers establish a reliable way to exploit it. New tools can change that calculation without changing the age of the underlying code.

Wiz identified PHP’s use in major publishing platforms, including WordPress, Drupal, Joomla and MediaWiki. That shared dependency helps explain why the response extends across otherwise unrelated websites. It does not establish that every installation of those platforms suffered a breach.

USA Herald previously examined warnings about AI accelerating cybersecurity threats. The PHP emergency brings those concerns into a concrete maintenance problem: defenders need to turn discoveries into protections that website operators can actually install.

Website owners need to check the underlying software

For website owners, updating a publishing platform or installing the latest plugin does not resolve this particular problem by itself. Cloudflare’s guidance says the PHP software running the application must receive the security fix.

That means a business owner, newsroom or nonprofit may need confirmation from its hosting provider. The useful question is whether the PHP environment serving the website has received fixes for both identified vulnerabilities.

A general assurance that a website is “up to date” leaves too much ambiguity. Application updates and server software updates address different parts of the system.

The PHP project released fixes in versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Linux distributions and long-term-support vendors may supply updated packages through their own channels.

PHP 8.1 and earlier no longer receive routine support from the project. Because of the severity, developers also supplied limited source-code backports for PHP 7.4, 8.0 and 8.1. Operators of older systems should verify their vendor’s fix or upgrade to a supported release.

Temporary protections leave work to do

AWS’s mitigation guidance explains that web application firewalls can reduce exposure to certain attack paths while administrators patch. Those protections have limits because they cannot fully inspect PHP’s internal memory or every relevant server-side condition.

The practical response therefore starts with identifying where PHP runs, obtaining the appropriate updates and checking that applications work with the patched software. Temporary filtering can support that process, but it cannot establish that the underlying vulnerability has disappeared.

Organizations also need to distinguish between restoring availability and confirming security. A website loading normally shows that it is reachable. That observation alone says nothing about its patch status or whether an earlier intrusion occurred.

What the crisis means for people using these websites

For readers encountering an unavailable government portal or business website, the outage may reflect a deliberate protective measure. The Dutch agency’s account demonstrates why a shutdown should not automatically be described as a successful cyberattack.

At the same time, bringing a website back online does not answer every question about historical exposure. Organizations need to communicate what they have established: whether they shut down preventively, whether they installed the fixes and whether their investigation found evidence of unauthorized access.

The available reports do not establish that every PHP website leaked personal information. They do establish a serious vulnerability, active attempts to exploit it and an urgent need for operators to verify their systems.

The next measure of the response will be more than how quickly websites return. It will be whether organizations can account for their exposure, explain what their investigations found and give the people who depend on their services accurate information about any consequences.