Vulnerabilidades de PostgreSQL: tipos y cómo protegerse contra ellas

Principales conclusiones

• Las vulnerabilidades de PostgreSQL se agrupan en cuatro patrones: inyección SQL, escalada de privilegios y ejecución de código, fallos en el control de acceso y uso indebido de las herramientas de copia de seguridad.
• La actualización del 13 de agosto de 2026 solucionó 28 CVE de una sola vez, la mitad de las cuales tenían una puntuación de 8,8.
• El peor escenario no es la filtración de una tabla, sino una cadena de exploits que llega hasta el sistema operativo del host.
• Aplica los parches rápidamente, limita los privilegios, configura los parámetros y no utilices una versión obsoleta sin parches.
• Si pensabas que las funciones de escape integradas en PostgreSQL habían resuelto el problema de la inyección SQL, el CVE-2025-1094 demuestra lo contrario.

PostgreSQL cuenta con un historial de seguridad realmente sólido y, al igual que otras bases de datos SQL ampliamente implantadas bases de datos SQL , publica avisos coordinados con una periodicidad predecible; sin embargo, varios de los errores recientes han sido graves, y algunos llegan incluso a permitir la ejecución de código en el servidor.

Los alertas de 2026 no dan señales de que el ritmo vaya a disminuir. En febrero se corrigieron cinco CVE, en mayo once y el 13 de agosto se corrigieron veintiocho en una única publicación coordinada, con fallos de alta gravedad que afectaban al servidor central, a los módulos contrib y a las herramientas de cliente. A continuación, te ofrecemos un resumen de los tipos de vulnerabilidades con los que te encontrarás, qué ocurre si las dejas sin solucionar y cómo se subsana el problema.

Tipos de vulnerabilidades de PostgreSQL

Una nota sobre los rangos de versiones que aparecen a continuación: Los avisos de seguridad de PostgreSQL enumeran las ramas compatibles que se han comprobado, lo cual no equivale a dar el visto bueno a todo lo anterior. Parte de este código se comparte entre ramas y otra parte no, por lo que una versión al final de su ciclo de vida (EOL), como PostgreSQL 13, debe evaluarse por sí misma, en lugar de darla por vulnerable o por segura. Lo que es seguro es que ya nadie en el proyecto original realiza esa evaluación por ti. El CVE Tracker de TuxCare es la forma más rápida de ver qué se ha evaluado realmente para una versión al final de su ciclo de vida y si ya existe un parche a través del servicio Endless Lifecycle Support.

Inyección SQL

Aún no ha desaparecido, por mucho que muchos ORM prometan lo contrario. CVE-2025-1094, una vulnerabilidad de inyección SQL de alta gravedad descubierta por Rapid7 y corregida en febrero de 2025, demostró que incluso una entrada correctamente escapada puede convertirse en una inyección en condiciones de codificación inadecuadas. El problema fundamental era que las funciones de escapado de libpq (PQescapeLiteral, PQescapeIdentifier, PQescapeString y PQescapeStringConn) no lograban neutralizar la sintaxis de escapado en texto que no superaba la validación de codificación. El mismo tipo de error que se encontraría en una aplicación web descuidada, solo que oculto una capa más abajo. Y la propia corrección estropeó esas funciones de otra forma, haciendo que ignoraran sus parámetros de longitud de cadena y provocando fallos en algunas llamadas, lo que requirió otra versión una semana más tarde para solucionarlo.

Más recientemente, la vulnerabilidad CVE-2026-6637 (CVSS 8,8) afectó al módulo «refint contrib» con un desbordamiento de búfer de pila que permite a un usuario de la base de datos sin privilegios ejecutar código arbitrario con los privilegios del usuario del sistema operativo que ejecuta la base de datos.

Existe un segundo ataque, más limitado, en el mismo fallo: si una aplicación declara una columna controlada por el usuario como clave primaria «refint cascade», quienquiera que proporcione el valor de actualización para dicha clave se expone a una inyección SQL. Ambas vías afectan a las versiones 14 a 18. CVE-2026-6638 añade un vector de inyección a través de los nombres de las tablas en la instrucción ALTER SUBSCRIPTION … REFRESH PUBLICATION, lo que permite que quien cree una tabla desde el lado del suscriptor ejecute código SQL con las credenciales del lado de la publicación, aunque en la práctica es mucho más limitado (CVSS 3,7; solo afecta a las versiones 16 a 18).

