PostGREShell, una vulnerabilidad en PostgreSQL convierte las cuentas de replicación en un trampolín para ejecutar código

Una vulnerabilidad en el sistema de replicación lógica de PostgreSQL permite que una cuenta con el atributo REPLICATION cargue código arbitrario en el proceso de la base de datos. El fallo, identificado como CVE-2026-6471 y denominado PostGREShell por Cyera, ha obtenido una puntuación CVSS 7.2.

El ataque no requiere privilegios iniciales de superusuario de PostgreSQL. Sin embargo, sí necesita una cuenta autorizada para la replicación, una capacidad que a menudo se concede a software de copia de seguridad, servidores secundarios, canalizaciones y plataformas de monitorización.

Una vez cargado, el código malicioso se ejecuta con los permisos de la cuenta del sistema operativo que administra PostgreSQL. Desde esa posición también puede manipular los mecanismos internos de la base de datos, hasta asignar privilegios permanentes de superusuario.

A 4 de septiembre de 2026 no hay información que permita clasificar CVE-2026-6471 como una vulnerabilidad incluida en el catálogo Known Exploited Vulnerabilities de CISA. Por tanto, no se conoce ninguna fecha límite de CISA para su corrección.

El punto débil está en la selección del plugin de logical decoding

La vulnerabilidad afecta al logical decoding, una función empleada por la replicación lógica para convertir los cambios registrados por la base de datos en un flujo interpretable por aplicaciones externas.

Cuando un cliente abre una sesión de replicación lógica, crea un slot y especifica qué plugin de salida debe procesar los eventos. PostgreSQL debe entonces localizar y cargar la biblioteca correspondiente.

El problema es la ausencia de un control de autorización, clasificado como CWE-862, Missing Authorization. Un usuario que no sea superusuario, pero que tenga el atributo REPLICATION, puede indicar un archivo arbitrario en lugar de un plugin autorizado.

Según el análisis técnico de Cyera, el analizador del protocolo acepta en el nombre del plugin, delimitado por comillas dobles, varios caracteres útiles para construir una ruta:

• barras diagonales y barras inversas;
• puntos;
• secuencias de traversal de directorios como ../;
• rutas UNC utilizadas en entornos Windows.

El nombre llega al cargador sin una validación suficiente. De este modo, el atacante puede pasar una ruta completa a dlopen(), en lugar de limitarse al nombre de una biblioteca prevista en la configuración.

El payload se carga en el mismo espacio de direcciones del proceso de PostgreSQL. No intervienen sandboxes dedicados y el código puede invocar las API internas de la base de datos con los privilegios del proceso en ejecución.

Por tanto, no basta con considerar fiable una cuenta solo porque no sea superusuario. En este escenario, REPLICATION se convierte en una capacidad para ejecutar código.

De la ejecución en el proceso a la modificación de pg_authid

El primer impacto afecta a la cuenta del sistema operativo que ejecuta PostgreSQL. Una biblioteca maliciosa puede leer y modificar todo aquello a lo que tenga acceso ese proceso, además de interferir directamente en el funcionamiento de la base de datos.

Cyera también ha descrito una vía para obtener privilegios de superusuario de PostgreSQL. El plugin puede invocar funciones internas para operar como superusuario de arranque y modificar directamente pg_authid, el catálogo que contiene los atributos sensibles de las cuentas.

Al establecer los indicadores correspondientes, el atacante puede convertir una identidad existente en un superusuario permanente. Por tanto, el compromiso no queda limitado a la sesión de replicación utilizada para iniciar el ataque.

Con estos privilegios son posibles varias operaciones:

• acceso a las tablas de todas las bases de datos alojadas;
• modificación de configuraciones, roles y objetos;
• lectura de claves privadas accesibles para el proceso de PostgreSQL;
• escritura de archivos en las rutas accesibles para la cuenta operativa;
• ejecución de comandos en el sistema operativo;
• instalación de mecanismos de persistencia.

La persistencia puede incluir la habilitación de accesos sin contraseña, la copia del payload en una ubicación estable y su registro para que se cargue en los nuevos procesos backend. El código también puede volver a aplicar los cambios de privilegios después de un intento de recuperación.

Por ello, revocar únicamente el rol comprometido resulta insuficiente. Si ya se ha instalado o registrado una biblioteca, también es necesario revisar el sistema operativo y los mecanismos de inicio de PostgreSQL.

