Vulnérabilités de PostgreSQL : types et mesures de protection

Principaux enseignements

• Les vulnérabilités de PostgreSQL se regroupent en quatre catégories : l'injection SQL, l'escalade de privilèges et l'exécution de code, les failles de contrôle d'accès et l'utilisation abusive des outils de sauvegarde.
• La mise à jour du 13 août 2026 a corrigé 28 CVE d'un seul coup, dont la moitié avait obtenu une note de 8,8.
• Le pire scénario n'est pas la fuite d'une table, mais une chaîne d'exploits qui atteint le système d'exploitation hôte.
• Appliquez rapidement les correctifs, limitez les privilèges, sécurisez vos paramètres et n'utilisez pas de version en fin de vie sans correctifs.
• Si vous pensiez que les fonctions d’échappement intégrées à PostgreSQL avaient résolu le problème des injections SQL, la vulnérabilité CVE-2025-1094 prouve le contraire.

PostgreSQL affiche un bilan de sécurité véritablement solide et, à l'instar d'autres bases de données SQL largement déployées bases de données SQL , il publie des avis de sécurité coordonnés à une fréquence prévisible ; cependant, plusieurs des failles récentes se sont avérées particulièrement graves, et certaines permettent même l'exécution de code sur l'hôte.

Les avis de sécurité de 2026 ne laissent entrevoir aucun ralentissement du rythme. Cinq CVE ont été corrigées en février, onze en mai, et vingt-huit en août lors d’une seule publication coordonnée, avec des failles de gravité élevée touchant le serveur principal, les modules contrib et les outils client. Voici un aperçu des types de vulnérabilités que vous rencontrerez concrètement, des conséquences si vous les négligez, et des solutions pour y remédier.

Types de vulnérabilités de PostgreSQL

Remarque concernant les plages de versions ci-dessous : Les avis de sécurité de PostgreSQL répertorient les branches prises en charge qui ont été vérifiées, ce qui ne signifie pas pour autant que toutes les versions antérieures sont exemptes de problèmes. Une partie de ce code est commune à plusieurs branches, tandis qu’une autre ne l’est pas ; ainsi, une version en fin de vie (EOL) telle que PostgreSQL 13 doit être évaluée au cas par cas, sans présumer qu’elle soit vulnérable ou sûre. Ce qui est certain, c’est que personne en amont ne procède plus à cette évaluation à votre place. Le CVE Tracker de TuxCare est le moyen le plus rapide de voir ce qui a réellement été trié pour une version en fin de vie et si un correctif existe déjà via le support de cycle de vie illimité.

Injection SQL

Elle n'est toujours pas morte, même si de nombreux ORM prétendent le contraire. CVE-2025-1094, une vulnérabilité d’injection SQL à haut niveau de gravité découverte par Rapid7 et corrigée en février 2025, a démontré que même des données correctement échappées peuvent se transformer en injection dans des conditions d’encodage inappropriées. Le problème fondamental résidait dans le fait que les fonctions d’échappement de libpq (PQescapeLiteral, PQescapeIdentifier, PQescapeString et PQescapeStringConn) ne parvenaient pas à neutraliser la syntaxe d’échappement dans un texte qui ne passait pas la validation d’encodage. Il s’agissait du même type de bogue que l’on pourrait trouver dans une application web mal conçue, mais enfoui un peu plus profondément. Et le correctif lui-même a perturbé le fonctionnement de ces fonctions d’une autre manière, les amenant à ignorer leurs paramètres de longueur de chaîne et provoquant le plantage de certains appelants, ce qui a nécessité une nouvelle version une semaine plus tard pour régler le problème.

Plus récemment, la vulnérabilité CVE-2026-6637 (CVSS 8,8) a affecté le module « refint contrib » : il s'agit d'un débordement de tampon de pile qui permet à un utilisateur de base de données sans privilèges d'exécuter du code arbitraire en tant qu'utilisateur du système d'exploitation exécutant la base de données.

Cette faille comporte une deuxième vulnérabilité, plus restreinte : si une application déclare une colonne contrôlée par l’utilisateur comme clé primaire « refint cascade », toute personne fournissant la valeur de mise à jour pour cette clé est exposée à une injection SQL. Ces deux vulnérabilités affectent les versions 14 à 18. La vulnérabilité CVE-2026-6638 ajoute un vecteur d'injection via les noms de tables dans la commande `ALTER SUBSCRIPTION … REFRESH PUBLICATION`, permettant à un créateur de table côté abonné d'exécuter du code SQL avec les identifiants du côté publication, bien que cette faille soit bien plus limitée dans la pratique (CVSS 3,7, versions 16 à 18 uniquement).

