Is This the Start of a Cyber Apocalypse? AI Accelerates Attacks as PHP2Shell Raises the Alarm

The cyber apocalypse will probably not begin as in the movies, with all computers shutting down at once. It could start in a much more mundane way: an unpatched website, a critical vulnerability, and criminals capable of automating part of their work using artificial intelligence.

On October 21, 2026, the PHP team published updates for two flaws that could allow an attacker to execute code on a server without needing a password. European authorities have urged immediate action. At the same time, recent research documents how some cybercriminals use AI to accelerate target identification, prepare tools, and conduct operations at a larger scale.

Are we facing the end of the Internet? No. Are we facing a worrying shift in the rules of the game? There are reasons to take it seriously. But beware of mixing facts: there is no evidence, based on the sources consulted for this article, that AI originated the PHP2Shell vulnerabilities or that all attacks against them were directed by AI. It also does not mean that all websites using PHP have been compromised.

What has happened

The flaws, identified as CVE-2026-109618 and CVE-2026-109619 and collectively known as php2shell, relate to the memory management of the interpreter itself. Under certain circumstances, an HTTP request prepared by an attacker can create a situation that allows executing unauthorized instructions, exposing information, or disrupting service.

The official PHP project notice identifies installations serving web requests as potentially exposed, including configurations with PHP-FPM, Apache mod_php, php-cgi, FrankenPHP, and LiteSpeed. The security team considers the risk in mod_php especially grave, for which an exploitation path has been demonstrated even before the application code is executed.

On October 21, the European Commission, ENISA, CERT-EU, Europol, and the European Incident Response Team network issued a joint statement. Their recommendation: identify where PHP is used, apply the corrected versions, and prioritize applications accessible from the Internet.

AI in the wrong hands: the factor that could multiply the problem

Until recently, preparing a large-scale intrusion campaign required time, experience, and considerable human effort. AI does not eliminate those barriers, but it can reduce part of the effort: helping to analyse exposed systems, adapt tools, automate checks, and process stolen data. This is not a hypothesis taken from a movie.

In its September 2026 threat report, Anthropic documented operations that it had detected and interrupted in which certain attackers used AI models to accelerate reconnaissance tasks, tool development, and exploitation. The New Zealand National Cyber Security Centre, in its 2026 threat report, also warns of the increased speed and scale that AI can bring to malicious activities.

This matters when a widespread vulnerability like PHP2Shell appears: the same weakness can be sought by attackers automating the identification of potential targets. That general risk does not demonstrate that a specific PHP2Shell campaign used AI; it is the context in which companies and administrators must act.

The paradox is that AI also helps defenders analyse logs, locate outdated systems, and respond faster. The difference does not lie in supposed evil intelligence, but in who uses it, with what controls, and how long each organisation takes to correct its weak points.

Which websites and companies could be affected

The problem lies in the PHP execution environment, not in a specific plugin. Therefore, websites built with WordPress, Magento, or other applications depending on a vulnerable PHP installation could be affected. Updating only WordPress or its extensions does not replace updating the PHP interpreter.

The main potential affected parties are web administrators, hosting providers, online stores, agencies maintaining pages for third parties, and organisations with internal applications accessible from the Internet.

If your website uses Next.js, React, or Node.js without executing PHP on the server, these two flaws do not directly affect it simply by using those technologies. Nevertheless, a server may host other applications or services based on PHP. One must check what is actually installed, not deduce it solely from the public page's appearance.

It is also important to understand the difference between three things: a vulnerable installation, an attack attempt, and a confirmed intrusion. They are not equivalent. A company blocking thousands of malicious requests does not demonstrate that thousands of databases have been stolen.

For a broader website security review, read how to secure an Apache server and our separate analysis of WordPress core vulnerabilities. These are different issues from PHP2Shell and do not replace PHP security updates.

What to do today if you administer a website