Versiones vulnerables y releases que deben instalarse

La vulnerabilidad afecta a PostgreSQL. La descripción de NVD indica como vulnerables las versiones anteriores a las siguientes releases con correcciones, cada una dentro de su propia rama:

Rama de PostgreSQL	Primera versión corregida
18	18.6
17	17.11
16	16.15
15	15.19
14	14.24

SecurityWeek sitúa el perímetro afectado entre PostgreSQL 9.4 y 18 e informa de que Cyera verificó el problema también en la versión 18.2. Se trata, por tanto, de una debilidad presente en releases distribuidas desde 2014.

Una línea de resumen asociada a la ficha de CVE recoge la formulación más restringida postgresql postgresql < 14.24. Sin embargo, esta indicación contradice el detalle del advisory, que enumera explícitamente correcciones también para las ramas 15, 16, 17 y 18.

A efectos operativos deben considerarse vulnerables:

• las versiones 18 anteriores a la 18.6;
• las versiones 17 anteriores a la 17.11;
• las versiones 16 anteriores a la 16.15;
• las versiones 15 anteriores a la 15.19;
• las versiones 14 anteriores a la 14.24.

Para las ramas de la 9.4 a la 13 no se indica una release correctiva específica. Las organizaciones que las utilicen deben tenerlo en cuenta en su plan de actualización y evitar interpretar la ausencia de un parche enumerado como ausencia de la vulnerabilidad.

Por qué las cuentas REPLICATION son el objetivo principal

El vector CVSS es CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H. El ataque es accesible a través de la red, presenta una complejidad baja y no requiere la interacción de ningún usuario.

El requisito PR:H indica la necesidad de privilegios elevados. Sin embargo, en el caso de PostGREShell no significa que el atacante deba ser ya administrador de la base de datos: debe controlar una cuenta con el atributo REPLICATION.

Estas credenciales pueden encontrarse en sistemas de copia de seguridad, secretos de las canalizaciones, servidores secundarios o configuraciones de herramientas de observabilidad. Por tanto, una organización podría haberlas protegido con menos rigor que las cuentas clasificadas explícitamente como administrativas.

Las consecuencias afectan tanto a instalaciones locales como a bases de datos accesibles a través de redes corporativas o infraestructuras cloud. Para explotar el fallo siguen siendo necesarias credenciales adecuadas y la posibilidad de iniciar o utilizar una sesión de logical replication.

No se han publicado indicadores de compromiso específicos, como hashes, nombres de payloads o direcciones de red. Tampoco se sabe si la vulnerabilidad ya se está utilizando en ataques reales.

Actualización, auditoría de roles y búsqueda de cargas anómalas

La medida principal consiste en instalar PostgreSQL 18.6, 17.11, 16.15, 15.19 o 14.24, según la rama utilizada. No se ha indicado una medida de mitigación oficial alternativa al parche.

A continuación, los administradores deberían inventariar todas las cuentas con REPLICATION y comprobar que el privilegio está justificado por una necesidad operativa documentada. Cuando no sea necesario, debe eliminarse.

La actividad de detección puede centrarse en:

• creación o uso inusual de slots de replicación lógica;
• sesiones de replicación procedentes de direcciones o sistemas inesperados;
• nombres de plugins que contengan separadores de ruta, ../ o rutas UNC;
• carga de bibliotecas desde directorios no previstos;
• modificaciones anómalas de roles y atributos almacenados en pg_authid;
• cambios en las reglas de autenticación, incluidas las conexiones sin contraseña;
• archivos nuevos o modificados en los directorios accesibles para el proceso de PostgreSQL;
• configuraciones que provoquen la carga persistente de bibliotecas en los nuevos procesos backend.

Si aparecen indicios de explotación, la respuesta no debería limitarse a cambiar las contraseñas. Es necesario considerar comprometidos la base de datos, la cuenta operativa de PostgreSQL y todos los secretos que ese proceso pueda leer.

La rotación de credenciales debe acompañarse de la revisión de las bibliotecas cargadas, los archivos modificados, los roles de superusuario y la configuración de autenticación. Solo después de esta limpieza la actualización podrá cerrar el vector sin dejar activos los mecanismos de persistencia ya instalados.