PHP2Shell : la CISA confirme l'exploitation, les industriels comptent leurs produits

Dans notre édition d'hier, l'exploitation réussie restait une affaire d'exploits privés et d'une attaque « agentique » retirée par Unit 42. Elle est désormais observée, mesurée et reconnue par une agence gouvernementale. Le rythme est classique : fuite le 17 octobre, correctifs le 21, preuve de concept publique, puis attaques réelles. Attention toutefois : les shells confirmés l'ont été sur des leurres, dans une configuration favorable à l'attaquant. Aucune victime réelle n'est publiquement identifiée à ce stade. Si vous gérez du PHP exposé, passez en 8.5.12, 8.4.27, 8.3.36 ou 8.2.35. Cherchez aussi dans vos journaux des processus PHP qui lancent un shell ou téléchargent des outils, comme le conseille la CISA. Une troisième faille, CVE-2026-115560, attend encore son correctif, jugé moins urgent par PHP (voir plus bas).

ARTEX n'est pas inconnu : c'est le même cadre d'agents d'IA utilisé contre des banques sud-coréennes par un acteur sinophone, dont nous parlions le 22 octobre. La police coréenne tire une leçon claire : l'IA abaisse la barrière d'entrée, et « même des individus qui ne sont pas des organisations de hackers professionnelles peuvent désormais pirater à grande échelle ». À relativiser : les failles exploitées (bases de données, pages d'administration mal protégées) restent classiques. L'IA a surtout accéléré et industrialisé le travail. La réponse passe toujours par l'hygiène de base : interfaces d'administration jamais exposées sur Internet, correctifs rapides, surveillance des exportations massives de données.

Un jeton de session d'assistant de code vaut désormais autant qu'un mot de passe bancaire. Il ouvre l'historique des conversations, le code partagé et parfois des crédits payants. Check Point évoque la revente d'accès ou le chantage à la divulgation des conversations. Prudence : ces modes de monétisation sont des hypothèses, l'analyse ne les confirme pas. Le mode de diffusion du logiciel n'est pas détaillé non plus. Concrètement : traitez les dossiers .claude, .codex, .aws comme des secrets, révoquez les sessions après toute infection, et préférez des jetons courts aux clés permanentes. Ce sujet rejoint celui des fichiers AGENTS.md piégés (voir plus bas) : le poste du développeur devient la cible prioritaire.

C'est le scénario que redoutent tous les hôpitaux : un incident informatique qui touche directement l'accueil des urgences. UNM Health est un acteur central de la santé au Nouveau-Mexique, et chaque détournement allonge le trajet des patients. Attention toutefois : on ignore encore la nature exacte de l'incident, son point d'entrée et l'éventuel vol de données. Il serait prématuré de le relier à PHP2Shell ou à une autre campagne en cours. Pour les établissements de santé, la leçon reste celle des plans de fonctionnement dégradé : procédures papier prêtes, et communication rapide vers les patients.

La menace visée est celle du « récolter maintenant, déchiffrer plus tard » : un adversaire enregistre aujourd'hui des échanges chiffrés pour les casser quand il disposera d'une machine quantique. Avec ML-KEM dans KMS, les clients d'AWS peuvent tester l'échange de clés post-quantique sans gérer eux-mêmes leurs clés sensibles. À relativiser : cette brique ne couvre que l'échange de clés, pas les signatures. Le pilote IDEMIA-KT, lui, ne précise ni volumes ni calendrier de déploiement. Ces annonces prolongent celle des banques centrales espagnole et portugaise (voir notre édition d'hier). Pour vos équipes : commencez par l'inventaire de vos usages cryptographiques, condition de toute migration.

Le numéro CPR danois sert à presque tout : banque, santé, impôts. Sa fuite ouvre la voie à l'usurpation d'identité et à des hameçonnages très crédibles. Le cas illustre une erreur fréquente : copier des données de production réelles dans un environnement de test, souvent moins surveillé. Attention toutefois : l'université ne dit pas encore comment le pirate est entré, ni si les données ont été publiées. Conseil pratique : vos environnements de recette doivent utiliser des données anonymisées ou synthétiques, jamais une copie de la production.