El mes de agosto trajo consigo otra vulnerabilidad que conviene conocer. CVE-2026-15741 (CVSS 8,8) es una inyección SQL en el proceso de desensamblaje de EXTRACT(), en la que el propietario de un objeto ejecuta código SQL arbitrario como superusuario a través de una definición de objeto maliciosa, y se activa en cualquier lugar donde se utilicen expresiones desensambladas, incluyendo pg_dump, comandos de psql como \sf y herramientas no incluidas en el núcleo que realicen la misma función. El patrón es idéntico en todos los casos: una entrada que debería ser inerte acaba siendo ejecutable.

Atención: CVE-2025-1094 tiene dos vías distintas. En el caso de las funciones de comillas de libpq, el riesgo surge cuando su salida se introduce en psql como entrada. En cuanto a las utilidades de línea de comandos, el desencadenante específico es una codificación BIG5 en el cliente combinada con EUC_TW o MULE_INTERNAL en el servidor. Si tu pila mezcla codificaciones o canaliza la salida de las consultas a psql en cualquier punto, aplica el parche al cliente.

Escalada de privilegios y ejecución remota de código

Las extensiones de lenguaje procedimental son potentes, y eso es precisamente lo que las convierte en un objetivo atractivo para los ataques. La vulnerabilidad CVE-2024-10979 (CVSS 8,8) permitía a un usuario de la base de datos sin privilegios modificar variables de entorno sensibles del proceso a través de PL/Perl, entre ellas la variable PATH, lo que a menudo es suficiente para lograr la ejecución de código arbitrario, incluso cuando el atacante no dispone de una cuenta del sistema operativo en el servidor. Afectó a todas las ramas, desde la 12 hasta la 17, por lo que disponer de una versión reciente no suponía una protección. PL/Perl volvió a ser objeto de ataque en agosto de 2026 con CVE-2026-14670 (CVSS 8,8), un desbordamiento del búfer del montón al devolver un hash vinculado que permite al propietario de una función ejecutar código como el usuario del sistema operativo de la base de datos a través de un cuerpo de función manipulado.

La remesa de febrero de 2026 amplió esta categoría mucho más allá de los lenguajes procedimentales. CVE-2026-2006 (CVSS 8,8) se debe a la falta de validación de la longitud de los caracteres multibyte en el manejo básico de texto, donde un usuario normal de la base de datos envía consultas manipuladas, desborda un búfer y acaba ejecutando código como usuario del sistema operativo. No se necesita ninguna extensión para este caso. CVE-2026-2005 (CVSS 8,8) es un desbordamiento de búfer del montón en pgcrypto al que puede acceder cualquiera que pueda proporcionarle texto cifrado, lo cual es más grave de lo que parece, ya que pgcrypto es una extensión de confianza, lo que significa que un usuario sin privilegios de superusuario, pero con privilegios CREATE en la base de datos, puede instalarla mediante CREATE EXTENSION. CVE-2026-2004 (CVSS 8,8) afecta a intarray debido a la falta de validación de tipos en la entrada del estimador de selectividad. Si añadimos CVE-2026-2007, un desbordamiento de pila en pg_trgm de la versión 8.2 que afecta a PostgreSQL 18, ya son cuatro fallos de alta gravedad en una versión con cinco CVE, tres de ellos en módulos contrib.

Cabe señalar que una puntuación CVSS puede abarcar más de una consecuencia práctica. El CVE-2026-6473, de la tanda de mayo, tiene una puntuación de 8,8 por un desbordamiento de entero que permite a un usuario de la base de datos sin privilegios asignar una memoria insuficiente y escribir fuera de los límites. PostgreSQL afirma que esto podría ejecutar código arbitrario como usuario del sistema operativo de la base de datos, mientras que las aplicaciones que pasen entradas del orden de los gigabytes a las funciones afectadas podrían, en cambio, provocar un error de segmentación en el proveedor de la entrada. Es mejor leer el aviso que fijarse solo en la puntuación.

