PostgreSQL ODBC : le pilote de l’application est aussi à corriger

Le composant qui relie l’application à la base

psqlODBC est le pilote qui permet à une application utilisant l’interface ODBC de dialoguer avec PostgreSQL. L’avis CERTFR-2026-AVI-1445 du 3 novembre vise ce composant avant 18.00.0006, pas une version du serveur PostgreSQL portant ce numéro. Une application peut donc conserver un pilote vulnérable alors que le serveur a reçu ses mises à jour.

Les onze fiches NVD citées décrivent des chemins différents. Certaines attaques passent par les réponses d’un serveur non approuvé selon les réglages SSL ; d’autres dépendent de valeurs que l’application transmet au pilote, d’un curseur modifiable ou de la journalisation. La seule présence de PostgreSQL sur le réseau ne réunit pas toutes ces conditions.

Les données traitées par le client comptent aussi

Pour CVE-2026-120057, le pilote copie le résultat de lecture d’un grand objet en faisant confiance à la longueur envoyée par le serveur, sans la comparer à la taille du tampon de l’application. Un serveur non approuvé selon les réglages SSL, ou un intermédiaire, peut alors fournir trop d’octets et écraser de la mémoire du processus client. La fiche nomme la récupération d’une colonne de grand objet comme déclencheur.

CVE-2026-120062 concerne SQLSpecialColumns : des noms de table ou de schéma non fiables sont insérés sans échappement dans une requête de catalogue. Si l’application transmet ces noms à cette fonction, l’appelant peut exécuter du SQL avec les droits de la connexion. CVE-2026-120065 vise un autre chemin, avec un nom de colonne mal échappé dans certains curseurs modifiables ; elle peut notamment changer les lignes qu’une modification ou suppression positionnée atteint.

CVE-2026-120066 concerne les systèmes de type Unix lorsque la journalisation est activée. Le pilote crée par défaut des journaux prévisibles dans /tmp, avec des permissions généralement lisibles par tous, et suit les liens symboliques. Un utilisateur local peut lire du texte de requête et des données, ou faire ajouter le journal à un autre fichier avec les droits de la victime. Ce n’est pas une fuite systématique de toutes les bases.

Identifier le pilote réellement chargé

Demandez à la personne qui maintient l’application si elle utilise psqlODBC, où il est installé et quelle version elle charge réellement. Plusieurs applications ou environnements peuvent avoir leurs propres copies. Une version de pilote ne se déduit ni du numéro du serveur ni de celui de l’application.

Le repère donné par les sources est 18.00.0006. Utilisez le circuit de mise à jour prévu pour votre application ou votre distribution ; ne remplacez pas à la main un fichier embarqué sans vérifier sa compatibilité. Après l’intervention et le redémarrage requis, faites confirmer le pilote chargé, puis le fonctionnement d’une connexion et des opérations utiles dans un environnement de test. Gardez un retour arrière adapté aux données et à la configuration.

La vérification des droits de connexion, des entrées non fiables et de la journalisation reste utile. Elle ne remplace pas le correctif. Cette brève ne propose pas de modifier au hasard les réglages SSL ou de désactiver un contrôle pour retrouver une connexion.

• Préparer les mises à jour et la restauration d’un service↗

Ce que les sources établissent

Les onze réponses NVD relues le 4 novembre contiennent bien une fiche, mais pas encore de configurations CPE. Nous retenons leurs descriptions et la borne psqlODBC qu’elles donnent, sans inventer une liste de paquets de distribution corrigés. Nous avons aussi lu l’avis CERT-FR, pas le bulletin PostgreSQL auquel il renvoie.

Nous n’avons installé ni pilote ni application, reproduit aucune de ces failles ni vérifié un déploiement. Ces sources décrivent des vulnérabilités ; cette lecture n’établit pas une exploitation active ni une compromission de votre application.