1. Check whether your server runs PHP. Review this from the hosting panel or ask the provider to confirm the interpreter installed on each domain or service. If you use managed hosting, do not assume that updates are applied automatically.
2. Verify the version and vendor patches. The PHP project published versions 8.5.12, 8.4.27, 8.3.36, and 8.2.35 on October 21 to address both flaws. In Linux distributions with extended support, a correction may be included in a package whose apparent version number is earlier: ask the manufacturer for confirmation before drawing conclusions.
3. Prioritise public-facing applications. ENISA recommends addressing services accessible from the Internet first. If immediate correction is not possible and the risk warrants it, consider temporarily restricting access until the patch is applied.
4. Maintain network protections, but do not confuse them with a fix. A web application firewall (WAF) can block certain attempts. Cloudflare announced specific protections against php2shell. However, both Cloudflare and PHP insist that updating remains necessary.
5. Review signs of compromise and preserve evidence. Look for anomalous activity in HTTP and application logs, unexpected changes to files, processes, or tasks, unusual access patterns, and unexplained errors. None of these indicators alone prove an intrusion; nor does their absence guarantee that no intrusion has occurred.

If you work with an agency or hosting provider, a useful and specific question is: «Have you checked CVE-2026-109618 and CVE-2026-109619 on all PHP services hosting my domains, and can you confirm the corrected version or equivalent patch?»

What if you only browse the Internet?

You do not need to install PHP or search for these vulnerabilities on your mobile device just by visiting a page. This is a problem with servers that run PHP. The risk to a user arises if a website storing their data ends up compromised, which will have to be confirmed on a case-by-case basis.

In the meantime, keep your devices and browser updated, avoid links promising supposed «emergency tools», and pay attention to official communications from the services you use. An alarming message on social media is not proof that your information has been leaked.

What to do if you suspect your server is already compromised

An update corrects the vulnerability, but does not necessarily eliminate an intrusion already in progress. If there are well-founded indications of unauthorised access, avoid deleting logs or reinstalling hastily without preserving evidence. Isolate the affected system according to the response plan, analyse accesses and potential data exposure, revoke or rotate credentials that may have been compromised, and restore from a verified point if necessary. If it affects personal data, evaluate legal notification obligations.

In Spain you can access the resources and support channels of INCIBE and, where appropriate, competent incident response teams. For incidents related to data protection, the AEPD provides information on breach management and notification.

Is this the beginning of a «cyber apocalypse»?

There is no evidence of a general Internet outage. There are two critical vulnerabilities in a widely used technology, a threat landscape where some criminals already employ AI and organisations must correct their servers quickly. These are distinct facts that, together, justify attention; they are not a prophecy of collapse.

If there is something unsettling here, it is not a machine rebelling: it is the ease with which a known weakness can remain exposed while the attacker automates tasks and the website administrator has yet to review their updates.

The response remains quite grounded: identify affected installations, apply corrections, and check for signs of exploitation. Fear sells clicks; fixing servers prevents problems.

Official and technical sources consulted (21–22/10/2026)

• PHP Security Team, 21/10/2026 announcement. Corrected versions, technical scope, and provisional measures: https://www.php.net/archive/2026.php
• ENISA and EU agencies, joint statement of 21/10/2026. Remote execution risk and update priority: https://www.enisa.europa.eu/news/joint-statement-on-critical-php-vulnerabilities
• Cloudflare, 21/10/2026. Technical description and WAF measures: https://blog.cloudflare.com/php-vulnerabilities-waf-protection
• Anthropic, AI abuse intelligence report (September 2026). Documented cases of AI assistance in malicious operations: https://www.anthropic.com/threat-intelligence-report-september-2026
• New Zealand NCSC, Cyber Threat Report 2026. Assessment of the impact of AI on cyberattack speed and scale: https://www.ncsc.govt.nz/insights-and-research/cyber-threat-reports/cyber-threat-report-2026/
• INCIBE, official Spanish channel: https://www.incibe.es/
• AEPD, Spanish data protection authority: https://www.aepd.es/

You may also be interested in

• Alert about SQL Injection Vulnerability in Sequelize Affecting Web Applications
• Microsoft is preparing larger security patch cycles with AI
• Una una una SSRF Vulnerability in SeaweedFS Allows Server-Side Request Forgery