Le début d’une cyberapocalypse ? L’IA accélère les attaques et PHP2Shell déclenche une nouvelle alerte

L'apocalypse cybernétique ne commencera probablement pas comme dans les films, avec tous les ordinateurs éteints en même temps. Elle peut commencer d’une manière bien plus banale : un site web non mis à jour, une faille critique et des criminels capables d'automatiser une partie de leur travail grâce à l'intelligence artificielle.

Le 21 octobre 2026, l'équipe PHP a publié des mises à jour pour deux failles qui pourraient permettre à un attaquant d'exécuter du code sur un serveur sans avoir besoin d'un mot de passe. Les autorités européennes ont demandé une action urgente. Parallèlement, des recherches récentes documentent comment certains cybercriminels utilisent l'IA pour accélérer la recherche de cibles, préparer les outils et exécuter des opérations à plus grande échelle.

Sommes-nous face à la fin d'Internet ? Non. Face à un changement préoccupant dans les règles du jeu ? Il y a des raisons de le prendre au sérieux. Mais attention à mélanger les faits : il n'y a pas, dans les sources consultées pour cet article, de preuves que l'IA ait généré les failles PHP2Shell ni que toutes les attaques contre elles soient dirigées par l'IA. Cela ne signifie pas non plus que tous les sites web utilisant PHP ont été compromis.

Ce qui s'est passé

Les failles, identifiées comme CVE-2026-109618 et CVE-2026-109619 et connues collectivement sous le nom de php2shell, sont liées à la gestion de la mémoire de l’interpréteur PHP lui-même. Dans certaines circonstances, une requête HTTP préparée par un attaquant peut provoquer une situation permettant d'exécuter des instructions non autorisées, d'exposer des informations ou d'interrompre le service.

L'avertissement officiel du projet PHP identifie comme potentiellement exposées les installations qui traitent des requêtes web, y compris les configurations avec PHP-FPM, Apache mod_php, php-cgi, FrankenPHP et LiteSpeed. L'équipe de sécurité considère particulièrement grave le risque dans mod_php, pour lequel une voie d'exploitation a été démontrée avant même que le code de l'application ne soit exécuté.

Le 21 octobre, la Commission européenne, ENISA, CERT-EU, Europol et le réseau européen des équipes de réponse aux incidents ont émis un communiqué conjoint. Leur recommandation : identifier où PHP est utilisé, appliquer les versions corrigées et donner la priorité aux applications accessibles depuis Internet.

L'IA entre de mauvaises mains : le facteur qui peut multiplier le problème

Jusqu'à récemment, préparer une campagne d'intrusion à grande échelle exigeait du temps, de l'expérience et beaucoup de travail humain. L'IA n'élimine pas ces barrières, mais peut réduire une partie des efforts : aider à analyser les systèmes exposés, adapter les outils, automatiser les vérifications et traiter les données volées. Ce n'est pas une hypothèse tirée d'un film.

Dans son rapport sur les menaces de septembre 2026, Anthropic a documenté des opérations qu'il avait détectées et interrompues dans lesquelles certains attaquants utilisaient des modèles d'IA pour accélérer les tâches de reconnaissance, le développement d'outils et l'exploitation. Le Centre national de cybersécurité de Nouvelle-Zélande, dans son rapport sur les menaces de 2026, alerte également sur l'accélération et l'échelle que l'IA peut apporter aux activités malveillantes.

Cela importe lorsqu'une faille généralisée comme PHP2Shell apparaît : une même faiblesse peut être recherchée par des attaquants qui automatisent l'identification de cibles potentielles. Ce risque général ne démontre pas qu'une campagne spécifique sur PHP2Shell utilise l'IA ; c'est le contexte dans lequel les entreprises et les administrateurs doivent agir.