Le mois d’août a révélé une autre vulnérabilité à connaître. CVE-2026-15741 (CVSS 8,8) est une injection SQL dans le déparsage de la fonction EXTRACT(), où le propriétaire d’un objet peut exécuter du code SQL arbitraire en tant que superutilisateur via une définition d’objet malveillante ; cette vulnérabilité se déclenche partout où des expressions déparsées sont utilisées, notamment dans pg_dump, les commandes psql telles que \sf, ainsi que dans des outils tiers effectuant la même opération. Le schéma est identique dans tous ces cas : une entrée qui devrait être inerte finit par devenir exécutable.

Attention : la vulnérabilité CVE-2025-1094 présente deux voies d’exploitation distinctes. Pour les fonctions de mise entre guillemets de libpq, le risque survient lorsque leur sortie est transmise à psql en tant qu’entrée. Pour les utilitaires en ligne de commande, le déclencheur spécifique est un encodage client BIG5 combiné à EUC_TW ou MULE_INTERNAL sur le serveur. Si votre pile mélange des encodages ou redirige la sortie des requêtes vers psql à un moment quelconque, appliquez le correctif au client.

Élévation de privilèges et exécution de code à distance

Les extensions de langage procédural sont puissantes, et c’est précisément ce qui les rend vulnérables aux attaques. La faille CVE-2024-10979 (CVSS 8,8) permettait à un utilisateur de base de données non privilégié de modifier des variables d’environnement sensibles du processus via PL/Perl, notamment la variable PATH, ce qui suffit souvent à obtenir l’exécution de code arbitraire, même lorsque l’attaquant ne dispose d’aucun compte sur le système d’exploitation de la machine. Cette faille touchait toutes les branches de la 12 à la 17 ; le fait d’utiliser une version récente ne constituait donc pas une protection. PL/Perl a refait surface en août 2026 avec la faille CVE-2026-14670 (CVSS 8,8), un débordement de tampon de la mémoire dynamique lors du retour d’un hachage lié, qui permet au propriétaire d’une fonction d’exécuter du code en tant qu’utilisateur du système d’exploitation de la base de données via un corps de fonction spécialement conçu.

La série de février 2026 a élargi cette catégorie bien au-delà des langages procéduraux. La vulnérabilité CVE-2026-2006 (CVSS 8,8) provient d’une absence de validation de la longueur des caractères multioctets dans le traitement de base du texte : un utilisateur ordinaire de la base de données peut ainsi lancer des requêtes spécialement conçues, provoquer un débordement de tampon et finir par exécuter du code en tant qu’utilisateur du système d’exploitation. Aucune extension n’est requise pour celle-ci. CVE-2026-2005 (CVSS 8,8) correspond à un débordement de tampon du tas dans pgcrypto, accessible à toute personne capable de lui fournir un texte chiffré. Ce problème est plus grave qu'il n'y paraît, car pgcrypto est une extension de confiance : cela signifie qu'un utilisateur non super-utilisateur disposant du privilège CREATE sur la base de données peut l'installer à l'aide de la commande CREATE EXTENSION. CVE-2026-2004 (CVSS 8,8) affecte intarray en raison d’une validation de type manquante sur l’entrée de l’estimateur de sélectivité. Ajoutez à cela CVE-2026-2007, un débordement de mémoire du tas dans pg_trgm à la version 8.2 affectant PostgreSQL 18, et vous obtenez quatre failles de gravité élevée dans une version comportant cinq CVE, dont trois dans des modules contrib.

Il convient de noter qu’un même score CVSS peut correspondre à plusieurs conséquences concrètes. Le CVE-2026-6473, issu de la série de mai, affiche un score de 8,8 pour un débordement d'entier qui permet à un utilisateur de base de données sans privilèges de sous-dimensionner une allocation et d'écrire hors limites. PostgreSQL indique que cela peut entraîner l'exécution de code arbitraire en tant qu'utilisateur du système d'exploitation de la base de données, tandis que les applications transmettant des données d'entrée de l'ordre du gigaoctet aux fonctions concernées peuvent, quant à elles, provoquer une erreur de segmentation chez le fournisseur de données. Il est préférable de lire l'avis de sécurité plutôt que de se contenter du score.

