Cognition lance un plugin pour agents de code contre les failles PHP et Node.js notées CVSS 9,2

Le 21 octobre 2026, des mises à jour de sécurité urgentes sont sorties pour PHP et Node.js, et les deux dossiers concernent l'exécution de code à distance. Côté PHP, le correctif couvre le duo de vulnérabilités PHP2Shell (CVE-2026-109618 et CVE-2026-109619), noté CVSS v4 9,2 et exploitable sans authentification. Côté Node.js, 10 CVE sont corrigées, dont quatre de sévérité High. Cognition, la société derrière l'agent Devin, affirme que ces failles sont déjà exploitées de manière automatisée. Elle a publié en open source un plugin qui transforme un agent de code en exécutant de l'ensemble du processus de correction.

Ce qui est exactement touché

PHP2Shell repose sur deux bugs. Le premier, CVE-2026-109618, est une corruption de mémoire survenant après un épuisement de la mémoire vive. Le second, CVE-2026-109619, est un état global périmé qu'une requête laisse à la suivante. Toute configuration web de PHP est exposée : PHP-FPM, php-cgi, FrankenPHP, LiteSpeed et Apache mod_php, qui présente le risque le plus élevé.

Dans Node.js, le problème principal est CVE-2026-111497 : une écriture hors des limites du tampon dans le décodeur Brotli, qui peut conduire à l'exécution de code. Il faut corriger en priorité les services exposés à Internet qui décompressent du Brotli : clients HTTP, serveurs et proxys. Trois autres failles High (CVE-2026-105482, CVE-2026-105483, CVE-2026-106069) touchent TLS et la vérification des noms d'hôte. Elles menacent les services qui se connectent à des adresses fournies par l'utilisateur.

• PHP : correctifs dans les versions 8.2.35, 8.3.36, 8.4.27 et 8.5.12 ; pour 7.4, 8.0 et 8.1, seuls des backports sous forme de sources ont été publiés
• Node.js : 22.23.4, 24.22.1 et 26.12.1
• Node.js 20 et les versions antérieures ne sont plus supportées : aucun correctif ne sera publié et la faille subsiste ; il faut migrer vers 22+
• La version de Node.js met à jour OpenSSL, c-ares, Undici, SQLite et le magasin de CA : le certificat racine eMudhra en a été retiré

Pourquoi « mettre à jour » ne suffit pas

PHP et Node.js se cachent dans les images de conteneurs, les paquets de l'OS, les pipelines CI, les valeurs Helm, Terraform et les runtimes Lambda, et ce dans des dizaines de dépôts. Chaque déploiement doit être repéré, mis à jour, vérifié, puis mis en production.

Les pièges ne manquent pas. Debian et Ubuntu rétroportent les correctifs sans changer la version amont : sur Ubuntu 24.04, le paquet corrigé s'appelle 8.3.6-0ubuntu0.24.04.13, et `php -v` affichera toujours 8.3.6. Il faut donc consulter le bulletin de sécurité de l'éditeur ou le changelog du paquet. Les images épinglées par digest exigent un nouveau digest, tandis que les tags flottants comme php:8.3-fpm doivent être reconstruits avec une nouvelle image de base. Modifier require.php ou config.platform.php dans Composer ne règle rien : ces réglages ne déterminent pas le runtime utilisé en production.

Si la mise à jour immédiate est impossible, PHP propose des mesures provisoires. Elles comprennent session.upload_progress.enabled=0 avec redémarrage de tous les workers, ainsi qu'une limite sur la taille du corps des requêtes et sur le nombre de parties multipart au niveau du proxy. En revanche, RLIMIT_AS et RLIMIT_DATA ne doivent pas être utilisés : ils déclenchent eux-mêmes le chemin de code vulnérable.

Comment fonctionne le plugin

Le plugin Vulnerability Fixes est tiré du processus que Cognition a employé pour réparer sa propre infrastructure. L'agent commence par un inventaire en lecture seule : Dockerfile, images de base, paquets, builds depuis les sources, setup-php, setup-node, .nvmrc, Terraform, Packer, Ansible, Chef et Puppet. Il présente ensuite un tableau et attend que vous indiquiez les dépôts qu'il peut modifier. Tout ce qui est plus risqué qu'un changement de version corrective (mise à niveau minor ou major, changement d'OS de base, modifications de code probables) est signalé en amont.

L'agent recoupe ensuite les tags, digests, versions de paquets et sommes de contrôle avec les registres officiels. Il exécute les tests sur la version actuelle comme base de référence, les rejoue dans la nouvelle image de production et compare les runtimes : extensions, réglages ini, versions d'OpenSSL et d'ICU. Il produit une PR par dépôt, avec les versions avant et après, les résultats des tests, une étiquette de risque et un plan de déploiement et de retour arrière.

Le plugin est disponible dans le Devin Marketplace, ainsi que sous forme d'Agent Skills standard pour Claude Code, Codex, Cursor, Factory Droid, GitHub Copilot, Gemini CLI et OpenCode : `npx skills add CognitionAI/devin-vuln-fixes`. Les skills s'exécutent avec tous les droits de votre agent ; Cognition demande donc de les lire avant de les lancer. Pour la compilation et les tests, il faut git, un shell, Docker et un accès à votre registre d'images.

Par où commencer aujourd'hui

Cognition conseille avant tout de mettre hors ligne les applications PHP publiques pendant le correctif, car l'exploitation est automatisée. Ensuite :

• vérifier les versions d'après le bulletin de la distribution, et non d'après `php -v`
• reconstruire les images à tags flottants et remplacer le digest de celles qui sont épinglées
• inscrire Node 20 et les versions antérieures dans un plan de migration vers 22+
• déployer d'abord les PR risquées sur staging ou en canary
• après le merge, redéployer chaque service : le correctif ne s'applique que dans le nouveau build

L'agent ne vérifie que ce que les tests couvrent ; pour les applications peu testées, la PR recommande donc explicitement un passage par staging. Les runtimes managés sont corrigés par le fournisseur, et pour les solutions matérielles des éditeurs ainsi que pour les applications Electron embarquant PHP ou Node, l'agent se contente de signaler qu'une mise à jour doit venir de l'éditeur.

Chez Cognition, on estime que ce type d'épisode va devenir la norme : la vitesse de découverte des vulnérabilités augmente, et les attaquants automatisent leurs chaînes d'exploitation grâce à l'IA. L'entreprise recommande de scanner en continu la surface d'attaque externe, de placer les applications internes derrière un VPN ou un ZTNA, de passer à des runtimes et conteneurs récents et d'abandonner les cycles de correctifs de 30 jours. Le directeur de la sécurité Alex Stamos animera un webinaire le 26 octobre à 10 h 30, heure du Pacifique.