La paradoxe est que l'IA aide également les défenseurs à analyser les journaux, localiser les systèmes non mis à jour et répondre plus rapidement. La différence ne marque pas une intelligence malveillante supposée, mais qui l'utilise, avec quels contrôles et combien de temps chaque organisation met pour corriger ses points faibles.

Quels sites web et entreprises pourraient être concernés ?

Le problème réside dans le environnement d'exécution PHP, et non dans un plugin spécifique. C'est pourquoi des sites web construits avec WordPress, Magento ou d'autres applications dépendant d'une installation vulnérable de PHP peuvent être touchés. Mettre à jour uniquement WordPress ou ses extensions ne remplace pas la mise à jour de l'interpréteur PHP.

Les principaux acteurs potentiellement affectés sont les administrateurs de sites web, les hébergeurs, les boutiques en ligne, les agences qui gèrent des pages pour des tiers et les organisations avec des applications internes accessibles depuis Internet.

Si votre site web utilise Next.js, React ou Node.js sans exécuter PHP sur le serveur, ces deux failles ne l'affectent pas directement simplement par le fait d'utiliser ces technologies. Néanmoins, un serveur peut héberger en outre d'autres applications ou services basés sur PHP. Il faut vérifier ce qui est réellement installé, et non déduire cela uniquement à partir de l'apparence de la page publique.

Il est également important de comprendre la différence entre trois choses : une installation vulnérable, une tentative d'attaque et une intrusion confirmée. Elles ne sont pas équivalentes. Le fait qu'une entreprise bloque des milliers de requêtes malveillantes ne démontre pas qu'elle ait volé des milliers de bases de données.

Pour approfondir la sécurité de votre site, consultez notre guide pour sécuriser un serveur Apache et notre analyse distincte de vulnérabilités du cœur de WordPress. Ces problèmes sont différents de PHP2Shell et ne remplacent pas les correctifs PHP.

Que faire aujourd'hui si vous administrez un site web

1. Vérifiez si votre serveur exécute PHP. Vérifiez-le via le panneau d'hébergement ou demandez au fournisseur de confirmer l'interprète installé sur chaque domaine ou service. Si vous utilisez un hébergement géré, ne présumez pas que la mise à jour s'applique automatiquement.
2. Vérifiez la version et les correctifs du fournisseur. Le projet PHP a publié le 21 octobre les versions 8.5.12, 8.4.27, 8.3.36 et 8.2.35 pour corriger ces deux failles. Sur les distributions Linux avec support prolongé, une correction peut être intégrée dans un paquet dont la numérotation apparente est antérieure : demandez confirmation du fabricant avant de tirer des conclusions.
3. Priorisez les applications publiques. L'ENISA recommande d'intervenir en priorité sur les services accessibles depuis Internet. Si vous ne pouvez pas les corriger immédiatement et que le risque le justifie, envisagez de restreindre temporairement l'accès jusqu'à l'application du correctif.
4. Maintenez les protections réseau, mais ne les confondez pas avec une réparation. Un pare-feu d'applications web (WAF) peut bloquer certains tentatives. Cloudflare a annoncé des protections spécifiques contre php2shell. Cependant, tant Cloudflare que PHP insistent sur le fait que la mise à jour reste nécessaire.
5. Vérifiez les signes de compromission et conservez les preuves. Cherchez une activité anormale dans les logs HTTP et d'application, des modifications inattendues de fichiers, processus ou tâches, des accès inhabituels et des erreurs insolites. Aucune de ces indications ne prouve par elle-même une intrusion ; leur absence non plus ne garantit pas qu'aucune n'a eu lieu.

Si vous travaillez avec une agence ou un fournisseur d'hébergement, une question utile et précise est : « Avez-vous vérifié CVE-2026-109618 et CVE-2026-109619 sur tous les services PHP hébergeant mes domaines, et pouvez-vous confirmer la version corrigée ou le correctif équivalent ? »

Et si vous naviguez simplement sur Internet ?