La tendencia en los casos graves es que el acceso a nivel de base de datos se convierta, de forma silenciosa, en acceso a nivel de host. La estrategia defensiva consiste en aplicar correctamente el principio del «privilegio mínimo», lo que implica restringir quién puede crear funciones y objetos, eliminar las extensiones que tus aplicaciones nunca utilizan y mantener reducida la superficie de exposición. Pero no confundas nada de esto con un sustituto de la aplicación de parches, ya que nada de ello detiene un error de seguridad de memoria en el manejo del texto del núcleo.

Fallos en el control de acceso y en la seguridad de las filas

No todos los errores se detectan fácilmente. El CVE-2024-10976 se debió a un seguimiento incompleto de las tablas que utilizan seguridad a nivel de fila, por lo que un plan de consulta reutilizado podía acabar devolviendo o modificando filas que no debía tocar. Solo afecta a las bases de datos que utilizan realmente la instrucción CREATE POLICY, lo que hace que sea fácil pasarlo por alto hasta que te acuerdes de cuáles de tus aplicaciones dependen de esa función. CVE-2026-14666 es la versión de agosto de 2026 de la misma idea, en la que las políticas de seguridad a nivel de fila almacenadas en caché perduran más allá de los cambios en la pertenencia a roles, los atributos de los roles y la propiedad de la base de datos, por lo que un usuario sigue completando lecturas y escrituras que estaban permitidas hace un momento y que ya no lo están.

CVE-2024-10978 también pertenece a esta categoría. Una aplicación que utilice SET ROLE o SET SESSION AUTHORIZATION podría aplicar un ID de usuario incorrecto a una consulta, lo que permitiría a un usuario con menos privilegios ver o modificar filas destinadas a otra persona. No se trata de ejecución de código, pero es exactamente el tipo de cosa que socava silenciosamente un modelo multitenant. Son los fallos silenciosos, específicos de la aplicación y fáciles de pasar por alto porque nada se bloquea. Los datos simplemente se filtran por la puerta trasera.

CVE-2026-6478 (CVSS 6,5) es otro caso distinto. Un canal de temporización oculto en la comparación de contraseñas con hash MD5 permite a un atacante recuperar credenciales lo suficientemente válidas como para autenticarse. No afecta a scram-sha-256, que lleva ya un tiempo siendo el valor predeterminado en todas las versiones compatibles, pero muchas bases de datos en producción siguen conteniendo hash MD5 heredados de una actualización desde PostgreSQL 13 o versiones anteriores. Esa es la población que realmente está en riesgo. Afecta a las versiones 14 a 18, corregidas en el lote de mayo de 2026.

Herramientas de copia de seguridad y restauración

Esta vulnerabilidad no se ajusta al modelo mental habitual de las vulnerabilidades de las bases de datos, y precisamente por eso merece su propia categoría.

Las vulnerabilidades CVE-2025-8714 y CVE-2025-8715 (ambas con una puntuación CVSS de 8,8) se detectaron en pg_dump en agosto de 2025. La vulnerabilidad CVE-2025-8714 permite a un superusuario malintencionado del servidor de origen introducir metacomandos de psql en la copia de seguridad, que se ejecutan como la cuenta del sistema operativo del cliente durante una restauración. CVE-2025-8715 hace algo similar a través de un salto de línea en un nombre de objeto creado específicamente para ello, y podría decirse que es el peor de los dos: solo requiere un usuario del servidor de origen en lugar de un superusuario, y el mismo ataque también puede provocar una inyección SQL como superusuario en el destino de la restauración. pg_dumpall, pg_restore y pg_upgrade se ven afectados. CVE-2012-0868 ya había corregido este tipo de fallo una vez, y la versión 11.20 lo reintrodujo discretamente.

Entonces, el parche necesitó a su vez un parche. El CVE-2026-18408 (CVSS 8,8, agosto de 2026) descubrió otra vía a través de la expansión de entradas que eludía la protección \restrict introducida para el CVE-2025-8714, siendo \unrestrict por sí solo suficiente para que el ataque original en el momento de la restauración volviera a funcionar. En la actualización de mayo ya se había añadido CVE-2026-6477 (CVSS 8,8), en la que un superusuario del servidor sobrescribe la memoria de la pila en psql o pg_dump a través de la función lo_read() de libpq.

