A PHP web shell flaw supposedly hit 70% of websites, but the real issue is how AI-discovered bugs get patched. Here's what the evidence actually supports.
What is the PHP web shell flaw and is it real?
No primary source has confirmed a mass PHP vulnerability that took down most of the web, so the widely shared "70% of the internet" claim should be treated as unverified. The PHP group publishes its own security announcements, and any genuine flaw affecting sites running PHP would normally appear there first.
PHP is the server-side scripting language that powers content management systems such as WordPress and many custom web applications. WordPress alone runs a large share of websites, which is the origin of the popular 70% figure. That figure describes site usage, not the number of sites affected by any single bug.
The claim that a flaw called something like "PHP2shell" had existed since about 2012 and was exploited four days before disclosure came from a television interview, not from a published advisory. The official PHP security page is the place to check before acting on any such warning.
How AI models would change vulnerability discovery
Large language models can generate candidate inputs and review code at a scale that human reviewers cannot match, so it is plausible that AI tools would surface subtle flaws. No published demonstration has yet shown a named model independently discovering a real remote code execution bug in PHP itself.
Two claims from the interview need care. The first is that AI found the bug. The second is that two teams using different chatbot models found it separately around August. Neither claim can be verified without a technical write-up, a disclosure timeline, or a maintainer confirmation.
What is well documented is that researchers already use fuzzing and static analysis to find memory corruption and injection bugs. Models can assist that work, but they have also been shown to produce confident-sounding findings that do not reproduce.
Who is responsible for patching quickly?
Site owners are responsible for patching, and the practical fix is the same for almost every PHP vulnerability: update PHP, update the application, and remove unused plugins. Hosting providers control the runtime version; the site owner controls the code running on it.
Web hosting platforms handle PHP updates on their own schedules, which is why two sites on the same code can be exposed differently. A managed host may patch within hours, while a self-managed server can stay on an outdated version for months.
Why the "70% of websites" number misleads
The 70% figure reflects how many sites run PHP, not how many were attacked, so using it as a damage estimate overstates the incident. W3Techs, which tracks server-side language usage, has reported PHP above 70% of sites it surveys for years. That is a usage statistic, not a breach count.
A website can run PHP and still be safe if the runtime is patched and the applications are maintained. The more useful question is how quickly the patch reaches shared hosting accounts, and that is usually days rather than minutes.
Treat any headline that converts usage share into victim share as a category error until a breach count exists.
What site owners should do after a PHP security warning
Treat any PHP security warning as real until the official advisory list says otherwise, and check your installed version first. The sequence below is the safe order for most teams.
FAQ
- Is 70% of the internet really at risk from a PHP bug? No verified source ties any specific PHP vulnerability to 70% of websites being attacked. The 70% is the share of surveyed sites that use PHP, tracked by W3Techs.
- Was the flaw found by AI? The claim comes from a television interview and has no published technical write-up behind it. Do not repeat it as fact until the discoverer or the PHP maintainers publish a timeline.
- Where do official PHP security warnings appear? The PHP security advisories page lists confirmed vulnerabilities with fixed versions. If a bug is not listed there, treat the claim as unconfirmed.
Fork this article
Start a new branch from the same video, shaped your way. You keep the credit; the original keeps the attribution.
A fork in another language is filed as a translation of this article, so the two pages point at each other. You can unlink it later from the editor.
0/240
You are creating
- Format
- For
- Language
- Source
- Your angle
You will be asked to sign in before it is generated.
Buy credits