[{"data":1,"prerenderedAt":178},["ShallowReactive",2],{"seo-verification":3,"blog-postgresql-cve-2026-6471-patch-instances-self-hosted-fr":6},{"google":4,"bing":5},"EycwPY2XMyTkVzas3n1ygeNJFGAH513qrMjfDljzsMQ","",{"key":7,"data":8},"blog-postgresql-cve-2026-6471-patch-instances-self-hosted-fr",{"id":9,"slug":10,"slugs":11,"title":15,"excerpt":16,"readTime":17,"views":18,"isPinned":19,"publishedAt":20,"category":21,"categories":27,"featuredImage":29,"bgImage":30,"posterImage":31,"relatedSolution":29,"intro":32,"sections":33,"ctaTitle":119,"ctaBody":120,"ctaButton":121,"ctaUrl":122,"relatedPosts":123},339,"postgresql-cve-2026-6471-patch-instances-self-hosted",{"fr":10,"en":12,"ar":13,"es":14},"postgresql-cve-2026-6471-patch-self-hosted-instances","تصحيح-ثغرة-postgresql-cve-2026-6471-الخوادم-الذاتية","cve-2026-6471-postgresql-parchear-instancias-self-hosted","CVE-2026-6471 et -14669 : patcher PostgreSQL sur VPS","Deux failles critiques PostgreSQL corrigées le 13 août 2026 : réplication vers RCE et heap overflow vers RCE. Patcher vos instances via apt ou Docker.",7,1,false,"2026-09-08T00:00:00+00:00",{"id":22,"name":23,"slug":24,"color":25,"icon":26},8,"Sécurité & Monitoring","securite-monitoring","bg-rose-500\u002F10 text-rose-400","security",[28],{"id":22,"name":23,"slug":24,"color":25,"icon":26},null,"\u002Fblog\u002Fcovers\u002Fbg.svg","\u002Fblog\u002Fcovers\u002Fpostgresql-cve-2026-6471-patch-instances-self-hosted-poster.svg","Le 13 août 2026, l'équipe PostgreSQL a publié des correctifs pour 28 vulnérabilités, dont deux qui permettent à un attaquant d'exécuter du code arbitraire avec les droits du processus de base de données. CVE-2026-6471 exploite le décodage logique pour charger une bibliothèque arbitraire — un vecteur présent depuis PostgreSQL 9.4. CVE-2026-14669 est un débordement de tampon dans `to_char()` qui peut être déclenché par n'importe quel utilisateur authentifié. Si vous hébergez PostgreSQL vous-même — dans une instance Supabase, NocoDB, Gitea, Twenty ou toute autre application — voici comment évaluer votre exposition et appliquer le correctif.",[34,38,70,73,76,95,107,110,113,116],{"type":35,"title":36,"body":37},"h2","Ce que font ces deux vulnérabilités","CVE-2026-6471 (CVSS 7.2) touche le mécanisme de décodage logique introduit en PostgreSQL 9.4. Un compte portant l'attribut REPLICATION peut spécifier un plugin de sortie arbitraire lors de la création d'un slot de réplication logique. Avant le correctif, PostgreSQL chargeait le fichier demandé via `dlopen` sans vérifier sa provenance, ce qui permettait d'exécuter du code avec les droits du compte système `postgres`. L'attaquant n'a pas besoin d'un accès réseau direct à votre instance : un pair de réplication compromis, un outil CDC (Change Data Capture) ou un utilisateur interne disposant de l'attribut REPLICATION suffisent. Le correctif ajoute un paramètre `output_plugin_libraries` qui liste les bibliothèques autorisées — par défaut `pgoutput` et `test_decoding` uniquement.\n\nCVE-2026-14669 (CVSS 8.8) est un débordement de tampon de tas dans la fonction `to_char(timestamptz)`. La fonction construit un tampon de travail depuis la chaîne de format, mais les chemins de traitement des fuseaux horaires POSIX copient l'abréviation fournie par l'utilisateur dans ce tampon sans vérification de longueur. Un utilisateur authentifié ordinaire peut déclencher la vulnérabilité en passant une abréviation de fuseau horaire excessivement longue, ce qui écrase les structures adjacentes du tas et détourne le flux d'exécution pour atteindre l'exécution de code arbitraire avec les droits du compte `postgres`.",{"type":39,"title":40,"headers":41,"rows":45},"comparison","Comparatif des deux CVE",[42,43,44],"Critère","CVE-2026-6471","CVE-2026-14669",[46,50,54,57,61,64,67],[47,48,49],"Score CVSS","7.2 (High)","8.8 (High)",[51,52,53],"Composant","Décodage logique","`to_char(timestamptz)`",[55,56,56],"Vecteur","Réseau",[58,59,60],"Privilège minimal requis","Attribut REPLICATION","Utilisateur authentifié",[62,63,63],"Accès public requis","Non",[65,66,66],"Type d'impact","Exécution de code arbitraire",[68,69,69],"Date de correction","2026-08-13",{"type":35,"title":71,"body":72},"Versions affectées et versions corrigées","Les deux CVE touchent toutes les branches maintenues de PostgreSQL. Les versions corrigées, publiées simultanément le 13 août 2026, sont : PostgreSQL 18.6, 17.11, 16.15, 15.19 et 14.24. Toute instance qui tourne sur une version antérieure à ces numéros est exposée. PostgreSQL 13 et les versions antérieures ont atteint leur fin de vie et ne reçoivent plus de correctifs : si votre instance tourne sur une branche en fin de vie, ces CVE s'ajoutent à un risque structurel déjà existant. Les applications qui embarquent PostgreSQL — Supabase, NocoDB, Gitea, Twenty CRM, Planka — sont affectées si elles n'ont pas encore mis à jour leur image de base.",{"type":35,"title":74,"body":75},"Avant de patcher : auditer vos rôles de réplication","Avant d'appliquer le correctif, il vaut la peine de savoir combien de comptes portent l'attribut REPLICATION sur vos instances. La requête suivante liste tous les rôles concernés :\n\n`SELECT rolname, rolreplication, rolsuper FROM pg_roles WHERE rolreplication = true OR rolsuper = true ORDER BY rolsuper DESC, rolname;`\n\nSi vous trouvez des comptes avec REPLICATION qui ne servent pas à une réplication effective (backup, CDC, monitoring), révoquez l'attribut : `ALTER ROLE nom_du_role NOREPLICATION;`. C'est une mesure de contournement partielle en attendant le patch, et une bonne pratique permanente.",{"type":77,"title":78,"steps":79},"steps","Patcher via apt sur Debian et Ubuntu",[80,83,86,89,92],{"title":81,"body":82},"Vérifier la version actuelle","Connectez-vous à votre instance et relevez la version en cours : `psql -U postgres -c 'SELECT version();'`. Notez la branche (14, 15, 16, 17 ou 18) pour installer le bon paquet cible.",{"title":84,"body":85},"S'assurer que le dépôt PGDG est configuré","Les dépôts Debian et Ubuntu standard livrent souvent des versions en retard. Pour obtenir les correctifs à jour, utilisez le dépôt officiel PostgreSQL. Si ce n'est pas déjà fait : `sudo apt install -y postgresql-common && sudo \u002Fusr\u002Fshare\u002Fpostgresql-common\u002Fpgdg\u002Fapt.postgresql.org.sh`. Ce script configure le dépôt PGDG pour votre distribution.",{"title":87,"body":88},"Mettre à jour les paquets","Une mise à jour mineure (17.10 → 17.11, 16.14 → 16.15, etc.) ne requiert pas `pg_upgradecluster` et conserve vos données en place. Exécutez : `sudo apt update && sudo apt install postgresql-17` (adaptez `17` à votre branche). APT installera la version corrigée. Pour les autres branches : `sudo apt install postgresql-16`, `postgresql-15`, `postgresql-14` selon votre cas.",{"title":90,"body":91},"Redémarrer le service","Le service doit être redémarré pour charger le nouveau binaire : `sudo systemctl restart postgresql`. Vérifiez ensuite que le service est reparti correctement : `sudo systemctl status postgresql`.",{"title":93,"body":94},"Confirmer la version après le patch","Reconnectez-vous et vérifiez que la version affichée correspond au correctif : `psql -U postgres -c 'SELECT version();'`. Vous devez voir 17.11, 16.15, 15.19, 14.24 ou 18.6 selon votre branche.",{"type":77,"title":96,"steps":97},"Patcher via Docker",[98,101,104],{"title":99,"body":100},"Tirer l'image corrigée","Les images officielles `postgres` sur Docker Hub ont été mises à jour avec les versions corrigées. Tirez l'image correspondant à votre branche : `docker pull postgres:17.11`, ou avec le tag mineur de votre branche (`postgres:16.15`, `postgres:15.19`, `postgres:14.24`). Pour les images Alpine : `docker pull postgres:17.11-alpine`.",{"title":102,"body":103},"Relancer le conteneur","Si vous utilisez Docker Compose, mettez à jour le tag d'image dans votre `docker-compose.yml`, puis : `docker compose pull && docker compose up -d`. Pour un conteneur lancé directement : `docker stop postgres-container && docker rm postgres-container`, puis relancez avec la nouvelle image. Vos données restent dans le volume monté — vérifiez que le volume est bien déclaré avant de supprimer le conteneur.",{"title":105,"body":106},"Vérifier la version dans le conteneur","Connectez-vous au conteneur et confirmez la version : `docker exec -it postgres-container psql -U postgres -c 'SELECT version();'`. La sortie doit indiquer la version corrigée.",{"type":35,"title":108,"body":109},"Mesures de contournement si le patch est temporairement impossible","Si vous ne pouvez pas redémarrer l'instance immédiatement, trois mesures réduisent l'exposition à CVE-2026-6471 sans appliquer le correctif :\n\nPremièrement, révoquer l'attribut REPLICATION des comptes qui n'en ont pas besoin (`ALTER ROLE nom NOREPLICATION;`). Deuxièmement, restreindre les entrées de réplication dans `pg_hba.conf` aux seules adresses IP des pairs légitimes — remplacer une règle `host replication all 0.0.0.0\u002F0` par des entrées spécifiques à chaque hôte autorisé. Troisièmement, si votre instance n'utilise pas la réplication logique du tout, vous pouvez passer `wal_level = replica` (au lieu de `logical`) dans `postgresql.conf` — cette configuration désactive le décodage logique et ferme le vecteur d'attaque de CVE-2026-6471.\n\nPour CVE-2026-14669, aucun contournement applicatif n'est documenté : le seul remède est la mise à jour du binaire.",{"type":35,"title":111,"body":112},"Vérifier les applications qui embarquent PostgreSQL","Supabase, NocoDB, Gitea, Twenty CRM et Planka embarquent PostgreSQL dans leurs images Docker ou leurs charts Helm. Pour ces applications, la mise à jour PostgreSQL passe par la mise à jour de l'image de l'application elle-même. Vérifiez les notes de version de chaque application : depuis le 13 août 2026, les distributions qui ont publié une mise à jour doivent avoir intégré PostgreSQL 17.11, 16.15 ou équivalent. Si aucune mise à jour n'est disponible pour votre application, vous pouvez déployer un conteneur PostgreSQL séparé à la version corrigée et pointer l'application dessus — ou épingler l'image postgres de base dans votre `docker-compose.yml` à la version corrigée, si l'architecture le permet.",{"type":114,"body":115},"tip","La commande `SELECT version();` dans psql ne suffit pas pour confirmer que le correctif est actif si plusieurs binaires PostgreSQL coexistent sur le même hôte. Vérifiez quel binaire tourne réellement : `pg_lsclusters` sur Debian\u002FUbuntu liste tous les clusters avec leur version. Assurez-vous que le cluster actif utilise bien le binaire mis à jour, et pas un binaire résiduel d'une installation précédente.",{"type":35,"title":117,"body":118},"Déployer PostgreSQL avec accès root pour appliquer les correctifs à la main","Sur un hébergement mutualisé ou dans un environnement PaaS, vous n'avez pas accès au binaire PostgreSQL : la mise à jour dépend de votre fournisseur. Sur un VPS avec accès root, vous appliquez ce correctif en moins de dix minutes, sans dépendre d'un tiers. Vous choisissez le moment du redémarrage, vous gardez la main sur `pg_hba.conf`, et vous auditez vous-même vos rôles de réplication. C'est le modèle qui s'applique naturellement à toute stack auto-hébergée.","Déployez PostgreSQL sur un VPS avec accès root","Un VPS Cloud ServOrbit vous donne un accès root complet pour appliquer ce correctif en moins de dix minutes, configurer `pg_hba.conf` et auditer vos rôles de réplication sans dépendre d'un fournisseur.","Configurer ma solution PostgreSQL sur VPS","\u002Fvps-cloud",[124,147,164],{"id":125,"slug":126,"slugs":127,"title":131,"excerpt":132,"readTime":133,"views":134,"isPinned":19,"publishedAt":135,"category":136,"categories":142,"featuredImage":29,"bgImage":30,"posterImage":144,"relatedSolution":145},56,"heberger-postgresql-vps",{"fr":126,"en":128,"ar":129,"es":130},"postgresql-on-a-vps-a-reliable-and-controlled-database","postgresql-على-خادم-vps-قاعدة-بيانات-موثوقة-ومتحكم-بها","alojar-postgresql-en-un-vps","PostgreSQL sur VPS : base fiable et contrôlée","Hébergez PostgreSQL sur VPS : volumes, sauvegardes, accès réseau limité et configuration saine pour vos applications.",4,0,"2026-04-25T00:00:00+00:00",{"id":137,"name":138,"slug":139,"color":140,"icon":141},6,"Bases de données","bases-de-donnees","bg-teal-500\u002F10 text-teal-400","database",[143],{"id":137,"name":138,"slug":139,"color":140,"icon":141},"\u002Fblog\u002Fcovers\u002Fheberger-postgresql-vps-poster.svg",{"categorySlug":139,"appSlug":146},"postgresql-stack",{"id":148,"slug":149,"slugs":150,"title":154,"excerpt":155,"readTime":156,"views":134,"isPinned":19,"publishedAt":157,"category":158,"categories":159,"featuredImage":29,"bgImage":30,"posterImage":161,"relatedSolution":162},60,"heberger-supabase-vps",{"fr":149,"en":151,"ar":152,"es":153},"hosting-supabase-on-a-vps","استضافة-supabase-على-خادم-vps","alojar-supabase-en-un-vps","Héberger Supabase sur un VPS en 2026","Self-hostez Supabase sur votre VPS : Postgres, Auth, Storage et API REST avec Envoy Gateway. Migration Kong→Envoy, dépannage URLs S3.",11,"2026-04-21T00:00:00+00:00",{"id":137,"name":138,"slug":139,"color":140,"icon":141},[160],{"id":137,"name":138,"slug":139,"color":140,"icon":141},"\u002Fblog\u002Fcovers\u002Fheberger-supabase-vps-poster.svg",{"categorySlug":139,"appSlug":163},"supabase",{"id":165,"slug":166,"slugs":167,"title":171,"excerpt":172,"readTime":133,"views":134,"isPinned":19,"publishedAt":173,"category":174,"categories":175,"featuredImage":29,"bgImage":30,"posterImage":177,"relatedSolution":29},225,"postgresql-fin-de-vie-planifier-montee-version",{"fr":166,"en":168,"ar":169,"es":170},"postgresql-end-of-life-plan-your-major-upgrade","postgresql-ونهاية-الدعم-تخطيط-الترقية-الكبرى","postgresql-fin-de-vida-planificar-actualizacion","PostgreSQL en fin de vie : planifier la montée de version","PostgreSQL suit chaque version majeure cinq ans, jusqu'à un arrêt en novembre. Repérez la vôtre et planifiez la montée sans perdre de données.","2026-08-05T00:00:00+00:00",{"id":137,"name":138,"slug":139,"color":140,"icon":141},[176],{"id":137,"name":138,"slug":139,"color":140,"icon":141},"\u002Fblog\u002Fcovers\u002Fpostgresql-fin-de-vie-planifier-montee-version-poster.svg",1789046131554]