Publicado en

PostgreSQL corrige una vulnerabilidad crítica de 12 años: Riesgos y soluciones para empresas

•Publicado enVulnerabilidades

PostgreSQL soluciona el fallo ‘PostGREShell’ tras más de una década de exposición

El equipo de desarrollo de PostgreSQL ha lanzado una serie de actualizaciones de seguridad críticas para abordar una vulnerabilidad que ha permanecido latente durante 12 años. Identificada como CVE-2026-6471 (con una puntuación CVSS de 7.2), este fallo permite que cuentas con atributos de replicación ejecuten código arbitrario en el sistema operativo que aloja el servidor de base de datos.

Esta vulnerabilidad, bautizada por los investigadores de Cyera como PostGREShell, ha estado presente desde la introducción de la decodificación lógica en PostgreSQL 9.4 en el año 2014. Su descubrimiento subraya la importancia de auditar incluso los componentes más estables y antiguos de la infraestructura tecnológica empresarial.

¿En qué consiste el riesgo técnico?

El problema radica en cómo el sistema gestiona la carga de bibliotecas (plugins) durante los procesos de replicación. Normalmente, PostgreSQL restringe la carga de bibliotecas a directorios específicos controlados por el administrador. Sin embargo, se descubrió que la ruta de replicación no aplicaba estas restricciones.

Un atacante con una cuenta que posea el atributo REPLICATION —comúnmente utilizado por herramientas de backup, sistemas de monitoreo y nodos secundarios— podría suministrar una ruta maliciosa (incluyendo técnicas de path traversal como ../) para cargar una biblioteca externa. Esto resulta en la ejecución de código con los privilegios del usuario del sistema operativo ‘postgres’, lo que podría derivar en el control total del servidor y la escalada a superusuario de la base de datos.

Versiones afectadas y soluciones

El fallo afecta a todas las ramas con soporte activo. Las empresas deben actualizar sus instancias a las siguientes versiones o superiores de manera inmediata:

  • PostgreSQL 18.6
  • PostgreSQL 17.11
  • PostgreSQL 16.15
  • PostgreSQL 15.19
  • PostgreSQL 14.24

La corrección introduce un nuevo parámetro de configuración llamado output_plugin_libraries. Este actúa como una «lista blanca» (whitelist) que define explícitamente qué bibliotecas tienen permitido cargarse para la decodificación lógica. Por defecto, solo se permiten pgoutput y test_decoding.

Recomendaciones para la continuidad de negocio

Desde una perspectiva de gestión de riesgos y ciberseguridad, en Intedya recomendamos a los responsables de IT y CISO seguir estos pasos:

  1. Auditoría de Plugins: Antes de actualizar, identifique los plugins de replicación en uso mediante la consulta: SELECT DISTINCT plugin FROM pg_replication_slots;.
  2. Actualización Programada: Aplique los parches de seguridad oficiales de PostgreSQL o de su proveedor de servicios en la nube (como Amazon RDS).
  3. Configuración del Whitelist: Tras la actualización, añada cualquier plugin legítimo de terceros (como wal2json) al parámetro output_plugin_libraries en el archivo de configuración y recargue el servidor.
  4. Principio de Menor Privilegio: Revise qué cuentas poseen el atributo REPLICATION y elimínelo de aquellas que no lo requieran estrictamente para su función operativa.

La seguridad de las bases de datos es el pilar de la integridad de la información corporativa. Mantener los sistemas actualizados y configurar correctamente las nuevas capas de protección es esencial para mitigar ataques que, como PostGREShell, pueden comprometer años de datos críticos.

Fuentes