PostgreSQL CVE-2026-6471: de replicación a RCE

CVE-2026-6471 es un fallo de autorización en PostgreSQL que puede transformar el privilegio REPLICATION en ejecución de código arbitrario en el servidor de base de datos. PostgreSQL lo solucionó en las versiones 18.6, 17.11, 16.15, 15.19 y 14.24 el 13 de agosto de 2026. Si tu entorno considera que una cuenta de replicación o de backup conlleva bajo riesgo, revisa esa suposición de inmediato.

Consulté el aviso de seguridad del propio proyecto PostgreSQL antes de fiarme de los titulares más llamativos sobre "PostGREShell". El aviso principal es claro: un usuario sin rol de superusuario que disponga del privilegio REPLICATION puede valerse de la decodificación lógica para cargar un archivo arbitrario accesible para la cuenta del sistema operativo que ejecuta PostgreSQL, lo que puede resultar en la ejecución de código arbitrario bajo dicha cuenta.

¿Qué es exactamente CVE-2026-6471?

CVE-2026-6471 es una verificación de autorización ausente en la decodificación lógica de PostgreSQL. Un rol con el privilegio REPLICATION puede elegir un plugin de salida de decodificación lógica, y las versiones vulnerables de PostgreSQL no restringen adecuadamente qué bibliotecas pueden cargarse. Eso abre una vía directa desde los privilegios de base de datos hasta la ejecución de código en el sistema operativo.

REPLICATION es un privilegio independiente del superusuario de PostgreSQL. Las organizaciones suelen concederlo a servicios de replicación, herramientas de backup, sistemas de captura de datos modificados (CDC) o cuentas operativas, porque dichos sistemas necesitan acceso al registro de escritura anticipada (WAL) y a funciones de replicación sin recibir permisos globales de administración de la base de datos. La vulnerabilidad rompe ese límite de confianza, permitiendo que una cuenta considerada potente pero acotada pase al contexto del sistema operativo del servidor.

PostgreSQL asignó a esta vulnerabilidad una puntuación CVSS 3.0 de 7.2. El vector refleja que el atacante ya requiere un privilegio elevado en la base de datos, y el impacto sigue siendo grave porque su explotación exitosa puede comprometer la confidencialidad, la integridad y la disponibilidad a nivel de servidor.

¿Por qué se habla de un fallo de 12 años en PostgreSQL?

El fallo se describe como un problema de aproximadamente 12 años porque la funcionalidad vulnerable de decodificación lógica se remonta a PostgreSQL 9.4, introducido en 2014. El problema de seguridad pasó desapercibido a lo largo de múltiples ciclos de versiones hasta que fue reportado y corregido en 2026.

Los fallos de larga duración recuerdan que la antigüedad del código no demuestra nada sobre su seguridad. El software de infraestructura maduro puede arrastrar suposiciones durante años simplemente porque nadie ha evaluado un límite de confianza determinado de la forma adecuada. PostgreSQL no es un caso aislado de inseguridad; los sistemas consolidados acumulan funcionalidades potentes, y la interacción entre ellas puede crear rutas de elevación de privilegios inesperadas.

La decodificación lógica es un buen ejemplo. Es un mecanismo legítimo y muy útil para transmitir cambios de la base de datos a sistemas externos. El error radicaba en el grado de control que un rol autorizado a usar la función tenía sobre la carga de código, sobrepasando lo previsto por el modelo de autorización.

¿Qué versiones de PostgreSQL están afectadas?

PostgreSQL indica que las versiones anteriores a 18.6, 17.11, 16.15, 15.19 y 14.24 están afectadas en las ramas con soporte oficial que enumera el aviso. Esas versiones corregidas se publicaron el 13 de agosto de 2026.

Para los administradores, la acción es directa: identifica la versión principal que se ejecuta en cada servidor de bases de datos y verifica la versión secundaria de mantenimiento. Comprueba la compilación real de PostgreSQL en lugar de asumir que el paquete del sistema operativo está "lo bastante actualizado".

Si tu distribución incorpora parches de seguridad mediante backports sin alterar la cadena de versión upstream habitual, consulta el boletín de seguridad de dicha distribución para confirmar el estado. Los números oficiales de la rama upstream de PostgreSQL siguen siendo la referencia más limpia para compilaciones no gestionadas o instaladas directamente.

Las ramas antiguas de PostgreSQL que ya han quedado sin soporte upstream requieren una atención aparte. Una versión mayor antigua puede incluir el diseño vulnerable y no recibir una actualización oficial que lo solucione. Para el software sin soporte, la respuesta segura pasa por una ruta de actualización soportada en lugar de una gestión indefinida de excepciones.

¿Por qué preocupan tanto las cuentas de replicación y backup?

Las cuentas de replicación y backup suelen situarse en un terreno intermedio peligroso entre los usuarios ordinarios y los administradores totales. Es habitual que los equipos protejan la cuenta de superusuario postgres con sumo cuidado mientras una cuenta de servicio con privilegio REPLICATION permanece durante años en un servidor de backup, una plataforma de integración o un gestor de secretos de automatización. Esa cuenta puede verse expuesta mediante una superficie de ataque muy distinta a la de la propia base de datos.