La tendance qui se dégage des vulnérabilités graves est que l’accès au niveau de la base de données se transforme discrètement en accès au niveau de l’hôte. La stratégie de défense consiste à appliquer correctement le principe du « privilège minimal », ce qui implique de limiter les utilisateurs autorisés à créer des fonctions et des objets, de supprimer les extensions que vos applications n’utilisent jamais et de réduire au minimum la surface d’exposition. Ne confondez surtout pas cela avec une alternative à l’application de correctifs, car aucune de ces mesures n’empêche un bug lié à la sécurité de la mémoire dans le traitement du texte au niveau du noyau.

Failles liées au contrôle d'accès et à la sécurité des lignes

Toutes les failles ne se manifestent pas forcément. La faille CVE-2024-10976 provenait d’un suivi incomplet des tables utilisant la sécurité au niveau des lignes ; ainsi, un plan de requête réutilisé pouvait finir par renvoyer ou modifier des lignes qu’il n’aurait pas dû toucher. Elle n’affecte que les bases de données utilisant effectivement la commande CREATE POLICY, ce qui permet de la négliger facilement jusqu’à ce que l’on se souvienne quelles applications dépendent de cette fonctionnalité. CVE-2026-14666 est la version d’août 2026 du même principe : les politiques de sécurité au niveau des lignes mises en cache survivent aux modifications apportées à l’appartenance aux rôles, aux attributs des rôles et à la propriété de la base de données, ce qui fait qu’un utilisateur continue d’effectuer des lectures et des écritures qui étaient autorisées il y a un instant, mais qui ne le sont plus.

La vulnérabilité CVE-2024-10978 fait également partie de cette catégorie. Une application utilisant les commandes SET ROLE ou SET SESSION AUTHORIZATION pourrait appliquer un identifiant utilisateur erroné à une requête, permettant ainsi à un utilisateur disposant de privilèges moindres de consulter ou de modifier des lignes destinées à quelqu'un d'autre. Il ne s'agit pas d'exécution de code, mais exactement du genre de problème qui compromet discrètement un modèle multi-locataires. Ce sont là des failles discrètes, spécifiques à l'application et faciles à manquer, car elles ne provoquent aucun plantage. Les données s'échappent simplement par la petite porte.

La vulnérabilité CVE-2026-6478 (CVSS 6,5) est d’un tout autre genre. Un canal temporel caché dans la comparaison des mots de passe hachés en MD5 permet à un attaquant de récupérer des identifiants suffisamment fiables pour s’authentifier. Cela ne concerne pas le hachage scram-sha-256, qui est désormais la valeur par défaut dans toutes les versions prises en charge depuis un certain temps déjà, mais de nombreuses bases de données en production contiennent encore des hachages MD5 hérités d’une mise à niveau depuis PostgreSQL 13 ou une version antérieure. C’est cette population qui est réellement exposée au risque. Cela concerne les versions 14 à 18, corrigées dans le lot de mai 2026.

Outils de sauvegarde et de restauration

Celle-ci ne correspond pas au modèle mental habituel des vulnérabilités des bases de données, et c'est précisément pour cette raison qu'elle mérite sa propre catégorie.

Les vulnérabilités CVE-2025-8714 et CVE-2025-8715 (toutes deux notées CVSS 8,8) ont été identifiées dans pg_dump en août 2025. La vulnérabilité CVE-2025-8714 permet à un super-utilisateur malveillant sur le serveur d'origine d'injecter des méta-commandes psql dans la sauvegarde, qui s'exécutent sous le compte du système d'exploitation du client lors d'une restauration. La vulnérabilité CVE-2025-8715 fonctionne de manière similaire via un caractère de nouvelle ligne dans un nom d’objet spécialement conçu à cet effet, et elle est sans doute la plus grave des deux : elle ne nécessite qu’un utilisateur du serveur d’origine plutôt qu’un super-utilisateur, et la même attaque peut également permettre une injection SQL en tant que super-utilisateur sur la cible de restauration. Les commandes pg_dumpall, pg_restore et pg_upgrade sont toutes concernées. La faille CVE-2012-0868 avait déjà corrigé ce type de bogue une fois, mais la version 11.20 l’a discrètement réintroduit.