CVE-2026-6475 (CVSS 8,8) amplía el alcance a pg_basebackup y pg_rewind, donde el seguimiento de enlaces simbólicos permite a un superusuario de origen sobrescribir archivos locales no relacionados, como por ejemplo /var/lib/postgres/.bashrc, y secuestrar la cuenta del sistema operativo. PostgreSQL delimita cuidadosamente el alcance de esta vulnerabilidad, y tú también deberías hacerlo: al iniciar el servidor tras ejecutar esos comandos, ya se confía implícitamente en el superusuario de origen a través de mecanismos como shared_preload_libraries, por lo que la exposición práctica se da en flujos de trabajo que mueven, crean instantáneas o realizan cualquier otra acción sobre los archivos resultantes antes de que se inicie el servidor.

El hilo conductor de toda esta sección es que la superficie de ataque no es tu aplicación ni tu grupo de conexiones, sino tu tarea de copia de seguridad —algo que a menudo se ejecuta con privilegios elevados y que rara vez recibe el mismo escrutinio que la configuración principal de la base de datos—. También sirve para recordar que un buen número de estas vulnerabilidades (CVE) se encuentran en el lado del cliente. PostgreSQL las clasifica bajo el componente de cliente, y aplicar parches al servidor no sirve de nada para solucionarlas. Las máquinas en las que se ejecutan psql, pg_dump, pg_basebackup y pg_createsubscriber necesitan que se les apliquen parches por sí mismas.

Riesgos de no corregir las vulnerabilidades de PostgreSQL

No se trata de una decisión del tipo «ya nos ocuparemos de ello en el próximo sprint». Las consecuencias pueden ir desde una filtración de datos embarazosa hasta que un servidor quede totalmente en manos de terceros.

Una filtración que cuesta dinero de verdad

El Informe de IBM de 2026 sobre el coste de una filtración de datos sitúa la media mundial en 4,99 millones de dólares, una cifra récord que supone un aumento del 12 % respecto al año anterior, impulsado principalmente por la detección, la escalada y la pérdida de negocio. La cifra que debería preocupar a cualquiera que tenga un ciclo de parches lento es el tiempo. El tiempo medio para identificar y contener una filtración ascendió a 247 días, invirtiendo la tendencia de cinco años consecutivos de mejora, y las filtraciones que superaron la barrera de los 200 días costaron aproximadamente un tercio más que las que se resolvieron antes.

Las organizaciones que utilizan la inteligencia artificial y la automatización en las fases de prevención, detección, investigación y respuesta resolvieron las brechas de seguridad aproximadamente dos meses antes y gastaron 1,93 millones de dólares menos que aquellas que no las utilizaban. Todo ello refuerza el argumento a favor de aplicar esa automatización a la gestión de vulnerabilidades, es decir, a la labor de detectar y subsanar las brechas antes de que alguien las aproveche.

Compromiso total del servidor, no solo pérdida de datos

La vulnerabilidad CVE-2025-1094 está directamente relacionada con la vulnerabilidad de BeyondTrust CVE-2024-12356, que fue explotada como una vulnerabilidad de día cero en el sonado ataque contra el Departamento del Tesoro de EE. UU. En todos los escenarios probados por Rapid7, para explotar con éxito la vulnerabilidad de BeyondTrust era necesario explotar la CVE-2025-1094 con el fin de lograr la ejecución remota de código. Una vez que alguien está ejecutando comandos de shell en el servidor de la base de datos, la propia base de datos es la menor de las preocupaciones: se hace posible el movimiento lateral por el resto del parque informático Linux.

Los equipos que utilizan PostgreSQL integrado en otros productos a menudo ni siquiera se dan cuenta de que están expuestos. PostgreSQL se incluye como dependencia en muchos programas de terceros y, cuando se publica un CVE, es posible que te veas obligado a aplicar parches a una base de datos que habías olvidado que tenías.

Ejecutar una versión al final de su ciclo de vida sin parches