Vous n'avez pas besoin d'installer PHP ni de rechercher ces vulnérabilités sur votre téléphone pour visiter une page. Il s'agit d'un problème des serveurs qui exécutent PHP. Le risque pour un utilisateur apparaît si un site web stockant ses données finit par être compromis, ce qui devra être confirmé au cas par cas.

Pour l'instant, maintenez vos appareils et votre navigateur à jour, évitez les liens promettant des supposées « outils d'urgence » et portez attention aux communications officielles des services que vous utilisez. Un message alarmant sur les réseaux sociaux n'est pas une preuve que vos informations ont été fuites.

Que faire si vous soupçonnez que votre serveur est déjà compromis

Une mise à jour corrige la vulnérabilité, mais n'élimine pas nécessairement une intrusion déjà produite. S'il y a des indices fondés d'accès non autorisé, évitez de supprimer les logs ou de réinstaller précipitamment sans préserver les preuves. Isolez le système affecté selon le plan de réponse, analysez les accès et les données potentiellement exposées, annulez ou invalidez les identifiants qui auraient pu être compromis et restaurez depuis un point vérifié si nécessaire. Si cela concerne des données personnelles, évaluez les obligations légales de notification.

En Espagne, vous pouvez recourir aux ressources et canaux d'aide de INCIBE et, le cas échéant, aux équipes de réponse aux incidents compétentes. Pour les incidences liées à la protection des données, l'AEPD fournit des informations sur la gestion et la notification des brèches.

Est-ce le début de l'« apocalypse cybernétique » ?

Il n'y a pas de preuves d'une chute générale d'Internet. Il y a deux vulnérabilités graves dans une technologie très répandue, un paysage de menaces où certains délinquants utilisent déjà l'IA et des organisations doivent corriger leurs serveurs rapidement. Ce sont des faits distincts qui, ensemble, justifient une attention ; ce n'est pas une prophétie de effondrement.

S'il y a une scène inquiisante ici, ce n'est pas une machine qui se révolte : c'est la facilité avec laquelle une faiblesse connue peut rester exposée pendant que l'attaquant automatise des tâches et le responsable du site web n'a toujours pas vérifié ses mises à jour.

La réponse reste assez terrestre : identifier les installations affectées, appliquer les correctifs et vérifier s'il y a des indices d'exploitation. La peur vend des clics ; réparer les serveurs évite les problèmes.

Sources officielles et techniques consultées (21–22/10/2026)

• PHP Security Team, avis du 21/10/2026. Versions corrigées, portée technique et mesures provisoires : https://www.php.net/archive/2026.php
• ENISA et organismes de l'UE, communiqué conjoint du 21/10/2026. Risque d'exécution à distance et priorité de mise à jour : https://www.enisa.europa.eu/news/joint-statement-on-critical-php-vulnerabilities
• Cloudflare, 21/10/2026. Description technique et mesures WAF : https://blog.cloudflare.com/php-vulnerabilities-waf-protection
• Anthropic, rapport d'intelligence sur l'abus d'IA (septembre 2026). Cas documentés d'assistance IA dans des opérations malveillantes : https://www.anthropic.com/threat-intelligence-report-september-2026
• NCSC de Nouvelle-Zélande, Cyber Threat Report 2026. Évaluation de l'impact de l'IA sur la vitesse et l'échelle des cyberattaques : https://www.ncsc.govt.nz/insights-and-research/cyber-threat-reports/cyber-threat-report-2026/
• INCIBE, canal officiel espagnol : https://www.incibe.es/
• AEPD, autorité espagnole de protection des données : https://www.aepd.es/

Vous pourriez également être intéressé

• Alerte sur la vulnérabilité d'injection SQL dans Sequelize affectant les applications web
• Microsoft prépare davantage de correctifs de sécurité avec l’IA
• Vulnérabilité SSRF non authentifiée dans SeaweedFS permettant la falsification de requêtes côté serveur