pgcrypto : 20 ans de failles RCE silencieuses et pourquoi vos droits PUBLIC sont une bombe à retardement

Le 4 mai 2026, ZeroDay.Cloud a publié les analyses techniques de deux vulnérabilités critiques dans l'extension PostgreSQL pgcrypto : CVE-2026-2005 et CVE-2026-2006. Toutes deux permettent une exécution de code à distance (RCE). Toutes deux sont présentes dans le code depuis la contribution initiale de pgcrypto en 2005. Vingt ans de production. Vingt ans dans vos bases de données.

Cette révélation mérite qu'on s'y arrête, non seulement pour comprendre les bugs eux-mêmes, mais surtout pour ce qu'ils révèlent sur la manière dont nous configurons et auditons nos extensions de base de données.

Ce que font réellement ces deux CVE

CVE-2026-2005 est un dépassement de tampon (heap overflow) de 32 octets dans la fonction pgp_parse_pubenc_sesskey(). Concrètement, cette fonction déchiffre la clé de session RSA ou ElGamal contenue dans un message PGP, puis copie le résultat dans un buffer de taille fixe (ctx->sess_key, limité à 32 octets) — sans aucune vérification de taille.

Il suffit de soumettre un message PGP dont la clé de session dépasse cette limite pour provoquer des écritures arbitraires sur le tas (heap) du processus backend PostgreSQL. À partir de là, le chemin vers une RCE complète à l'intérieur du processus de base de données est mécanique.

CVE-2026-2006 est une variante adjacente, centrée sur une absence de validation d'encodage, qui aboutit au même résultat par une porte légèrement différente.

Les correctifs ont été intégrés dans les versions mineures de février 2026 :

• PostgreSQL 18.2
• PostgreSQL 17.8
• PostgreSQL 16.12
• PostgreSQL 15.16
• PostgreSQL 14.21

Si vous êtes à jour, vous êtes protégé. Si vous tournez encore sur 18.0, 17.7 ou toute version antérieure : mettez à jour maintenant.

Le vrai problème : qui peut atteindre cette fonction ?

La condition d'exploitation telle que décrite dans les CVE semble rassurante : "un utilisateur connecté avec le privilège EXECUTE sur pgp_pub_decrypt_bytea()". Cela paraît restrictif.

Mais c'est là que la réalité du terrain change tout.

PostgreSQL, lors de la création d'une extension avec CREATE EXTENSION pgcrypto, accorde par défaut le privilège EXECUTE à PUBLIC — c'est-à-dire à tous les rôles authentifiés. AWS RDS pré-charge l'extension. De nombreux frameworks applicatifs supposent qu'elle est disponible et l'utilisent sans configuration supplémentaire.

Traduisez cela en termes de sécurité applicative : "tout rôle authentifié" équivaut en pratique à "toute injection SQL réussie dans la couche applicative".

Autrement dit, un attaquant qui exploite une injection SQL dans votre application PHP/Symfony n'a pas besoin de compromettre un compte administrateur. Le compte applicatif courant — celui utilisé par votre ORM Doctrine, par exemple — dispose très probablement du droit d'exécuter pgp_pub_decrypt_bytea(). Et donc de déclencher la RCE.

La surface d'attaque est structurellement beaucoup plus large que ce que le texte du CVE laisse entendre.

Les actions concrètes à mener dès maintenant

1. Appliquer le patch en priorité

C'est la seule vraie solution. Mettez à jour PostgreSQL vers une version corrigée (14.21+, 15.16+, 16.12+, 17.8+, 18.2+). Il n'y a pas de contournement fiable à long terme.

2. Révoquer les droits PUBLIC si le patch est impossible cette semaine

Si une mise à jour immédiate est bloquée par vos contraintes opérationnelles, appliquez au minimum cette mitigation :

-- Révoquer l'accès public aux fonctions vulnérables
REVOKE EXECUTE ON FUNCTION pgp_pub_decrypt_bytea(bytea, bytea) FROM PUBLIC;
REVOKE EXECUTE ON FUNCTION pgp_pub_decrypt_bytea(bytea, bytea, text) FROM PUBLIC;

-- Accorder explicitement l'accès uniquement aux rôles qui en ont besoin
GRANT EXECUTE ON FUNCTION pgp_pub_decrypt_bytea(bytea, bytea) TO mon_role_applicatif;

Ce n'est pas une solution définitive, c'est une réduction de la surface d'attaque en attendant le patch.

3. Auditer tous vos droits PUBLIC sur vos extensions

Profitez-en pour requêter l'ensemble des fonctions accessibles à PUBLIC dans vos bases :

SELECT n.nspname AS schema,
       p.proname AS fonction,
       pg_get_function_identity_arguments(p.oid) AS arguments
FROM pg_proc p
JOIN pg_namespace n ON n.oid = p.pronamespace
JOIN pg_extension e ON p.oid = ANY(
    SELECT unnest(extconfig) FROM pg_extension WHERE extname = 'pgcrypto'
    -- Adaptez pour d'autres extensions
)
WHERE has_function_privilege('public', p.oid, 'EXECUTE');

Plus généralement, identifiez toutes les fonctions exposées à PUBLIC, extension par extension, et demandez-vous : est-ce que chaque rôle applicatif a vraiment besoin d'appeler cette fonction ?

4. Renforcer la défense en profondeur côté applicatif

Ces failles rappellent aussi que la sécurité de votre base de données ne commence pas à la couche SQL. Dans vos projets Symfony :

• Utilisez systématiquement les requêtes paramétrées via Doctrine (jamais de concaténation de chaînes dans vos DQL/SQL natifs)
• Appliquez le principe du moindre privilège sur les comptes de connexion à la base
• Séparez les rôles : un rôle en lecture seule pour les opérations qui n'écrivent pas, un rôle restreint pour les opérations critiques
• Activez la journalisation des requêtes suspects et intégrez-la à votre pipeline de monitoring

Ce que cette affaire nous enseigne sur la gestion des extensions

La leçon fondamentale de ces CVE n'est pas "pgcrypto était buggué". C'est "nous installons des extensions sans auditer ce qu'elles exposent par défaut".

CREATE EXTENSION est une opération qui a des implications de sécurité immédiates. Elle modifie les droits dans votre base. Elle expose des fonctions à des rôles qui n'en ont peut-être pas besoin. Et parce que c'est une commande qu'on exécute une fois, lors de la mise en place, on l'oublie ensuite dans les audits de routine.

Intégrez à vos procédures de mise en production un audit systématique des droits accordés lors de l'installation d'une extension. Documentez quels rôles ont besoin de quelles fonctions. Révoquez tout le reste.

Conclusion

Deux vulnérabilités RCE, vingt ans d'exposition silencieuse, une configuration par défaut qui transforme n'importe quelle injection SQL en vecteur de compromission totale du serveur. CVE-2026-2005 et CVE-2026-2006 dans pgcrypto sont un cas d'école sur la façon dont des décisions de configuration anodines — accorder EXECUTE à PUBLIC — peuvent amplifier dramatiquement la portée d'une faille.

Mettez à jour PostgreSQL. Auditez vos droits. Ne laissez pas la commodité de l'installation par défaut devenir votre surface d'attaque.

Source originale : Christophe Pettus — Two Decades, Two RCEs: What pgcrypto Has Been Doing Since 2005, publié le 15 mai 2026 sur The Build.