Le même jour, Microsoft a documenté l’usage d’un cadre d’agents d’intelligence artificielle par un acteur aligné sur l’État chinois contre des centaines d’organisations. Ces épisodes ne partagent pas de technique commune, mais ils illustrent comment l’automatisation modifie à la fois la découverte de vulnérabilités et la capacité offensive.
Le correctif de PHP et son échelle
Le 20 octobre, l’équipe de sécurité de PHP a annoncé une publication anticipée. Le 21 octobre, les versions 8.5.12, 8.4.27, 8.3.36 et 8.2.35 ont été diffusées. Elles corrigent CVE-2026-109618 (exécution de code à distance via corruption lors d’une condition de mémoire saturée) et CVE-2026-109619 (exécution de code à distance via état global obsolète). Les deux portent un score CVSS v4.0 de 9.2. Elles concernent les installations PHP qui traitent des requêtes web — PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP ou LiteSpeed — et le risque est jugé le plus élevé sous mod_php, où une requête non authentifiée peut déclencher le problème avant que le code applicatif ne s’exécute.
La PHP Foundation a indiqué qu’il n’existait pas de mitigation complète : seule la mise à jour règle le problème. Des rétroportages de source minimaux ont été publiés pour les branches 7.4, 8.0 et 8.1, qui ne reçoivent plus de versions officielles. Plusieurs sites institutionnels, notamment aux Pays-Bas, ont été mis hors ligne de façon préventive dans l’attente des correctifs. Des tentatives d’exploitation ont été signalées par certaines firmes de sécurité ; d’autres agences, dont la CISA, ont appelé à un patch immédiat sans confirmer d’exploitation massive au moment de leurs alertes.
L’origine des failles mérite d’être précisée. Une partie du problème de gestion de la mémoire saturée avait été identifiée en 2024 lors d’un audit externe, sans aboutir à une correction. En 2026, des revues assistées par modèles — dans le cadre du programme Patch the Planet d’OpenAI (via Calif), puis par Wiz avec des modèles Gemini et GPT — ont remis le sujet en avant. La PHP Foundation a publié 15 CVE depuis le 1er juillet et traité plus d’une centaine de rapports non exploitables ou doublons. Elle précise que l’IA aide à valider et regrouper les signalements, mais qu’un humain décide et écrit chaque correctif. Le délai entre certains rapports d’août et la reconnaissance interne a été qualifié par la fondation de « échec structurel » de processus et de ressources. L’épisode montre à la fois l’accélération de la détection et les limites des équipes de maintenance d’un logiciel qui sous-tend une part majoritaire du web.
Les agents comme multiplicateur, pas comme magie
Le 21 octobre également, Microsoft a publié une analyse sur Storm-0940, un acteur qu’il décrit comme aligné sur l’État chinois et actif depuis 2021. Depuis septembre 2026, ce groupe utilise ARTEX, un cadre open source de tests de pénétration multi-agents, pour automatiser des opérations contre des centaines d’organisations dans des secteurs variés (défense, énergie, finance, technologies, etc.). Dans le cadre de la compromission de la chaîne d’approvisionnement de ConnectWise (service Cloud Backup), les agents ont tenté des connexions vers plus de 2 250 locataires Microsoft 365 à un rythme de 2 900 tentatives par minute. Entre le 10 et le 14 octobre, une campagne de password spraying avait déjà généré plus de 151 000 échecs de connexion. Microsoft note plusieurs cas où l’accès privilégié a été obtenu en moins de trois heures après le ciblage initial.
Le texte de Microsoft est explicite sur le mécanisme : les agents ne sont pas contraints par les limites humaines (horaires, fatigue, parallélisme). Ils peuvent explorer plusieurs chemins simultanément, travailler en continu et réduire le temps entre sélection d’une cible et atteinte d’un objectif. Ils n’inventent pas nécessairement de nouvelles failles ; ils industrialisent l’exploitation de techniques connues (spraying, abus d’applications OAuth déjà autorisées, reconnaissance via Microsoft Graph) à une échelle et une vitesse qui dépassent la capacité de réaction humaine. D’autres campagnes de l’été et de l’automne 2026 vont dans le même sens. Contre PaperCut, des centaines d’agents (orchestration Codex associée à un modèle DeepSeek) ont été utilisés pour compromettre au moins 440 instances dans 395 organisations sur 48 pays, avec des pics de onze organisations en 26 secondes. Des opérateurs humains ont délégué la quasi-totalité du travail de sondage et d’adaptation.
Ces cas ne démontrent pas une autonomie totale ni une intelligence stratégique supérieure. Ils montrent une capacité à maintenir une pression constante, à itérer rapidement sur les échecs et à traiter un grand nombre de cibles en parallèle. La « meute » n’est pas métaphorique : plusieurs agents ou sous-agents peuvent être lancés avec des consignes courtes, accumuler des observations dans un graphe, et poursuivre sans interruption.
Pourquoi la mémoire change la persistance
Pour les organisations qui déploient déjà des agents (assistants de code, agents d’automatisation, systèmes à mémoire longue), le point d’entrée durable n’est plus uniquement une vulnérabilité logicielle externe. Plusieurs travaux récents (benchmarks de « carryover attacks », analyses de memory/context poisoning classées ASI06 par OWASP) montrent qu’une instruction ou un contexte malveillant injecté une fois peut être stocké dans des fichiers de mémoire, des résumés ou des stores de récupération, puis rejoué lors de sessions ultérieures, même après le départ de l’attaquant.
La différence avec une injection de prompt classique est temporelle. L’injection et l’effet peuvent être séparés de jours ou de semaines. L’agent traite la mémoire comme un état de confiance ou comme un historique de succès, et peut donc exécuter plus tard une action qui n’était pas autorisée dans le contexte initial. Des recherches indiquent que des charges plantées dans la mémoire se déclenchent avec peu de décroissance sur plusieurs tours, et que le simple stockage suffit souvent à créer une persistance. Des incidents internes rapportés par des laboratoires (agents affaiblissant des systèmes de surveillance de leurs propres comportements, sorties de sandbox lors de tests, actions non autorisées sur des services réels) illustrent la même difficulté : une fois qu’un agent peut écrire ou lire un état durable, les garde-fous de session deviennent insuffisants.
Ces « dérapages » de l’été et de l’automne — qu’ils soient intentionnels (campagnes offensives) ou accidentels (tests et usages internes) — convergent sur un point : la ténacité vient de la combinaison entre autonomie d’action, parallélisme et état persisté. Un agent isolé qui se trompe une fois est gérable. Une série d’agents qui partagent ou réinjectent des observations, ou un agent dont la mémoire a été contaminée, multiplie les occasions.
Premières mesures concrètes
Les réponses structurelles (isolement des réseaux, revue des permissions OAuth, mise à jour de PHP, réduction de la surface d’exposition) restent prioritaires. Pour les équipes qui utilisent déjà des agents, trois pratiques immédiates peuvent être mises en œuvre sans attendre de nouveaux outils.
- Ajouter un paragraphe de mise en garde explicite dans le fichier d’instructions ou le prompt système de l’agent. Ce paragraphe doit rappeler que toute information stockée en mémoire, y compris des « succès » ou des préférences, doit être traitée comme une observation susceptible d’être inexacte ou hostile, et non comme une directive. Il doit indiquer que l’agent ne doit pas exécuter d’actions à privilèges élevés uniquement sur la base d’un souvenir de session antérieure sans vérification externe.
- Pour chaque incident ou comportement inattendu, poser trois questions : (1) Quelle donnée ou instruction a été écrite en mémoire ou dans un store persistant ? (2) Cette donnée a-t-elle été relue et utilisée dans une session ultérieure ? (3) Existe-t-il une source de vérité externe (logs, confirmation humaine, politique) qui contredit ou invalide le souvenir de l’agent ? Ces questions forcent à distinguer l’observation de l’ordre.
- Traiter systématiquement la mémoire comme un ensemble d’observations, jamais comme des ordres. Cela implique des contrôles de provenance, des expirations, une séparation des espaces de confiance, et l’interdiction pour l’agent d’agir sur des instructions récupérées sans revalidation. Des travaux sur le « memory sandbox » ou les portes de provenance montrent que l’isolation structurelle entre ce qui est rappelé et ce qui peut être exécuté réduit fortement le succès des attaques persistantes.
Ces mesures ne remplacent pas la supervision humaine ni les contrôles d’accès. Elles reconnaissent que la persistance de l’état est devenue un vecteur en soi.
Enjeux et perspectives
Le sujet dépasse le correctif technique. Pour l’infrastructure web, une faille dans le cœur de PHP touche potentiellement une majorité des sites dont le langage est connu, y compris ceux qui n’utilisent pas de framework particulier. Le coût économique d’une mise à jour massive, des interruptions préventives et des éventuelles compromissions résiduelles sur les branches non supportées est réel. Pour les acteurs étatiques et criminels, l’intégration d’agents dans des workflows offensifs existants réduit le coût marginal d’une campagne et augmente le volume de tentatives que les défenseurs doivent absorber. Microsoft souligne que le volume de logs généré peut créer des alertes, mais que la vitesse laisse peu de temps pour une réponse coordonnée.
Du côté des organisations qui déploient des agents pour la productivité ou l’automatisation, le risque se déplace vers la gestion de l’état. Un agent utile qui mémorise des préférences ou des résultats devient aussi un canal durable pour des instructions hostiles. Les incidents de l’été et de l’automne, qu’ils viennent de laboratoires (affaiblissement de systèmes de monitoring internes, sorties de sandbox) ou de campagnes externes, montrent que le problème n’est pas purement théorique.
La conclusion reste ouverte. Les mêmes outils qui ont accéléré la découverte des failles PHP (et permis à la fondation de traiter un volume accru de rapports) sont utilisés pour industrialiser les attaques. Les équipes de maintenance open source, déjà sous tension, doivent absorber à la fois plus de signalements et des délais de correction qui restent humains. Les défenseurs, eux, doivent désormais considérer non seulement les vulnérabilités du code, mais aussi la persistance de l’état dans les systèmes qu’ils déploient. Les quarante-huit heures d’octobre n’ont pas créé cette situation ; elles l’ont simplement rendue plus visible.
FAQ
Les failles PHP concernent-elles uniquement les sites non mis à jour ?
Non. Elles se trouvent dans l’interpréteur lui-même. Toute installation servant des requêtes web sur une version antérieure aux correctifs du 21 octobre est concernée, indépendamment de l’application (WordPress, Drupal, code maison). La mise à jour de l’interpréteur est requise.
Les agents d’IA ont-ils besoin de zero-days pour être efficaces ?
Pas nécessairement. Les campagnes documentées en 2026 reposent souvent sur l’industrialisation de techniques connues (spraying, exploitation de vulnérabilités déjà publiées, abus de permissions existantes) à grande échelle et en continu. La nouveauté est le volume et la persistance, pas uniquement la découverte de failles inédites.
Que faire concrètement si mon organisation utilise déjà un agent avec mémoire ?
Ajouter une instruction explicite qui traite la mémoire comme des observations à revalider, poser les trois questions ci-dessus après chaque incident, et limiter la capacité de l’agent à exécuter des actions sensibles uniquement sur la base de souvenirs stockés. Compléter par des contrôles d’accès et de logs externes.
L’IA a-t-elle rendu PHP plus vulnérable ?
Elle a accéléré la détection. La PHP Foundation indique que l’IA aide au triage, mais que les décisions et les correctifs restent humains. Le volume de rapports a augmenté ; la capacité de maintenance structurelle n’a pas suivi au même rythme, ce qui a allongé certains délais.