Una vez que una versión principal llega al final de su ciclo de vida, el desarrollador original deja de ofrecer correcciones de seguridad para ella. No es que dejen de descubrirse nuevas vulnerabilidades (CVE), sino que simplemente dejan de corregirse en esa rama. Varios de los 2026 errores mencionados anteriormente afectan a todas las ramas con soporte, desde la 14 hasta la 18, y lo peor es que PostgreSQL 14 dejará de recibir correcciones el 12 de noviembre de 2026, por lo que la versión con soporte actual será un problema del próximo trimestre. Si utilizas PostgreSQL 13, no verás tu versión en el aviso y, en cualquier caso, tampoco recibirás ninguna corrección del desarrollador original.

Esto es exactamente lo que el servicio «Endless Lifecycle Support» de TuxCare de TuxCare. Este servicio retrocompila las correcciones CVE para PostgreSQL 13 y las aplica a través de tu gestor de paquetes habitual, con cobertura para PostgreSQL 14 anunciada antes de su fecha de fin de vida útil (EOL), de modo que puedas mantenerte al día con los parches ahora y pasar a una versión compatible cuando realmente se ajuste a tu plan de desarrollo.

Cómo protegerse contra las vulnerabilidades de PostgreSQL

La seguridad de PostgreSQL es, sobre todo, una cuestión de disciplina, no de hazañas heroicas. Tres hábitos permiten mitigar gran parte del riesgo en la práctica.

Aplica las actualizaciones sin demora y realiza un seguimiento de los CVE

PostgreSQL publica al mismo tiempo actualizaciones de seguridad coordinadas para todas las ramas compatibles. El lote de noviembre de 2024 corrigió el CVE-2024-10979 y sus variantes en las versiones 17.1, 16.5, 15.9, 14.14, 13.17 y 12.21 el mismo día. El lote de mayo de 2026 incorporó once correcciones en las versiones 18.4, 17.10, 16.14, 15.18 y 14.23 simultáneamente, y el del 13 de agosto incluyó veintiocho en las versiones 18.6, 17.11, 16.15, 15.19 y 14.24. Suscríbete a los avisos y considera las actualizaciones de versión menor como mantenimiento rutinario, en lugar de como un proyecto que requiera un análisis de viabilidad.

Consejo de experto: Tras una actualización de versión menor, ejecuta SELECT version(); en psql para confirmar que el servidor está realmente en la versión que crees que está. Un paquete que se haya actualizado correctamente pero cuyo servicio no se haya reiniciado seguirá mostrando la versión antigua. A continuación, comprueba por separado el lado del cliente, ya que SELECT version() no te dice nada sobre psql, pg_dump, pg_basebackup o libpq en los equipos donde se ejecutan. Una trampa específica de PostgreSQL 18: la versión 18.5 nunca se lanzó al detectarse una regresión tras el proceso de empaquetado, por lo que la versión de agosto salta directamente de la 18.4 a la 18.6.

Restricción de privilegios y creación de extensiones

Muchas vías de ataque a PostgreSQL siguen pasando por los privilegios a nivel de base de datos, los derechos de creación de objetos o el acceso a una extensión concreta, por lo que el principio del «privilegio mínimo» sigue demostrando su utilidad. Limita quién puede crear funciones en PL/Perl y PL/Python, elimina las extensiones que nadie utilice y mantén los roles bien controlados en general.

Los recientes errores detectados en refint, pgcrypto, intarray y pg_trgm constituyen un argumento de peso para auditar esa lista de extensiones esta semana, en lugar de esperar al próximo trimestre. Esas restricciones habrían eliminado la vulnerabilidad CVE-2024-10979 y reducido varias otras, pero no impedirán que se produzca un error de seguridad de la memoria en el manejo de texto del núcleo, por lo que se suman a la aplicación de parches en lugar de sustituirla.

Validar los datos introducidos y utilizar consultas parametrizadas

La evasión es un recurso de último recurso, no una estrategia en sí misma. Utiliza consultas parametrizadas siempre que los valores procedan de entradas no fiables, de modo que dichas entradas nunca tengan la posibilidad de convertirse en código SQL ejecutable. Para aquellas partes de una instrucción que no puedan vincularse como parámetros —es decir, identificadores, nombres de tablas, dirección de ordenación y cualquier otro elemento estructural—, utiliza en su lugar una lista de permitidos muy estricta. Combina ambas medidas con una validación en el punto de entrada.

