Une faille vieille de 20 ans, découverte par une IA
En décembre 2025, un outil d'analyse de code autonome baptisé Xint Code a été soumis au concours ZeroDay.Cloud de Wiz. Résultat : trois CVEs critiques dans PostgreSQL et ses extensions — CVE-2026-2005, CVE-2026-2006 et CVE-2026-2007 — aujourd'hui corrigées.
La plus marquante, CVE-2026-2005, réside dans le gestionnaire de messages PGP de l'extension pgcrypto. Elle date d'environ 2005. Oui : cette faille est plus ancienne que l'iPhone, que Twitter, et pour beaucoup de développeurs... que leur carrière entière.
La vraie question que soulève cet épisode n'est pas « les IA savent-elles trouver des bugs ? ». C'est : pourquoi une communauté mondiale de développeurs compétents ne les a-t-elle pas trouvées en vingt ans ?
Ce que cachaient ces trois CVEs
Les trois vulnérabilités partagent la même morphologie : des débordements de tampon sur le tas (heap buffer overflows) dans du code C qui parse des données binaires ou textuelles contrôlées par un attaquant.
CVE-2026-2005 — la plus sévère — se déclenche dans pgcrypto via un message PGP forgé. Le parseur est trompé pour copier plus d'octets que le tampon destination ne peut en contenir. Avec un peu de chaînage, un attaquant peut obtenir une exécution de code arbitraire sous l'identité OS du processus PostgreSQL. Condition requise : avoir accès à pgcrypto et pouvoir appeler ses fonctions de déchiffrement — ce qui est le cas de tout utilisateur de base de données sur une installation standard utilisant cette extension.
CVE-2026-2006 suit le même schéma dans pgp_sym_decrypt : du UTF-8 malformé passe au travers des fonctions pg_mblen et pg_utf_mblen, provoquant des lectures ou écritures hors limites.
CVE-2026-2007 touche cette fois l'extension pg_trgm (trigrammes) : même forme de bug, autre voisinage du code.
Trois débordements de tampon dans du code C de parsing. Le type de vulnérabilité le plus classique qui soit — celui pour lequel le fuzzing a précisément été inventé.
Pourquoi le fuzzing humain n'a pas suffi
Il serait facile de dire « pgcrypto est une extension négligée » et d'en rester là. C'est partiellement vrai : l'extension existe depuis l'ère pré-cloud, son usage est plus discret que celui de PostGIS ou pg_stat_statements, et elle attire moins de regards.
Mais l'explication est plus structurelle. Le fuzzing traditionnel explore l'espace des entrées de façon aveugle ou semi-guidée. Pour atteindre CVE-2026-2005, il faut générer un message PGP syntaxiquement plausible, avec les bons octets au bon endroit pour tromper le parseur juste assez — sans déclencher un rejet précoce. C'est un chemin dans un espace d'entrées immense, avec peu de signaux intermédiaires pour orienter la recherche.
Les outils d'analyse statique classiques, eux, génèrent trop de faux positifs sur du code C bas niveau pour être exploitables à grande échelle sans investissement humain considérable.
C'est ici qu'intervient la différence de nature des outils IA comme Xint Code : ils combinent compréhension sémantique du code, raisonnement sur les flux de données, et exploration guidée par des heuristiques apprises sur des millions de patterns de vulnérabilités. Là où un fuzzer cherche une aiguille dans une botte de foin au hasard, un analyseur IA peut raisonner : « ce tampon est alloué avec cette taille, cette donnée vient de l'extérieur, cette fonction de validation est contournable sous ces conditions... »
Ce que ça change pour les équipes de développement
⚠️ L'impact sur les pratiques DevSecOps est immédiat.
Premièrement, aucune base de code n'est trop mature pour être auditée. Vingt ans d'historique et une communauté mondiale active n'ont pas suffi. Les équipes qui pensent que leur code legacy « a déjà été regardé » doivent revoir cette hypothèse.
Deuxièmement, l'IA ne remplace pas l'expertise humaine — elle l'augmente. Ces CVEs ont été trouvées par un outil autonome, mais leur correction, leur évaluation d'impact, leur priorisation ont nécessité des ingénieurs seniors. L'IA est un auditeur infatigable, pas un architecte.
Troisièmement, pour les projets PHP/Symfony qui s'appuient sur PostgreSQL — ce qui représente une large part des applications modernes — la surface d'attaque inclut les extensions. pgcrypto est utilisée dès qu'on chiffre des données en base (tokens, données sensibles). Si votre application appelle pgp_sym_encrypt / pgp_sym_decrypt, vous étiez potentiellement exposés.
Actions concrètes à engager dès maintenant :
- Vérifier la version de PostgreSQL déployée et appliquer les patches correspondants
- Auditer l'usage de
pgcrypto, pg_trgm et autres extensions dans vos environnements
- Intégrer des outils d'analyse statique et sémantique dans votre pipeline CI/CD — pas seulement du SAST classique
- Ne pas sous-estimer les dépendances indirectes : votre code Symfony peut être propre, votre infrastructure peut ne pas l'être
Conclusion : l'IA comme nouveau pair de revue
Cet épisode PostgreSQL illustre un changement de paradigme. Pendant des décennies, la sécurité du code open source a reposé sur la loi de Linus : « avec suffisamment d'yeux, tous les bugs sont visibles ». Ces trois CVEs montrent que cette loi a ses angles morts.
Les outils d'analyse autonome par IA ne sont pas une silver bullet. Mais ils explorent l'espace des vulnérabilités d'une façon qualitativement différente des approches précédentes. Ils méritent une place de choix dans la boîte à outils de toute équipe sérieuse sur la sécurité.
Pour MulerTech et nos clients, c'est un signal clair : la veille sécurité doit désormais intégrer les résultats de ces nouveaux outils, au même titre que les bulletins CVE officiels et les audits manuels.
Source originale : Christophe Pettus — Twenty Years, Three CVEs, One AI
