Une semaine, quatre écosystèmes : PHP, Node et Python, octobre 2026

Entre le 14 et le 22 octobre 2026, PHP et Node.js ont publié le même jour des correctifs de sécurité pour des failles d'exécution de code à distance, les clés intermédiaires d'une autorité de certification ont été révoquées, un hébergeur a annoncé un accès aux variables d'environnement de ses clients, et deux paquets, l'un sur npm, l'autre sur PyPI, ont été signalés comme porteurs de voleurs d'identifiants. Chaque affaire a son propre article sur ce blog. Celui-ci les aligne sur une seule ligne, parce que lues ensemble elles renvoient à une courte liste d'habitudes qui couvre l'essentiel.

La semaine, dans l'ordre

Une semaine plus tôt, le 8 octobre, le tracker pwn.watch rapporte que tensorlake 0.5.144 a été publié sur npm depuis son vrai dépôt, avec provenance, en embarquant un ver voleur d'identifiants (la provenance n'est pas une garantie). Le 14 octobre, selon le même tracker, Vercel a sorti hors calendrier Next.js 16.4.1 et 15.5.28 pour deux RCE critiques sans authentification ; l'avis GitHub sur celle liée au SVG lui donne un score CVSS de 9.5 (l'article sur Next.js). Les 18 et 19 octobre, toujours d'après le tracker, des clés de CA intermédiaires d'eMudhra se sont révélées faibles et ont été révoquées ; eMudhra dit avoir révoqué les CA concernées dans les 14 heures suivant la découverte (magasins de confiance).

Le 20 octobre, php.net a publié une entrée intitulée "Upcoming Critical PHP Security Release" ; le tracker indique que des détails avaient fuité en avance. Le 21 octobre, PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35 ont corrigé deux RCE critiques sans authentification (mettez PHP à jour), et Node.js 26.12.1, 24.22.1 et 22.23.4 ont corrigé dix vulnérabilités, dont une RCE dans le décodeur Brotli (la version de Node, et deux correctifs Node plus petits). Le même jour, Railway a annoncé qu'un tiers avait pu obtenir des variables d'environnement clients déchiffrées (renouveler ses secrets), et le tracker signale une version compromise de LiteLLM 1.107.0 sur PyPI et Docker (un paquet, toutes vos clés). Le 22 octobre, eMudhra a annoncé quitter le marché des certificats TLS, et l'enquête de W3Techs montrait que 34.7% des sites PHP qu'elle détecte tournent encore sous PHP 7 ou plus ancien (fin de vie de PHP).

Quatre tendances

Ce sont des tendances que je lis à travers les sources, pas des causes confirmées par qui que ce soit.

Le correctif est un numéro de version. PHP et Node.js ont tous deux répondu par des versions corrigées, et tous deux précisent que les branches en fin de vie sont laissées de côté : php.net indique que la 8.1 et les versions antérieures ne reçoivent plus de mises à jour du projet, et Node.js rappelle que les versions en fin de vie sont toujours affectées lorsqu'une version de sécurité sort. Si vous ignorez quelle version tourne en production, vous ne pouvez pas savoir si vous êtes corrigé.

La confiance est empilée, et elle se livre. Une liste de CA embarquée dans le runtime (Node.js a mis à jour son ca-cert pour eMudhra), un paquet construit avec provenance, le coffre à secrets d'une plateforme, un pipeline de release. Chaque couche est quelque chose qu'on accepte sans regarder, et c'est aussi pourquoi une compromission dans l'une peut passer discrètement dans la suivante.

Les identifiants sont le butin. Trois des incidents, le ver npm, la version LiteLLM et l'annonce de Railway, visent à collecter des secrets plutôt qu'à casser le code de l'application. Railway dit penser que son incident fait partie d'une série visant à atteindre des fournisseurs d'inférence IA.

Des habitudes ennuyeuses répondent à l'essentiel. C'est la bonne nouvelle, et c'est la dernière partie.

La checklist de la semaine

Commencez par les versions, partout où elles se cachent : le serveur web, la CLI, l'image Docker de base et la CI. En ligne de commande :

php -v
node -v
composer audit
npm ls next sharp

N'oubliez pas que php -v affiche la CLI, qui peut différer de ce qui sert les requêtes web. Ensuite : passez PHP en 8.5.12, 8.4.27, 8.3.36 ou 8.2.35 et Node.js en 26.12.1, 24.22.1 ou 22.23.4 ; planifiez la sortie de toute branche qui ne reçoit plus de correctifs ; écrivez la liste des secrets que détient votre application et la façon de renouveler chacun ; et gardez les secrets de production hors des machines des développeurs, là où les malwares d'installation vont les chercher. Si vous ne faites qu'une chose aujourd'hui, vérifiez quelles versions de PHP et de Node.js tournent réellement en production.

Des articles précédents qui creusent ces habitudes : les dix premières minutes après une fuite de clé, les malwares à l'installation, les lockfiles de workflow et isoler un agent de code.

Source : archives des actualités de php.net, 2026 ; chaque article lié cite sa propre source primaire.