No Password Needed: The Security Flaw Threatening Millions of Websites

Two critical flaws in PHP could allow attackers to take control of vulnerable website servers without a password. Here's what that means for everyone.

On 21 October, two serious security flaws were publicly disclosed in PHP, software used to make many websites work. Together, they are known as PHP2Shell. They could allow an attacker to take control of a vulnerable website's server, the computer running the site, without knowing a password or logging in.

Security updates are available. The urgent job for website owners is to install them before someone takes advantage of the flaws.

The speed of the attacks also raises a question I think we'll face more often: if AI helps attackers move faster, how much of our defence will need AI too?

What PHP does, and what went wrong

Think of a website as a restaurant. The pages you see are the dining room; PHP can be part of the kitchen, preparing what reaches your screen. It works behind the scenes to do things such as retrieve an order or display your account details. WordPress, Joomla and Drupal are among the website-building tools that use it. According to W3Techs, it was used by 69.3% of websites with an identifiable server-side programming language on 22 October. That is a measure of usage, not a count of hacked websites.

Normally, your browser asks the server for a page and receives a response. These flaws can let an attacker send a specially crafted request that confuses PHP's handling of memory and makes the server carry out instructions it shouldn't. The consequences could include stolen customer information or altered web pages, depending on what the server can access.

The PHP security team says installations handling website requests need updating. In one demonstrated attack, the problem occurs before the website's own code starts, including its login checks.

A good password is like a strong lock on your front door. This flaw is more like a weakness in the wall: someone may get inside without touching the lock. Passwords still matter, but they cannot fix this particular problem.

Illustration of a malicious website request breaking through a security barrier to reach a server

Conceptual illustration of an attack on a vulnerable server, not an actual incident screenshot.

Attacks were already happening

Amazon recorded an exploitation attempt on 17 October, four days before disclosure. It targeted a honeypot: a decoy computer set up to observe attackers. Amazon did not know how the attacker had obtained the information, or whether the attempt would have succeeded against a real website.

PHP warned of an emergency release on 20 October and issued security updates, often called patches, on 21 October. Cloudflare subsequently reported attempts rising from thousands before the announcement to hundreds of thousands within two hours afterwards, then millions.

Millions of attempts do not mean millions of websites were hacked. Automated tools can make repeated attempts against many sites. Those figures show the scale of the activity, not how many attacks succeeded.

Timeline of PHP2Shell's first recorded attack attempt, emergency preparation, security fixes and reports of millions of attack attempts

Timeline drawn from Amazon, PHP, Wikimedia and Reuters reporting. These are attempted attacks, not confirmed successful breaches.

Some organisations took services offline while applying fixes. Wikimedia's shutdowns affected supporting and cloud services; they were a precaution, not confirmation that Wikipedia had been hacked.

For the people managing websites, the earlier attempts matter: checking only for suspicious activity after the public announcement could miss part of the incident.

We'll probably need AI on the defensive side too

Amazon's analysis makes a useful point: artificial intelligence (AI) can help attackers compare a security update with the old software and work out which weakness was repaired. They can then try that weakness against websites that haven't updated yet. That leaves less time for their owners to react. It doesn't establish that every PHP2Shell attack was AI-generated.

I think we'll increasingly need AI to help prevent and respond to these incidents. A team can only read so many security warnings and investigate so many alerts in a day.

Before an attack, AI could help programmers find weaknesses while they're building and testing software. When a flaw is announced, it could help work out which of a company's websites need attention first. If an attack is suspected, it could examine thousands of activity records, known as logs, and highlight unusual behaviour for a person to investigate.

I would still want people checking its conclusions and testing suggested fixes. An AI system that mistakenly shuts down a service or changes the wrong setting can cause damage too. Its access should be limited, and changes should be reversible.

Conceptual illustration of defenders and attackers racing to protect or exploit a website

Illustration of AI-assisted attack and defence, not evidence of how a particular attack was carried out.

AI won't remove the need to know what software we're running or to keep it updated. My expectation is that it will become part of how we do that work quickly enough.

What to do now

If you own a website, ask the company hosting it, or the person maintaining it, whether PHP has received the security update. You don't need to install it yourself, but you do need someone to confirm it has been done.

For those managing the software directly, the emergency PHP releases were 8.2.35, 8.3.36, 8.4.27 and 8.5.12. Some providers supply equivalent fixes in their own packages. Updating website add-ons, such as WordPress plugins, does not necessarily update PHP itself.

Ask whoever manages the server to review activity dating back to at least 17 October. Installing a patch closes the vulnerability; it doesn't tell you whether someone used it earlier. PHP also lists temporary ways to reduce the risk, but says an update is the complete remedy.

For everyone else, the immediate target is the website's server, not your phone simply because you visited a PHP page. A compromised server can still expose your information or serve altered content. The useful precautions remain:

Use different passwords for important accounts and enable two-factor authentication: the extra check, such as a code from an app, when you sign in.
Treat unexpected security emails cautiously. Open the service directly rather than following a login or download link.
Watch for unusual account activity and follow verified notices from affected services.

There's also a separate incident involving eMudhra and digital certificates, which help browsers check that a website is genuine. It affects trust in secure connections, including in some Python tools, rather than being a flaw in Python itself. That deserves its own explanation.

For this incident, the most useful question a website owner can ask is simple: has the PHP installation actually been patched?

Sources and further reading

This article reflects public information available on 23 October 2026. PHP vulnerabilities: CVE-2026-109618 and CVE-2026-109619.