Buenas prácticas para prevenir vulnerabilidades en PostgreSQL

Esos controles bloquean las vías de ataque individuales. El siguiente paso consiste en sistematizar la detección y la corrección, de modo que los problemas se detecten y se solucionen antes de que nadie pueda aprovecharse de ellos.

Ejecutar un análisis continuo de vulnerabilidades

No se puede parchear lo que no se ve, y las instancias de PostgreSQL integradas se ocultan muy bien, a veces incluso a quienes las gestionan. Realiza análisis de forma continua en lugar de trimestral, para que un nuevo CVE aparezca en tu radar en cuestión de horas y no hasta la próxima auditoría. Cuando un escáner detecte algo, confirma que sea real antes de ponerte a dar vueltas, porque perseguir un falso positivo te hace perder un tiempo que no recuperarás.

Automatiza la aplicación de parches y cubre toda la pila

Lo que suele llevar más tiempo en la aplicación de parches no es encontrar la solución, sino la ventana de mantenimiento. La aplicación automatizada de parches reduce el lapso entre la divulgación y la implementación, que es el periodo en el que una vulnerabilidad conocida sigue siendo explotable aunque ya haya una solución disponible. Aquí es también donde la cobertura de fin de vida útil demuestra su utilidad, ya que TuxCare adapta las correcciones de seguridad a las versiones de PostgreSQL en fin de vida útil para las que ofrece soporte, junto con las dependencias directas y transitivas cubiertas, de modo que una versión sin soporte sigue recibiendo parches de todos modos.

Consejo de experto: Establece tu SLA de parches en función de la fecha de divulgación del CVE, no de la fecha en que alguien lo detectó por casualidad. Las vulnerabilidades expuestas a Internet suelen empezar a atraer intentos de análisis y explotación poco después de que se publique un aviso público, por lo que tu plazo debería comenzar cuando comience el de ellos.

Configurar Harden y supervisar los registros

Los valores predeterminados son un punto de partida, no una configuración definitiva. Activa el protocolo TLS para las conexiones de los clientes y escribe reglas en el archivo `pg_hba.conf` que especifiquen las bases de datos, los roles, las redes y los métodos de autenticación que realmente necesitan acceso, en lugar de dejar entradas genéricas sin modificar. Elimina o omite la instalación de las extensiones de «contrib» que no utilices, y presta atención a los registros para detectar errores SQL extraños o fallos repetidos de tipo inyección. Teniendo en cuenta la cantidad de errores recientes que se han producido específicamente en «contrib», merece la pena recortar esa lista ahora mismo, en lugar de hacerlo durante la próxima revisión programada.

Protege PostgreSQL contra los ataques a vulnerabilidades con TuxCare

Las vulnerabilidades de PostgreSQL se pueden gestionar, pero solo si se aplican los parches a tiempo y no se deja una versión fuera de soporte en producción sin protección de seguridad. PostgreSQL 13 superó su fecha de fin de soporte por parte de la comunidad el 13 de noviembre de 2025 y ya no recibe correcciones oficiales de CVE, y PostgreSQL 14 le seguirá el 12 de noviembre de 2026.

Si alguno de los dos sigue en tu pila, el servicio Endless Lifecycle Support de TuxCare te proporciona esas correcciones, que se aplican a través de las actualizaciones habituales del gestor de paquetes en lugar de mediante un proceso de aplicación de parches independiente, para que no tengas que elegir entre seguir expuesto a riesgos o migrar según los plazos que marque otra persona. Comprueba primero cuál es la situación real de tus implementaciones de PostgreSQL y, a continuación, subsana las lagunas en la cobertura de los parches.

Resumen

Nombre del artículo

Vulnerabilidades de PostgreSQL: tipos y cómo protegerse contra ellas

Descripción

Infórmate sobre las vulnerabilidades de PostgreSQL, los métodos de ataque más habituales y las mejores prácticas para proteger tu base de datos frente a posibles amenazas de seguridad.

Autor

Rohan Timalsina

Nombre del editor

TuxCare

Logotipo de la editorial