La vulnerabilidad CVE-2026-6471 permite a determinadas cuentas con privilegios de replicación ejecutar código como el usuario del sistema que opera PostgreSQL.
Una vulnerabilidad que llevaba presente en PostgreSQL desde 2014 ha obligado a los responsables del popular sistema de bases de datos a reforzar la seguridad de su mecanismo de replicación. El fallo, identificado como CVE-2026-6471, puede permitir la ejecución de código arbitrario en el servidor cuando un atacante dispone de una cuenta con el atributo REPLICATION y se cumplen determinadas condiciones.
El problema ha recibido una puntuación de 7,2 sobre 10 en CVSS y afecta a las versiones anteriores a PostgreSQL 18.6, 17.11, 16.15, 15.19 y 14.24. Las correcciones fueron publicadas el pasado 13 de agosto de 2026.
No se trata de una vulnerabilidad explotable por cualquier usuario de Internet sin credenciales: el atacante necesita previamente privilegios de replicación. Sin embargo, ese permiso aparece habitualmente en infraestructuras de copias de seguridad, servidores secundarios, sistemas de monitorización y plataformas de Change Data Capture (CDC), lo que convierte la actualización en especialmente relevante para administradores de bases de datos.
El fallo de PostgreSQL existe desde 2014
La vulnerabilidad está relacionada con el mecanismo de decodificación lógica —logical decoding—, introducido con PostgreSQL 9.4 en 2014.
Esta tecnología permite extraer los cambios realizados en una base de datos a partir del registro WAL y convertirlos mediante complementos de salida. Es una pieza importante en arquitecturas de replicación y sincronización de datos.
El problema descubierto permitía que un usuario con REPLICATION seleccionara como complemento de decodificación un archivo accesible para la cuenta del sistema operativo que ejecuta PostgreSQL. Al cargarlo como biblioteca, el servidor podía terminar ejecutando código arbitrario con los permisos de esa cuenta.
La firma de seguridad Cyera, que bautizó la vulnerabilidad como PostGREShell, explicó que el nombre del complemento utilizado al crear determinados replication slots llegaba al mecanismo encargado de cargar la biblioteca sin aplicar las restricciones esperadas en esa ruta.
El atacante puede terminar ejecutando código como «postgres»
La consecuencia potencial es considerable.
El código malicioso cargado mediante este mecanismo puede ejecutarse dentro del proceso de la base de datos como el usuario del sistema operativo que ejecuta PostgreSQL, habitualmente postgres.
Los investigadores demostraron en sus pruebas que era posible utilizar el acceso obtenido para modificar directamente el catálogo de roles y convertir la cuenta de replicación en superusuario de PostgreSQL, además de establecer mecanismos de persistencia capaces de sobrevivir a un reinicio del servidor.
Eso no significa que cualquier instalación PostgreSQL pueda ser comprometida remotamente de manera automática. La explotación requiere una combinación concreta de permisos y configuración, incluida una cuenta con REPLICATION; The Hacker News señala además el uso de wal_level = logical.
Windows presenta un escenario especialmente delicado
Los investigadores describen diferencias importantes dependiendo del sistema operativo.
En Windows, una ruta de red SMB puede permitir que el servidor intente obtener una biblioteca desde una máquina controlada por el atacante, sin necesidad de escribir previamente ese archivo en el servidor PostgreSQL.
En Linux y macOS, un escenario equivalente requiere determinadas configuraciones, como el montaje automático mediante NFS. En otros casos, el atacante necesitaría disponer previamente de alguna forma de colocar el archivo malicioso en un lugar accesible por el servidor.
Estas condiciones explican en parte por qué PostgreSQL ha asignado al fallo un CVSS 7,2, en lugar de clasificarlo como una vulnerabilidad crítica explotable sin autenticación.
PostgreSQL introduce una lista de complementos permitidos
La solución no se limita a corregir una línea de código.
PostgreSQL ha incorporado un nuevo parámetro denominado output_plugin_libraries, diseñado para controlar qué bibliotecas pueden utilizarse como complementos de salida durante la decodificación lógica.
La configuración predeterminada permite pgoutput y test_decoding.
Esto tiene una consecuencia práctica para los administradores que utilicen complementos externos como wal2json o decoderbufs: después de actualizar, la decodificación lógica puede quedar bloqueada hasta que esos componentes sean añadidos expresamente a la nueva lista permitida.
Por tanto, actualizar sin revisar previamente la configuración podría afectar a determinados sistemas de replicación o CDC.
Qué versiones de PostgreSQL deben actualizarse
Los responsables de PostgreSQL consideran afectadas las ramas soportadas 14, 15, 16, 17 y 18 anteriores a las versiones corregidas.
Los administradores deberían actualizar como mínimo a PostgreSQL 18.6, 17.11, 16.15, 15.19 o 14.24, dependiendo de la rama utilizada.
Antes de actualizar, The Hacker News recomienda identificar los complementos utilizados por los replication slots, instalar posteriormente la versión corregida y autorizar explícitamente cualquier complemento adicional necesario mediante output_plugin_libraries. La configuración puede recargarse sin reiniciar necesariamente todo el servidor.
Mientras no sea posible aplicar el parche, reducir los usuarios con privilegios REPLICATION, restringir las conexiones de replicación a direcciones conocidas y limitar tráfico SMB y NFS innecesario puede disminuir la superficie de exposición.
No hay constancia pública de explotación activa
Un elemento importante para dimensionar correctamente la amenaza es que, a 4 de septiembre, CVE-2026-6471 no figuraba en el catálogo de vulnerabilidades explotadas conocidas de CISA y The Hacker News afirmó no haber encontrado un proof of concept público.
Eso no elimina el riesgo, pero impide afirmar que exista actualmente una campaña masiva aprovechando el fallo.
El episodio vuelve a mostrar un problema habitual en infraestructuras críticas de software: una vulnerabilidad puede permanecer inadvertida durante más de una década en una funcionalidad utilizada por miles de organizaciones.
En este caso, el agujero nació con la decodificación lógica de PostgreSQL en 2014 y ha necesitado 12 años para ser identificado y corregido. Para empresas que utilicen replicación lógica, copias de seguridad o plataformas CDC, la prioridad ahora es clara: comprobar la versión instalada y actualizar sin perder de vista la nueva configuración de complementos.
