Black October : failles PHP, secrets volés, ce que ça change pour vos agents IA
PHP2Shell et l'incident Railway (octobre 2026) : ce que le cluster Black October change pour sécuriser un agent IA, ses secrets SaaS et un environnement HDS.
Mi-octobre 2026, deux sujets ont occupé la presse tech et X en même temps : des failles critiques dans le moteur PHP (PHP2Shell), et un incident chez Railway qui a poussé la plateforme à demander la rotation de secrets. Le cluster a vite pris le surnom de Black October. Pour une boîte qui ship de l'IA, le vrai sujet n'est pas « le cyber en général ». C'est comment sécuriser un agent IA quand le runtime legacy et les clés API SaaS deviennent des surfaces d'attaque.
Cet article n'est pas un avis juridique ni un bulletin de réponse à incident. Pour votre cas, voyez votre RSSI, votre DPO ou un prestataire spécialisé.
Black October en un écran
PHP2Shell : failles dans le cœur de PHP
Le 21 octobre 2026, PHP a publié des correctifs pour deux vulnérabilités critiques regroupées sous le nom PHP2Shell : CVE-2026-109618 et CVE-2026-109619. Selon Wiz Research, ce sont des problèmes de sécurité mémoire dans le moteur PHP lui-même. Wiz montre une exécution de code à distance sans authentification sur des déploiements représentatifs (WordPress, Drupal, Joomla), et une divulgation de mémoire de processus pouvant contenir mots de passe, tokens ou clés API. Le score CVSS annoncé va jusqu'à 9.2.
La PHP Foundation a annoncé les versions corrigées : PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35. La CISA a appelé à patcher immédiatement et rappelle que les installations qui servent des requêtes web (Apache mod_php, PHP-FPM, php-cgi, etc.) sont concernées.
En France, le CERT-FR a publié l'alerte CERTFR-2026-ALE-014, et Cybermalveillance.gouv.fr a relayé une AlerteCyber le 22 octobre 2026. Les versions PHP 8.1 et antérieures ne sont plus supportées : pas de correctif, il faut migrer ou isoler.
Incident Railway : secrets et clés AI providers
En parallèle, Railway a publié un rapport préliminaire sur un incident de sécurité autour du 20-22 octobre 2026. D'après ce rapport, un acteur malveillant a obtenu un accès non autorisé à un sous-ensemble de systèmes internes Railway. L'intention suspectée : récupérer des clés API de fournisseurs d'IA. Railway indique qu'au plus 1,85 % des workspaces ont pu avoir des variables d'environnement potentiellement compromises. La plateforme recommande à tous les clients ayant stocké des secrets avant le 21 octobre de les faire tourner. TechCrunch et BleepingComputer ont relayé l'appel à rotation.
Deux faits, une même leçon pour les équipes IA : patcher le runtime d'un côté, gouverner les secrets de l'autre. Un agent bien pensé ne suffit pas si les clés qu'il utilise vivent en clair dans un env trop large, ou si le PHP d'un outil métier à côté n'est plus patché.
Le vrai risque pour une boîte qui ship de l'IA
Beaucoup d'entreprises ont aujourd'hui deux stacks en parallèle :
- Le legacy web : WordPress, Drupal, intranet PHP, outils métier hébergés depuis des années. PHP2Shell montre que la faille peut être dans le langage, pas seulement dans le plugin.
- La couche agents : copilotes, agents support, pipelines qui appellent OpenAI, Anthropic, OpenRouter ou d'autres APIs, avec des secrets dans les variables d'environnement, les CI et les dashboards PaaS.
Le risque se croise. Une divulgation mémoire côté PHP peut exposer des tokens. Un incident PaaS peut exposer les mêmes clés que votre agent utilise pour lire le CRM ou écrire dans un ticket. Et un agent trop privilégié transforme une clé volée en action : envoyer un mail, modifier une fiche, appeler une API métier.
Ce n'est pas théorique. On le voit dans les projets. Dès qu'un agent passe de « résumer » à « exécuter », la surface change. On détaille cette grille dans Le vrai risque des agents IA, c'est l'autorité. Pour le cadre entreprise plus large, voir aussi Agents IA en entreprise.
Les PME françaises qui gardent un site ou un back-office PHP non maintenu, et qui branchent en même temps un agent sur des clés SaaS, cumulent les deux expositions. Black October a mis les deux sujets sur la même semaine.
Grille TVC : lire, proposer, préparer, exécuter (et secrets hors contexte)
Pour sécuriser un agent IA, on commence par classer ce qu'il a le droit de faire :
| Niveau | Ce que l'agent fait | Risque principal si les secrets fuient |
|---|---|---|
| Lire | Cherche, résume, compare | Fuite de données visibles dans le contexte |
| Proposer | Rédige un brouillon, propose un plan | Mauvaise recommandation, pas d'effet externe |
| Préparer | Ouvre une PR, prépare un mail prêt à envoyer | Validation trop facile, effet quasi immédiat |
| Exécuter | Envoie, modifie, déploie, appelle une API | Impact réel, parfois irréversible |
Trois règles concrètes qu'on applique chez The Vibe Company :
- Secrets hors du contexte agent. L'agent ne doit pas « voir » la clé API en clair dans son prompt ou ses logs. Les appels passent par un backend ou un vault qui injecte le secret au moment de l'appel HTTP, pas dans le message système.
- Moindre privilège par niveau. Un agent en mode « lire » n'a pas les mêmes scopes qu'un agent en mode « exécuter ». Compte technique séparé, scopes séparés, expiration.
- Validation humaine avant l'irréversible. Envoi mail, écriture CRM, déploiement, paiement : rester en « préparer » jusqu'à ce que les logs, les quotas et le kill switch soient en place.
Black October ne change pas cette grille. Il la rend urgente. Si vos clés SaaS peuvent fuir via un PaaS ou un runtime legacy, un agent en mode exécuter trop large devient le multiplicateur.
Cas France : HDS et données sensibles
Quand les données sont de santé, le sujet secrets + agents se joue dans un cadre plus strict. La certification HDS porte sur l'hébergement des données de santé. On l'explique dans IA et données de santé : ce que l'HDS impose vraiment.
Point important, et on le répète clairement : The Vibe Company n'est pas « certifiée HDS ». Chez Monka, le client était déjà hébergé en HDS. On a construit l'app aidants, le CRM infirmières et le moteur clinique dans l'environnement HDS du client. Aucune donnée n'en sortait. C'est ce modèle qu'on recommande : construire dans l'env conforme du client, pas prétendre porter la certification à sa place.
Pour un agent qui touche des dossiers patients ou des bilans :
- les prompts, logs et embeddings restent dans le périmètre HDS ;
- les appels modèle ne partent pas vers une API grand public avec des données en clair ;
- les secrets d'API restent dans le coffre de l'environnement client, pas dans le chat de l'agent ;
- les droits de l'agent restent au niveau « lire / proposer » tant que la validation métier n'est pas cadrée.
Checklist 48 h après Black October
À faire dans les deux jours si vous avez un stack web PHP, des agents, ou les deux :
- Inventorier PHP. Versions en prod, internet-facing d'abord. Viser 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 selon la branche. Versions EOL : isoler et planifier la migration (CERT-FR / Cybermalveillance).
- Patcher ou mitiger. Suivre les bulletins PHP et les mesures temporaires du CERT-FR si le patch n'est pas immédiat.
- Cartographier les secrets des agents. Clés OpenAI, Anthropic, CRM, mail, ticketing, registries : où elles vivent (PaaS, CI,
.env, vault). - Rotation. Si vous avez stocké des secrets sur Railway avant le 21 octobre 2026, suivez la recommandation de leur rapport : révoquer et réémettre. Même logique pour tout PaaS où des env vars sensibles étaient présentes.
- Réduire l'autorité des agents. Repasser chaque workflow en lire / proposer / préparer / exécuter. Couper l'exécution automatique là où la validation humaine manquait.
- Sortir les secrets du contexte. Vérifier qu'aucune clé n'apparaît dans les prompts, les traces LangSmith/PostHog, les tickets de debug ou les captures d'écran.
- Cas santé. Si données de santé : revoir les flux avec le guide HDS et le DPO. Ne pas improviser un appel modèle hors environnement couvert.
FAQ
Est-ce que Black October vise seulement PHP ?
Non. PHP2Shell est un sujet runtime web. L'incident Railway est un sujet secrets / plateforme. Ensemble, ils touchent les boîtes qui ont à la fois du legacy et des agents IA.
Faut-il arrêter tous les agents ?
Non. Il faut les borner. Un agent en « lire » et « proposer », avec secrets injectés côté serveur, reste utile. Le danger, c'est l'exécution large avec des clés trop puissantes.
The Vibe Company est-elle certifiée HDS ?
Non. On construit dans l'environnement HDS du client quand c'est le cas, comme chez Monka. La certification reste celle de l'hébergeur / du client.
Où trouver les correctifs PHP officiels ?
Sur php.net et dans le billet de la PHP Foundation. Relais FR : CERTFR-2026-ALE-014 et Cybermalveillance.
Besoin d'un audit d'architecture agents ?
The Vibe Company est une agence IA à Paris (YC, pivot Quivr). On aide les équipes à passer des agents utiles en production sécurisée : autorité, secrets, observabilité, et cadre HDS quand les données l'exigent.
