IA et cyberattaques : ce qui s’est passé ces dernières semaines

Ces dernières semaines, des sites publics ont été fermés par précaution, des entreprises ont subi des vols de données et des chercheurs ont révélé des failles avec l’aide de l’intelligence artificielle. Ces événements ont des causes et des chronologies différentes. Ce dossier revient sur ce qui s’est passé, explique le rôle de l’IA et précise les conséquences pour les utilisateurs.

Pour comprendre pourquoi cela compte, il faut partir des conséquences : un service inaccessible, des données de clients volées, une boutique dont la page de paiement a été piégée. Puis regarder, pour chaque incident, ce qui est réellement établi. Ce dossier explique les faits sans supposer de connaissances informatiques.

Publié le 24 octobre 2026. Texte et carrousel entièrement revus le 26 octobre 2026, avec la mise à jour du CERT-FR publiée ce jour.

1. Que s’est-il passé ? Une pièce commune à beaucoup de sites est vulnérable

Quand vous ouvrez un site, un ordinateur distant prépare et vous envoie son contenu. Cet ordinateur s’appelle un serveur. PHP est l’un des logiciels qui lui permettent de fabriquer les pages. Il est notamment utilisé par WordPress, un outil très répandu pour créer des sites.

Imaginez plusieurs immeubles équipés du même modèle de serrure. Si cette serrure présente un défaut, le problème peut concerner beaucoup de bâtiments. Avec PHP, c’est une pièce logicielle commune qui est en cause. Les sites peuvent avoir des propriétaires différents et partager le même point faible.

Le 21 octobre, PHP a publié des correctifs pour deux failles, regroupées sous le surnom PHP2Shell. Dans certaines conditions, elles permettent à un attaquant de faire exécuter ses instructions sur le serveur sans disposer d’un compte ni d’un mot de passe. Les identifiants techniques de ces failles sont CVE-2026-109618 et CVE-2026-109619. Annonce officielle PHP.

Les chercheurs de Wiz ont également démontré la lecture de données présentes dans la mémoire du logiciel. Les conséquences possibles incluent des données dérobées ou un site modifié. Une démonstration sur un environnement donné ne signifie cependant pas que tous les sites se piratent de la même manière. Travaux de Wiz.

Au 26 octobre, W3Techs relève PHP sur 69,2 % des sites dont il identifie le langage côté serveur. Ce chiffre explique l’ampleur de la mobilisation. Il ne signifie pas que 69,2 % d’Internet a été piraté. Mesure et périmètre W3Techs.

2. Pourquoi parle-t-on d’un tournant pour la cybersécurité ?

Les failles informatiques existaient avant l’IA. Ce qui change ici, c’est la capacité à transformer des défauts complexes et anciens en attaques démontrables. Wiz explique que le code concerné était présent depuis plus de dix ans et que l’IA a aidé à adapter des démonstrations à plusieurs applications en quelques heures. Le travail associait recherche humaine, outils et modèles d’IA. Explication des chercheurs.

L’image utile est celle d’une enquête. Repérer une porte abîmée ne suffit pas à prouver qu’on peut entrer. Il faut comprendre le mécanisme, essayer une hypothèse, constater l’échec, puis ajuster. L’IA aide à parcourir ces étapes. C’est cette capacité d’analyse et d’itération qui compte, bien davantage que la formule « l’IA a trouvé un bug ».

Il faut aussi corriger un raccourci : les humains n’avaient pas forcément « rien vu ». Calif indique qu’un problème lié avait été identifié lors d’un audit en 2024, sans preuve d’exploitation. Son chercheur explique avoir utilisé sa connaissance de l’histoire de PHP pour orienter l’IA. Il précise qu’une simple demande à un modèle ne permet pas de découvrir tous les défauts. Récit de Calif.

Le mot « historique » exprime donc une appréciation : cet épisode illustre un changement d’échelle dans la recherche et l’exploitation de failles. Il ne constitue pas un classement officiel des pires attaques. Le point décisif est que des protections autrefois difficiles à contourner peuvent devenir plus faciles à analyser, pour les défenseurs comme pour leurs adversaires.

