Après PHP, Node.js, Java et Python : il faudra patcher plus souvent
Après les failles PHP de cette semaine, Java, Node.js et des paquets Python ont aussi besoin de mises à jour de sécurité. Je pense qu’on va devoir s’habituer à ce rythme de signalements et de correctifs. Et les développeurs ont encore du pain sur la planche.
Tweakers a consacré un article à la faille Node.js (s’ouvre dans un nouvel onglet). La faille, CVE-2026-111497, se trouve dans Brotli, une bibliothèque de décompression. Node.js a publié des correctifs le 21 octobre (s’ouvre dans un nouvel onglet) dans les versions 22.23.4, 24.22.1 et 26.12.1, et attribue la découverte à OpenAI Codex Security. Imperva a montré (s’ouvre dans un nouvel onglet) qu’un attaquant pouvait ainsi exécuter son propre code sur Node.js 24.22.0. La version corrigée rejetait les mêmes données.
Le même décodeur se trouve dans les paquets Python Brotli et brotlicffi (s’ouvre dans un nouvel onglet), corrigés dans les versions 1.2.1 et 1.2.1.0. Aikido explique (s’ouvre dans un nouvel onglet) que des clients HTTP comme requests et httpx les utilisent automatiquement s’ils sont installés. Votre code n’a donc même pas besoin d’appeler Brotli directement.
Oracle a aussi publié des correctifs pour Java SE (s’ouvre dans un nouvel onglet). Ce sont des problèmes distincts. Pour la faille Brotli, le NCSC néerlandais évalue (s’ouvre dans un nouvel onglet) la probabilité d’exploitation comme moyenne et les dommages potentiels comme importants. Le 23 octobre, aucune exploitation active n’avait encore été constatée.
Trouver les failles plus souvent et les corriger plus vite
OpenAI s’attend à une forte hausse de ces découvertes dans les prochains mois (s’ouvre dans un nouvel onglet). L’entreprise décrit aussi comment l’IA peut aider à préparer des correctifs et des tests, vérifiés par les mainteneurs et les experts en sécurité. Les attaquants disposent eux aussi de ces capacités.
Java en donne déjà un exemple concret. Oracle a publié une première mise à jour mensuelle de Java le 18 août (s’ouvre dans un nouvel onglet), en plus du rythme trimestriel habituel. La suivante est prévue le 17 novembre. Oracle cite explicitement l’IA comme raison : les failles sont trouvées et corrigées plus vite, et à plus grande échelle. Les équipes doivent y préparer leurs tests et leurs déploiements.
Je m’attends à ce que cela devienne la nouvelle réalité. Appliquer des correctifs plus souvent fera parfois mal, comme on l’a vu avec PHP.
À terme, je pense tout de même que les logiciels en sortiront plus sûrs. Chaque faille trouvée tôt et bien corrigée, c’est une de moins dans les bibliothèques sur lesquelles nous construisons tous. Mais une faille découverte reste un risque tant que le correctif n’est pas en place. Brotli le montre bien : selon Aikido, la cause était déjà corrigée dans le code source en février. Personne n’y a vu un problème de sécurité, aucune version n’a suivi, et le correctif ne tournait donc nulle part.
Le développeur devient bâtisseur et chef d’équipe d’agents
Ce travail ne se fait pas tout seul. Quelqu’un doit décider ce qu’on corrige, comment, et si la mise en production est sûre. C’est pour cela que je crois que notre métier continuera d’exister. Les développeurs deviennent davantage des bâtisseurs, des architectes, des responsables d’équipes d’agents et des spécialistes de la sécurité. On tape moins de code soi-même. Déterminer quoi construire, comment les éléments fonctionnent ensemble et si le résultat est fiable devient le vrai travail.
Pour moi, cela implique de bien déléguer à l’IA, avec efficacité. Un agent peut préparer une modification, un autre peut examiner ses effets sur le reste de l’application. En tant que développeur, vous définissez la tâche, fournissez le contexte et vérifiez le résultat. Vous devez aussi intervenir quand les agents se contredisent ou reprennent une hypothèse erronée.
Prenez cette mise à jour de Brotli. Un agent peut retrouver par quels paquets la bibliothèque arrive, préparer les nouvelles versions et lancer les tests. Mais si cette analyse tient, si la mise à jour peut partir en production aujourd’hui et qui intervient si quelque chose casse malgré tout, c’est le développeur qui en décide. Cette responsabilité ne se délègue pas. Taper du code compte moins. Le développeur, lui, compte toujours autant.