Un sistema de backup puede tener una interfaz web. Un producto de captura de datos modificados puede disponer de conectores y complementos. Un sistema de CI puede inyectar la credencial en las tareas y un servidor de monitorización o automatización puede almacenarla en su configuración. Si cualquiera de esos sistemas se ve comprometido, el atacante puede heredar ese privilegio en la base de datos.

Antes de CVE-2026-6471, una organización podía asumir que perder las credenciales de replicación era grave pero aún contenido. En servidores vulnerables, esa credencial puede convertirse en un trampolín hacia la ejecución en el sistema operativo. La auditoría de privilegios debe considerar, por tanto, las cadenas de explotación además del propósito formalmente documentado de cada cuenta.

¿Puede esta vulnerabilidad tomar el control de todo el servidor?

Según el aviso de PostgreSQL, permite ejecutar código bajo la cuenta del sistema operativo que ejecuta PostgreSQL. Eso no equivale automáticamente a obtener acceso de root o de administrador total en cada equipo, pero representa un compromiso de enorme gravedad.

La cuenta de servicio de PostgreSQL suele ser propietaria de los archivos de la base de datos y puede leer o modificar cualquier información que el motor necesite. Según la configuración del servidor, también puede acceder a configuraciones locales, certificados, sockets, scripts o almacenamiento montado.

A partir de ahí, un atacante puede buscar vías adicionales para escalar privilegios. Que el acceso a root sea viable dependerá del sistema operativo, el bastionado, las vulnerabilidades locales, la configuración de sudo, el aislamiento de contenedores y la distribución de los servicios.

El equipo de respuesta a incidentes debe tratar cualquier explotación exitosa como un compromiso total del servidor aunque no se haya demostrado el acceso como root, ya que el atacante ha saltado de los permisos de SQL al contexto de ejecución del host.

¿Qué deben hacer ahora los administradores de PostgreSQL?

Aplica parches en cada servidor PostgreSQL afectado actualizando a una versión corregida o a un paquete de la distribución que incluya la corrección. Después, audita qué roles poseen el privilegio REPLICATION y si cada uno de ellos todavía lo necesita realmente.

Consulta el catálogo del sistema en busca de roles con capacidades de replicación, asocia cada cuenta a un responsable y sistema concretos y rota las credenciales que hayan podido quedar expuestas en herramientas de menor confianza. Elimina las cuentas en desuso en lugar de dejarlas simplemente deshabilitadas en la documentación.

Revisa también los accesos de red. Una cuenta de replicación no tiene motivo para conectarse desde cualquier dirección, por lo que los controles de acceso basados en host de PostgreSQL y los cortafuegos de red deben restringir estas conexiones a sistemas conocidos siempre que sea posible.

En cuanto a la arquitectura de backup, separa las credenciales de base de datos según su función. Una tarea de backup, un suscriptor de replicación lógica y una plataforma de captura de datos no tienen por qué compartir una única cuenta con altos privilegios: delimitar dominios de confianza más reducidos mitiga el impacto si se filtra una credencial.

La sección más amplia de almacenamiento y backup de Mr.PlanB resulta de utilidad si esta vulnerabilidad te motiva a rediseñar el modo en que la infraestructura de backup accede a los datos de producción. Los sistemas de backup forman parte del perímetro de seguridad porque custodian credenciales y copias exactas de los datos que los atacantes persiguen.

¿El parche elimina la necesidad de rotar credenciales?

El parche cierra la vulnerabilidad, pero es posible que aún debas rotar las credenciales si una cuenta pudo verse expuesta o si los registros muestran actividad de replicación sospechosa. Un parche no puede decirte si una credencial ya fue sustraída con anterioridad.

Examina los registros de conexión, los cambios de rol, la creación de slots de replicación, la actividad de decodificación lógica, las referencias inesperadas a plugins y los eventos del sistema operativo relacionados con la cuenta de servicio de PostgreSQL. Si el servidor cuenta con monitorización en el endpoint, correlaciona los eventos de la base de datos con nuevos procesos o accesos anómalos a archivos.

Si descubres indicios de ejecución de código, reconstruir el entorno puede ser más seguro que limpiarlo in situ. La lógica aplicada a un hipervisor comprometido sirve igualmente para un servidor de bases de datos: una vez que el atacante puede ejecutar código con una cuenta de servicio privilegiada, demostrar la ausencia de mecanismos de persistencia resulta extremadamente difícil.

Mantén las copias de recuperación suficientemente aisladas para que un host de base de datos comprometido no pueda reescribir cada backup. La sección de comparativas de Mr.PlanB puede ayudarte a evaluar estrategias de backup, con un principio fundamental muy claro: el acceso a producción y la autoridad sobre la recuperación no deben depender de una única vía de credenciales.

¿Qué cambiaría tras conocer CVE-2026-6471?

Aplicaría los parches en primer lugar y pasaría a tratar REPLICATION como un rol de seguridad privilegiado y no como un permiso de servicio inofensivo. Toda cuenta que lo posea debe tener un propietario asignado, una red de origen restringida, una política de rotación y un motivo documentado para existir.

También auditaría dónde se guardan esas credenciales. El secreto más peligroso a menudo no está en el servidor de base de datos, sino en un sistema adyacente que nadie consideraba crítico para la seguridad.