3. La découverte et l’annonce publique n’ont pas eu lieu le même jour

La chronologie évite de donner l’impression que tout Internet a basculé en une nuit :

• Début août : Calif situe ses premières découvertes au 1er août, puis son premier signalement à PHP au 11 août. Chronologie Calif.
• 19 août : Wiz situe une découverte indépendante, suivie de son signalement le 24 août. Chronologie Wiz.
• 21 octobre : les correctifs et les explications deviennent publics. Les équipes avaient travaillé à une réponse coordonnée pour préparer les protections avant cette publication. OpenAI décrit ce travail dans son initiative « Patch the Planet ». Présentation de la coordination.
• 26 octobre : le CERT-FR confirme observer des tentatives d’exploitation visant certains déploiements de PHP. Alerte française actualisée.

Préparer un correctif avant l’annonce publique donne une avance aux défenseurs. Encore faut-il que les propriétaires de serveurs l’installent. Une mise à jour disponible ne protège pas automatiquement tous les sites.

4. Pourquoi des sites publics ont-ils été coupés ?

Fermer temporairement un service peut être une mesure de protection. C’est l’équivalent d’interdire l’accès à un bâtiment pendant que l’on remplace une serrure défectueuse.

Les Numériques rapporte des mises en maintenance préventives de sites publics français le 21 octobre, notamment des préfectures. Le NCSC néerlandais confirme avoir lui-même coupé son site par précaution. Dossier des Numériques · Avis du NCSC-NL.

Il faut distinguer trois choses : une tentative, où quelqu’un essaie d’entrer ; une intrusion, où il obtient effectivement un accès ; un vol de données, où il récupère des informations. Une page de maintenance, à elle seule, ne prouve aucune de ces trois étapes.

Inversement, on ne peut pas affirmer que personne n’a tenté d’attaquer. Amazon a observé une tentative dès le 17 octobre sur ses systèmes servant à détecter les attaques, tout en précisant que la réussite de ces essais sur des systèmes réels restait à déterminer. Le CERT-FR constate désormais aussi des tentatives. Observations d’Amazon · CERT-FR, 26 octobre.

5. Comment les pirates utilisent-ils des agents IA ?

Un assistant classique répond à une question. Un agent IA peut aussi utiliser des outils et enchaîner des actions : examiner une cible, lancer un test, lire le résultat et choisir la suite. Il peut recommencer quand une piste échoue. Un humain définit l’objectif, choisit des cibles et peut intervenir.

NorForge décrit cette organisation après avoir examiné plus de vingt interfaces de pilotage exposées sur Internet et probablement liées à des activités malveillantes. L’intérêt pour le pirate est de déléguer une partie des essais répétitifs et d’en mener plusieurs en parallèle. Ce n’est pas une garantie de réussite : les pistes peuvent échouer. Enquête NorForge du 19 octobre.

Trois enquêtes permettent de voir ce que cela signifie concrètement.

Des boutiques en ligne et des données de cartes bancaires

Gambit rapporte 105 projets d’attaque lancés entre le 10 et le 15 septembre, avec au moins 27 entreprises compromises à des degrés divers. Sur l’ensemble de la campagne étudiée, l’équipe rapporte plus de 600 000 enregistrements de cartes bancaires dérobés à deux entreprises. Elle a également identifié des programmes destinés à copier des données de paiement sur des sites.

Le chiffre d’environ 25 dollars souvent cité correspond à une moyenne déclarée pour 101 scans terminés. Il ne représente ni le prix garanti d’un piratage, ni le coût total de la campagne. Le rapport est provisoire et distingue preuves directes et informations tirées des journaux des agents. Rapport Gambit du 22 septembre.

Des organismes financiers en Corée du Sud

CrowdStrike décrit une campagne menée de fin septembre à début octobre contre des organismes financiers sud-coréens, avec des données dérobées. Les chercheurs ont retrouvé des configurations et des historiques d’utilisation d’agents IA. Leur rapport ne permet pas de conclure que tous les comptes des clients ont été vidés. Cette campagne précède la publication des failles PHP et doit être examinée séparément. Rapport CrowdStrike du 7 octobre.