Le correctif a alors lui-même dû être corrigé. La vulnérabilité CVE-2026-18408 (CVSS 8,8, août 2026) a mis au jour une autre faille via l’expansion des entrées, contournant la protection \restrict mise en place pour la vulnérabilité CVE-2025-8714 ; l’utilisation de \unrestrict à elle seule suffisait à rendre à nouveau efficace l’attaque initiale lors de la restauration. Le lot de mai avait déjà ajouté la vulnérabilité CVE-2026-6477 (CVSS 8,8), dans laquelle un superutilisateur du serveur écrase la mémoire de la pile dans psql ou pg_dump via la fonction lo_read() de libpq.

La vulnérabilité CVE-2026-6475 (CVSS 8,8) étend ce problème à pg_basebackup et pg_rewind : le suivi d’un lien symbolique permet à un superutilisateur d’origine de réécrire des fichiers locaux sans rapport, tels que /var/lib/postgres/.bashrc, et de détourner le compte du système d’exploitation. PostgreSQL délimite soigneusement le champ d'application de cette vulnérabilité, et vous devriez en faire de même : le fait de démarrer le serveur après l'exécution de ces commandes implique déjà une confiance implicite envers le superutilisateur d'origine via des mécanismes tels que `shared_preload_libraries` ; par conséquent, le risque concret réside dans les workflows qui déplacent, créent des instantanés ou agissent de quelque manière que ce soit sur les fichiers résultants avant le démarrage du serveur.

Le fil conducteur de toute cette section est que la surface d’attaque n’est pas votre application ni votre pool de connexions, mais bien votre tâche de sauvegarde – une tâche qui s’exécute souvent avec des privilèges élevés et qui fait rarement l’objet de la même attention que la configuration principale de la base de données. Cela nous rappelle également qu’un grand nombre de ces CVE concernent le côté client. PostgreSQL les classe dans la catégorie des composants clients, et l’application de correctifs au serveur n’a aucun effet sur eux. Les machines exécutant psql, pg_dump, pg_basebackup et pg_createsubscriber doivent donc bénéficier de correctifs spécifiques.

Risques liés à l'absence de correction des vulnérabilités de PostgreSQL

Ce n'est pas le genre de décision qu'on peut remettre au prochain sprint. Les conséquences peuvent aller d'une fuite de données gênante jusqu'à la prise de contrôle totale d'un serveur.

Une faille qui coûte cher

Le rapport IBM 2026 sur le coût des fuites de données estime la moyenne mondiale à 4,99 millions de dollars, un record et une hausse de 12 % par rapport à l'année précédente, la détection, l'escalade et la perte d'activité étant les principaux facteurs à l'origine de cette augmentation. Le chiffre qui devrait inquiéter toute personne ayant un cycle de correctifs trop lent est celui du temps. Le délai moyen nécessaire pour identifier et contenir une fuite de données a grimpé à 247 jours, inversant ainsi la tendance à l’amélioration observée depuis cinq années consécutives, et les fuites qui ont dépassé la barre des 200 jours ont coûté environ un tiers de plus que celles qui ont été résolues plus rapidement.

Les organisations qui ont recours à l'IA et à l'automatisation dans les domaines de la prévention, de la détection, des enquêtes et de la réponse ont résolu les failles environ deux mois plus rapidement et ont dépensé 1,93 million de dollars de moins que celles qui n'y ont pas recours. Tout cela renforce l'argument en faveur de l'automatisation de la gestion des vulnérabilités, c'est-à-dire le travail consistant à identifier et à combler les failles avant que quiconque ne puisse en profiter.

Compromission totale du serveur, et pas seulement une perte de données

La vulnérabilité CVE-2025-1094 est directement liée à la vulnérabilité BeyondTrust CVE-2024-12356, qui a été exploitée en tant que faille « zero-day » lors de l’attaque très médiatisée contre le département du Trésor américain. Dans tous les scénarios testés par Rapid7, l’exploitation réussie de la faille BeyondTrust nécessitait d’exploiter la vulnérabilité CVE-2025-1094 pour parvenir à l'exécution de code à distance. Dès lors qu'un attaquant exécute des commandes shell sur l'hôte de la base de données, la base de données elle-même devient le moindre de vos soucis : un déplacement latéral vers le reste de votre parc Linux devient alors possible.

Les équipes qui utilisent PostgreSQL intégré à d’autres produits ne se rendent souvent pas compte qu’elles sont exposées à des risques. PostgreSQL est fourni en tant que dépendance dans de nombreux logiciels tiers, et lorsqu’une vulnérabilité CVE est signalée, on peut se retrouver à appliquer un correctif à une base de données dont on avait oublié l’existence.

