Le décompte porte sur le registre officiel des failles de PostgreSQL, qui liste chaque vulnérabilité publiée (CVE) avec les versions qui la corrigent et son score de gravité. Au 19 octobre 2026, il compte 44 identifiants CVE-2026, contre 7 identifiants CVE-2025 pour toute l'année précédente. Le rapport est de 6,3. Le registre ne nomme pas les découvreurs : la part trouvée avec des outils d'IA n'est pas établie. L'annonce de la RC1, première version candidate de PostgreSQL 19, ne mentionne ni l'IA ni les fonctions retirées.
28 failles dans la seule mise à jour du 13 août
Les failles de 2026 ont été corrigées en trois lots sur les branches maintenues, de la 14 à la 18. Le troisième, daté du 13 août, est le plus lourd. Son annonce indique qu'il « corrige 28 failles de sécurité et plus de 110 bogues » (traduit de l'anglais).
| Mise à jour (versions corrigées) | Failles (CVE) | Score CVSS de 7 ou plus | Corrigées sur les cinq branches |
|---|---|---|---|
| 18.2, 17.8, 16.12, 15.16, 14.21 | 5 | 4 | 4 |
| 18.4, 17.10, 16.14, 15.18, 14.23 | 11 | 6 | 8 |
| 18.6, 17.11, 16.15, 15.19, 14.24 (13 août 2026) | 28 | 18 | 23 |
| Total 2026 | 44 | 28 | 35 |
| Total 2025 (quatre mises à jour) | 7 | 3 | non compté |
Source : registre des failles de PostgreSQL, consulté le 19 octobre 2026. Décompte ActuIA.
Vingt et une des failles de 2026 sont notées 8,8 sur 10 au score CVSS. Aucune n'atteint 9. Une faille présente dans les cinq branches est corrigée dans cinq versions distinctes : c'est le cas de 35 des 44 failles de 2026.
La revue par LLM, l'une des causes citées par Peter Eisentraut
Le 9 octobre, Peter Eisentraut, développeur et committer de PostgreSQL, a publié sur son blog un billet intitulé The reverts will continue until morale improves. Il y compte « environ 8 à 10 fonctions importantes, selon la façon de compter », retirées de la branche 19 depuis le début de la bêta. Il a été le développeur ou le committer de certaines d'entre elles.
Il examine plusieurs explications, dont des défauts d'architecture, la complexité du système et l'absence de statut expérimental pour les nouvelles fonctions. C'est « probablement une combinaison » de ces facteurs, différente pour chaque fonction, écrit-il. Deux d'entre eux touchent à la revue et à la sécurité du code.
Le premier est l'outillage : « avec la revue de code assistée par LLM, ce genre de choses peut être trouvé beaucoup plus vite ». Des défauts qu'on aurait corrigés « petit à petit au cours des cinq années suivantes » remontent en bloc, et l'équipe se retrouve « face à une liste d'une quarantaine de rapports de défauts ». Chacun a « un coût fixe », « et le temps vient à manquer ». Selon lui, les fonctions retirées ont pour la plupart été écrites avant que cette revue devienne aussi utile : l'exigence de qualité a monté après leur intégration.
Le second est la mobilisation sur les failles. « À cause du Vulnpocalypse, beaucoup de développeurs expérimentés étaient occupés » à les corriger d'avril à août environ, date de « la plus récente publication de sécurité de PostgreSQL ». La revue et les tests habituels de la bêta en ont été réduits. Le billet ne définit pas le terme, qu'il dit « toujours en cours ».
Peter Eisentraut écarte une explication : la situation « n'est pas due au “vibe coding” », du moins pour l'essentiel, car ce code a été écrit avant que cette pratique existe. Parmi ses pistes figure le fuzzing assisté par LLM pendant le développement des fonctions.
Les fonctions absentes de PostgreSQL 19
Le billet ne dresse pas la liste des fonctions retirées. Un billet de l'éditeur Snowflake, signé Elizabeth Garrett Christensen le 16 septembre, en cite les principales à cette date. Y figurent les requêtes de graphes de propriétés (SQL/PGQ), la fusion et le découpage de partitions (ALTER TABLE MERGE/SPLIT PARTITION) et UPDATE ou DELETE FOR PORTION OF. S'y ajoutent GROUP BY ALL et l'activation à chaud des sommes de contrôle. Selon Snowflake, « la plupart seront retentées dans la v20 ». SQL/PGQ, GROUP BY ALL et la gestion des partitions y sont déjà renvoyés.
Le même billet estime que « l'IA doit faire partie de l'explication ». Il indique que le projet n'a pas de politique officielle sur les contributions par IA, mais qu'une politique est « attendue prochainement ».
curl : 18 des 24 failles du 14 octobre signalées par AISLE
Le registre des failles de curl, la bibliothèque de transfert de données, compte 69 failles publiées entre le 7 janvier et le 14 octobre 2026, contre 9 sur toute l'année 2025. Elles représentent 29 % des 239 failles publiées depuis l'origine du projet. Les trois dernières versions en ont corrigé 51 : 18 dans la 8.21.0 du 24 juin, 12 dans la 8.22.0 du 2 septembre, 21 dans la 8.23.0 du 14 octobre. Le billet de version de Daniel Stenberg, créateur de curl, en annonce 24 pour cette dernière : selon le registre, trois d'entre elles étaient déjà corrigées dans la 8.22.0.
Le fichier de données du projet crédite 18 de ces 24 failles à deux chercheurs d'Aisle Research, deux à « Luna with Claude » et Anthropic, quatre à d'autres chercheurs. La seule de gravité élevée, une réutilisation de mémoire libérée, vient d'Anthropic. Elle a conduit l'équipe à précipiter la version, selon A UAF turned RCE. Dans A curl audit by Aisle, Daniel Stenberg attribue à AISLE 35 failles au total, « plus qu'aucun autre groupe ou individu ». Ses employés ont aussi écrit « plusieurs dizaines de commits » dans curl.
La correction repose sur une équipe bénévole. Dans The 2026 curl team, le 12 octobre, Daniel Stenberg décrit « un rôle bénévole, sans rémunération », qui oblige à « traverser une avalanche de rapports de vulnérabilité ». En janvier, curl avait fermé son programme de primes, submergé de rapports invalides, comme ActuIA l'a détaillé à propos de la suspension d'une partie du bug bounty open source de Google. Le problème était alors de trier. Avec 24 failles confirmées en une version, il est désormais de corriger.
QGIS interdit les contributions par IA
Le 7 octobre, le système d'information géographique libre QGIS a adopté la proposition d'évolution QEP 428, No ai contributions permitted. Son auteur, le mainteneur Nyall Dawson, la présente comme le passage à une politique stricte « NOT ALLOWED ». Le texte n'est pas affiché sur la page. Son périmètre et ses sanctions ne sont pas connus.
Dans la discussion, le contributeur uclaros compte environ 50 pull requests étiquetées « AI Assisted », dont environ 40 fermées sans fusion. Nyall Dawson juge que la politique précédente « n'a clairement pas fonctionné » et que le projet a « déjà perdu au moins un contributeur de très grande valeur ». QGIS suit Godot, qui avait restreint le code généré par IA le 30 juin.
Ce que cela change pour une pile PostgreSQL
Le 12 novembre concentre trois échéances. Les versions maintenues recevront leur mise à jour trimestrielle, annoncée avec « un grand nombre de correctifs ». La RC2 de la 19 intégrera ces correctifs. PostgreSQL 14 recevra ses derniers correctifs. La disponibilité générale de la 19 est prévue le 19 novembre, « sauf si un problème exige un report ou une version candidate supplémentaire ».
Les mises à jour mineures sont cumulatives. Elles s'appliquent en remplaçant les binaires, sans export ni pg_upgrade, mais certaines demandent des opérations après coup : celle du 13 août recommandait de reconstruire certains index btree_gist et ltree. Selon sa politique de versions, le projet en publie au moins une par trimestre et recommande d'exécuter toujours la dernière. La feuille de route prévoit les suivantes le 11 février, le 13 mai et le 12 août 2027, et d'autres si un correctif important ou une faille l'exige.
Passer à la 19 demande une migration de version majeure, par pg_upgrade ou pg_dump et pg_restore. Le billet de Snowflake jugeait le 16 septembre que la 18, maintenue jusqu'au 14 novembre 2030, était « la cible de mise à jour sûre aujourd'hui ».
Ce que le Cyber Resilience Act prévoit pour les projets libres
Depuis le 11 septembre 2026, le règlement européen sur la cyberrésilience (CRA) impose aux fabricants de signaler les vulnérabilités activement exploitées et les incidents graves, a rappelé l'ENISA, l'agence de l'Union européenne pour la cybersécurité, dans un communiqué du même jour. Les projets libres ont un régime à part. Le considérant 18 précise qu'un logiciel libre non monétisé par son fabricant ne relève pas d'une activité commerciale. Le considérant 19 réserve aux intendants de logiciels ouverts (open-source software stewards), les organisations qui soutiennent ces projets dans la durée, un régime « léger et sur mesure ». Ces intendants entreront dans les obligations de signalement le 11 décembre 2027, en application de l'article 24, paragraphe 3, selon l'ENISA.
Nos articles remonteront en priorité dans « À la une » de Google.