Des accès déjà accordés à une application connectée

Microsoft documente l’utilisation d’ARTEX, un outil d’agents IA, par le groupe Storm-0940. Certaines opérations ont permis d’obtenir des accès privilégiés en moins de trois heures. Le groupe a notamment exploité les accès d’applications ConnectWise déjà autorisées dans des environnements Microsoft 365. Cela lui permettait d’agir sans connexion interactive de l’utilisateur. Microsoft précise que l’activité ne provenait pas d’une faille de ses propres produits. Analyse Microsoft du 21 octobre.

La conséquence pratique est simple : une application connectée possède ses propres droits. Un mot de passe solide reste nécessaire, mais il ne remplace pas la vérification des accès accordés.

6. Et les certificats, les autres failles, le « Black October » ?

Un autre incident touche eMudhra, une entreprise qui délivre des certificats numériques. Ces certificats participent à l’authentification des sites lors d’une connexion HTTPS. Mozilla confirme que les clés de huit certificats intermédiaires étaient compromises. Elles pouvaient servir à produire de faux certificats. Un attaquant capable d’intercepter une connexion aurait alors pu usurper un site et lire ou modifier le trafic. Mozilla a bloqué les certificats concernés. Explication de Mozilla.

Cet incident touche la confiance accordée aux certificats ; PHP touche le fonctionnement de serveurs. Ce sont deux mécanismes différents. De même, une campagne criminelle, une découverte par des chercheurs et un comportement problématique d’IA pendant un test ne sont pas interchangeables.

GitLab, utilisé pour héberger et gérer le code de logiciels, a également publié le 21 octobre un correctif pour sa propre faille critique, CVE-2026-110264. Elle pouvait permettre l’exécution d’instructions sans connexion préalable dans certaines conditions. L’éditeur demande aux organisations qui gèrent leur installation de la mettre à jour ; GitLab.com avait déjà été corrigé. Il s’agit d’un dossier distinct de PHP2Shell. Bulletin GitLab.

LiteLLM, un composant employé par des développeurs pour relier leurs applications à des modèles d’IA, a diffusé une version piégée le 21 octobre. Les fichiers concernés ont été retirés et l’éditeur a publié une enquête corrigée le 23 octobre. Ici, le danger venait d’un logiciel distribué avec du contenu malveillant. Utiliser un assistant IA grand public ne signifie pas que l’on a installé cette version de LiteLLM. Périmètre de l’incident · Enquête actualisée.

« Black October » est une expression circulant sur les réseaux. Les sources examinées ne démontrent pas une offensive unique derrière tous ces événements. Certaines campagnes ont commencé bien avant octobre. Un grand nombre d’annonces ne permet pas de calculer un pourcentage mondial de sites piratés.

Notre lecture : ce mois illustre une accélération à prendre au sérieux. La formule « la moitié d’Internet est piratée » dépasse les preuves présentées. Le risque doit être expliqué par ses mécanismes et ses conséquences, pas par un classement spectaculaire.

7. Ce que vous pouvez faire dès maintenant

Si vous êtes un particulier

• Mettez vos appareils et navigateurs à jour. Passez par leurs réglages habituels ou le site officiel de l’éditeur.
• Protégez votre messagerie. Activez une deuxième vérification à la connexion lorsque le service la propose, par exemple avec une application d’authentification.
• Gardez un mot de passe différent par compte. Un gestionnaire de mots de passe peut les créer et les retenir.
• Vérifiez les messages alarmants. Ouvrez directement votre application bancaire ou le site habituel. Une demande urgente de « sécurisation » peut elle-même être une arnaque.
• Conservez des sauvegardes séparées de vos documents importants. Elles aident à récupérer après une panne ou une attaque.

Ces mesures reprennent les recommandations de l’ANSSI. Elles protègent vos usages. Elles ne réparent pas le serveur d’une entreprise à sa place.