Utilisation d'une version en fin de vie (EOL) sans correctifs

Lorsqu’une version majeure arrive en fin de vie, l’équipe en amont cesse de produire des correctifs de sécurité pour celle-ci. De nouvelles vulnérabilités (CVE) continuent d’être découvertes, mais elles ne sont tout simplement plus corrigées sur cette branche. Plusieurs des 2 026 bogues mentionnés ci-dessus affectent toutes les branches prises en charge, de la version 14 à la version 18, et le problème, c’est que PostgreSQL 14 cessera de recevoir des correctifs le 12 novembre 2026 : la version prise en charge aujourd’hui deviendra donc le problème du trimestre prochain. Si vous utilisez PostgreSQL 13, votre version n'apparaîtra pas dans l'avis de sécurité et vous ne recevrez de toute façon pas de correctif de la part du développeur en amont.

C'est exactement ce que le service « Endless Lifecycle Support » de TuxCare de TuxCare a été conçu. Il rétroporte les correctifs CVE pour PostgreSQL 13 et les applique via votre gestionnaire de paquets habituel, la prise en charge de PostgreSQL 14 ayant été annoncée avant même sa date de fin de vie (EOL), ce qui vous permet de rester à jour dès maintenant et de passer à une version prise en charge dès que cela correspondra à votre feuille de route.

Comment se prémunir contre les vulnérabilités de PostgreSQL

La sécurisation de PostgreSQL relève avant tout de la rigueur, et non d'actes héroïques. Trois bonnes habitudes permettent de couvrir une grande partie des risques concrets.

Appliquez les correctifs sans tarder et suivez les CVE

PostgreSQL publie simultanément des mises à jour de sécurité coordonnées pour toutes les branches prises en charge. La série de novembre 2024 a corrigé la vulnérabilité CVE-2024-10979 et ses variantes dans les versions 17.1, 16.5, 15.9, 14.14, 13.17 et 12.21 le même jour. La série de mai 2026 a apporté simultanément onze correctifs aux versions 18.4, 17.10, 16.14, 15.18 et 14.23, tandis que celle du 13 août en a apporté vingt-huit aux versions 18.6, 17.11, 16.15, 15.19 et 14.24. Abonnez-vous aux avis de sécurité et considérez les mises à jour de version mineure comme une maintenance de routine plutôt que comme un projet nécessitant une analyse de rentabilité.

Conseil de pro : Après une mise à jour de version mineure, exécutez SELECT version(); dans psql pour vérifier que le serveur est bien sur la version que vous pensez. Un paquet qui s'est mis à jour correctement mais pour lequel le service n'a jamais été redémarré continuera sans problème à indiquer l'ancienne version. Vérifiez ensuite séparément du côté client, car SELECT version() ne vous donne aucune information sur psql, pg_dump, pg_basebackup ou libpq sur les machines qui les exécutent. Une particularité propre à PostgreSQL 18 : la version 18.5 n’a jamais été publiée après la découverte d’une régression post-wrap ; la version d’août passe donc directement de la 18.4 à la 18.6.

Restriction des privilèges et de la création d'extensions

De nombreuses failles d'attaque de PostgreSQL passent encore par les privilèges au niveau de la base de données, les droits de création d'objets ou l'accès à une extension particulière ; c'est pourquoi le principe du « privilège minimal » reste d'actualité. Limitez le nombre de personnes autorisées à créer des fonctions en PL/Perl et PL/Python, supprimez les extensions que personne n'utilise et veillez à ce que les rôles soient bien restreints de manière générale.

Les failles récemment découvertes dans refint, pgcrypto, intarray et pg_trgm constituent un argument de poids en faveur d’un audit de cette liste d’extensions dès cette semaine plutôt que le trimestre prochain. Ces restrictions auraient permis de colmater la faille CVE-2024-10979 et d’en limiter plusieurs autres, mais elles ne permettront pas d’empêcher une faille de sécurité liée à la gestion de la mémoire dans le cœur du système de traitement du texte ; elles viennent donc s’ajouter aux correctifs plutôt que de les remplacer.

Valider les données saisies et utiliser des requêtes paramétrées

L'échappement est un dernier recours, pas une stratégie en soi. Utilisez des requêtes paramétrées dès que les valeurs proviennent d'une entrée non fiable, afin que celle-ci ne puisse jamais devenir du code SQL exécutable. Pour les parties d'une instruction qui ne peuvent pas être liées en tant que paramètres (c'est-à-dire les identifiants, les noms de tables, le sens de tri et tout autre élément structurel), recourez strictement à une liste blanche. Associez ces deux mesures à une validation en périphérie.