Si un compte est effectivement piraté, utilisez le service officiel de récupération, changez son mot de passe ainsi que ceux des comptes où vous l’aviez réutilisé, vérifiez les connexions et les informations de récupération. Conservez les preuves. Si des coordonnées de paiement ont été dérobées ou qu’un débit suspect apparaît, contactez votre banque par votre canal habituel. Fiche pratique de Cybermalveillance.gouv.fr.

Si vous avez un site professionnel

Demandez à votre hébergeur ou à la personne qui entretient votre site de vérifier PHP, y compris dans les outils secondaires. Les versions correctives annoncées le 21 octobre sont 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Certains fournisseurs appliquent le correctif à une version conservant un autre numéro : demandez une confirmation explicite. Un complément du 23 octobre, CVE-2026-115560, concerne une combinaison particulière de réglages et de code ; il doit aussi être examiné. Consignes PHP.

Bonjour, pouvez-vous vérifier si mon site et ses services utilisent PHP ? Si oui, merci de confirmer l’application des correctifs publiés le 21 octobre 2026, de vérifier si l’avis complémentaire du 23 octobre concerne notre configuration et de préciser si des traces d’intrusion ont été recherchées. Merci de m’indiquer aussi si nos sauvegardes permettent une restauration.

Le CERT-FR recommande d’appliquer les correctifs et renvoie aux mesures d’endiguement pour les équipements concernés. En cas de suspicion d’intrusion, faites intervenir votre prestataire pour préserver les traces et traiter l’incident. Installer un correctif ferme une faille ; cela ne démontre pas, à lui seul, qu’aucun accès malveillant n’avait déjà été obtenu. Alerte et recommandations du CERT-FR.

Si vous utilisez un assistant IA connecté à vos outils

Un connecteur est un lien entre l’assistant et un service, comme votre messagerie ou vos documents. Vérifiez les services connectés et les droits accordés : lire, modifier ou envoyer sont des pouvoirs différents. Retirez les accès inutiles et conservez une validation humaine pour les actions importantes. La documentation de Claude décrit les contrôles disponibles selon le compte.

8. Ce que cet épisode change pour la suite

Un logiciel ancien et connu peut encore cacher un défaut sérieux. L’IA peut aider à le révéler et à vérifier une réparation. Elle peut aussi aider un attaquant à essayer davantage de chemins plus rapidement.

La réponse ne repose donc pas sur un réglage magique. Elle demande des logiciels entretenus, des accès limités, des sauvegardes et des équipes capables de réagir. Pour le grand public, l’essentiel est de comprendre qui doit agir : vous sur vos comptes et appareils, votre prestataire sur votre site, les éditeurs sur leurs logiciels.

Cette préparation concerne aussi les États. Le Royaume-Uni a annoncé le 12 octobre des travaux pour renforcer ses défenses avec l’IA et se préparer à des incidents impliquant des agents autonomes. Une annonce de préparation décrit une réponse à un risque ; elle ne prouve pas qu’une catastrophe mondiale est en cours. Annonce du gouvernement britannique.

Sources et méthode

Les liens sont placés près des faits qu’ils permettent de vérifier. Les annonces de PHP, le CERT-FR et les travaux des chercheurs sont privilégiés. Les chiffres décrivent les campagnes étudiées, avec leurs limites ; ils ne sont pas extrapolés à tout Internet. Les appréciations sur le caractère historique sont distinguées des faits mesurés.

Le dossier des Numériques du 25 octobre a servi de point de départ à cette recherche, complétée par les sources originales. La vidéo de Vision IA du 24 octobre constitue une ressource complémentaire proposée par le lecteur ; sa transcription intégrale n’étant pas accessible lors de cette vérification, aucune affirmation n’est validée sur sa seule base.

Dernière vérification : 26 octobre 2026. Les enquêtes et avis de sécurité peuvent évoluer. Les images conceptuelles utilisées pour illustrer le carrousel ont été générées par IA et ne montrent pas les incidents réels.