Bonnes pratiques pour prévenir les vulnérabilités de PostgreSQL

Ces contrôles bloquent les vecteurs d'attaque individuels. L'étape suivante consiste à systématiser la détection et la correction des failles, afin que les problèmes soient identifiés et résolus avant que quiconque ne puisse en tirer parti.

Lancer une analyse continue des vulnérabilités

On ne peut pas corriger ce qu’on ne voit pas, et les instances PostgreSQL intégrées se cachent bien, parfois même aux yeux de ceux qui les exploitent. Effectuez des analyses en continu plutôt que trimestrielles, afin qu’un nouveau CVE apparaisse sur votre radar en quelques heures plutôt qu’au prochain audit. Lorsqu’un scanner signale un problème, vérifiez qu’il s’agit bien d’un véritable problème avant de vous précipiter, car traquer un faux positif vous fait perdre un temps que vous ne récupérerez pas.

Automatisez l'application des correctifs et couvrez l'ensemble de la pile

Ce qui prend le plus de temps dans le processus de correction, ce n'est généralement pas la recherche du correctif, mais la fenêtre de maintenance. L'application automatisée des correctifs réduit le délai entre la divulgation et le déploiement, c'est-à-dire la période pendant laquelle une vulnérabilité connue reste exploitable même si un correctif est déjà disponible. C'est également là que la couverture « fin de vie » prend tout son sens, puisque TuxCare rétroporte les correctifs de sécurité vers les versions PostgreSQL en fin de vie prises en charge, ainsi que vers les dépendances directes et transitives couvertes, de sorte qu'une version non prise en charge continue de bénéficier de correctifs.

Conseil d'initié : Définissez votre SLA de correctif en fonction de la date de divulgation du CVE, et non de la date à laquelle quelqu'un l'a remarqué par hasard. Les vulnérabilités exposées à Internet ont tendance à faire l'objet de tentatives d'analyse et d'exploitation peu après la publication d'un avis public ; votre délai doit donc commencer à courir en même temps que le leur.

Configurer Harden et surveiller les journaux

Les paramètres par défaut constituent un point de départ, et non une configuration définitive. Imposez l’utilisation du protocole TLS pour les connexions des clients et rédigez des règles dans le fichier pg_hba.conf qui spécifient les bases de données, les rôles, les réseaux et les méthodes d’authentification qui nécessitent réellement un accès, plutôt que de laisser des entrées trop générales. Supprimez ou ne pastez pas l’installation des extensions contrib que vous n’utilisez pas, et surveillez les journaux à la recherche d’erreurs SQL inhabituelles ou d’échecs répétés de type injection. Étant donné le nombre de bogues récents qui ont touché spécifiquement les extensions contrib, il vaut mieux réduire cette liste dès maintenant plutôt que lors de la prochaine révision prévue.

Protégez PostgreSQL contre l'exploitation des vulnérabilités grâce à TuxCare

Les vulnérabilités de PostgreSQL sont gérables, mais uniquement si vous appliquez les correctifs en temps voulu et que vous ne laissez pas une version arrivée en fin de vie en production sans protection de sécurité. PostgreSQL 13 a atteint sa fin de vie communautaire le 13 novembre 2025 et ne bénéficie plus de correctifs CVE officiels ; PostgreSQL 14 suivra le 12 novembre 2026.

Si l'un ou l'autre se trouve encore dans votre pile, le service « Endless Lifecycle Support » de TuxCare réintègre ces correctifs pour vous, qui sont appliqués via les mises à jour habituelles du gestionnaire de paquets plutôt que par un processus de correction distinct. Vous n’êtes donc pas obligé de choisir entre rester vulnérable et migrer selon les délais imposés par un tiers. Vérifiez d’abord où en sont réellement vos déploiements PostgreSQL, puis comblez les lacunes dans la couverture des correctifs.

Résumé

Nom de l'article

Vulnérabilités de PostgreSQL : types et mesures de protection

Description

Découvrez les vulnérabilités de PostgreSQL, les méthodes d'attaque courantes et les bonnes pratiques pour protéger votre base de données contre les menaces potentielles.

Auteur

Rohan Timalsina

Nom de l'éditeur

de TuxCare

Logo de l'éditeur