PostgreSQL, una vulnerabilidad en el logical decoding permite ejecutar código como el usuario `postgres`

PostgreSQL ha corregido CVE-2026-6471, una vulnerabilidad en el sistema de logical decoding que permite cargar bibliotecas compartidas arbitrarias en el servidor de bases de datos.

Para explotarla no es necesario ser superuser. Sin embargo, el atacante debe disponer de una cuenta de PostgreSQL con el atributo REPLICATION, mientras que el servidor debe estar configurado con wal_level = logical.

Una vez cargada la biblioteca, el código se ejecuta dentro del proceso backend con la identidad de la cuenta del sistema que gestiona PostgreSQL, normalmente postgres. Por tanto, las consecuencias pueden incluir el robo o la alteración de datos, la indisponibilidad del servicio, la escalada de privilegios y la persistencia en el sistema.

La vulnerabilidad, bautizada como PostGREShell por los investigadores de Cyera, tiene una puntuación CVSS 3.1 de 7,2 y está clasificada como ausencia de un control de autorización (CWE-862). Vladimir Tokarev y Yu Kunpeng fueron reconocidos por el PostgreSQL Global Development Group por notificarla. Tokarev publicó un análisis técnico el 1 de septiembre.

Qué versiones de PostgreSQL deben actualizarse

Las versiones upstream que corrigen CVE-2026-6471, distribuidas el 13 de agosto, son:

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

Son vulnerables las versiones anteriores de cada una de estas cinco ramas. El aviso del proyecto afecta a las series que todavía reciben soporte, de la 14 a la 18.

Sin embargo, el defecto se remonta a la introducción del logical decoding en PostgreSQL 9.4, en 2014. Las series anteriores a la 14 no están contempladas en el aviso upstream actual, por lo que quienes las utilicen deberían planificar la migración a una versión con soporte, en lugar de interpretar su ausencia de la lista como una prueba de seguridad.

También hay paquetes corregidos para Amazon RDS, Debian, SUSE y Ubuntu. El aviso de Ubuntu USN-8653-1, publicado el 20 de agosto de 2026, distribuye estas versiones:

Ubuntu	Paquete corregido
26.04 LTS	postgresql-18 18.6-0ubuntu0.26.04.1
24.04 LTS	postgresql-16 16.15-0ubuntu0.24.04.1
22.04 LTS	postgresql-14 14.24-0ubuntu0.22.04.1

Ubuntu requiere reiniciar PostgreSQL después de la actualización de seguridad habitual. El paquete también corrige muchas otras vulnerabilidades, no solo la del logical decoding.

Además, PostgreSQL 14 dejará de recibir correcciones el 12 de noviembre de 2026. Las organizaciones que todavía utilicen esta rama deberían incluir en su plan operativo la migración a una versión posterior.

Del nombre del plugin a dlopen(): así se produce el ataque

El logical decoding traduce los cambios registrados en el write-ahead log a un formato que pueden utilizar sistemas externos. Se emplea, por ejemplo, en pipelines de change data capture y en herramientas que transfieren los cambios a otras plataformas.

Durante la creación de un slot de replicación, también mediante CREATE_REPLICATION_SLOT, el cliente puede indicar el output plugin que debe utilizarse. Antes de la corrección, PostgreSQL no verificaba adecuadamente que un usuario con REPLICATION estuviera autorizado a cargar la biblioteca solicitada.

El nombre del plugin llegaba así hasta la función de carga dinámica. El parser del protocolo de replicación aceptaba en los nombres entre comillas separadores de directorios, rutas absolutas y secuencias de recorrido como ../.

El resultado era una llamada a dlopen() sobre un archivo elegido por el atacante, siempre que la cuenta del sistema operativo que ejecuta PostgreSQL pudiera acceder a él. La biblioteca se cargaba en el espacio del proceso backend y su código adquiría los privilegios del usuario postgres.

Las restricciones habituales que el comando SQL LOAD aplica a los usuarios que no son superuser no cubrían esta vía. Por tanto, era posible eludir una protección existente mediante el protocolo de replicación.

La disponibilidad de la biblioteca maliciosa depende de la plataforma:

• en Windows, la ruta puede apuntar a un recurso compartido SMB controlado por el atacante, sin necesidad de copiar antes el archivo al servidor;
• en Linux y macOS, una carga equivalente desde la red requiere que el automount NFS esté activo;
• en los demás escenarios, el atacante debe disponer previamente de algún mecanismo para escribir la biblioteca en el disco del servidor.

En las pruebas de Cyera, el código cargado modificó directamente el catálogo de roles y convirtió la cuenta de replicación en un superuser de PostgreSQL. Los investigadores también desarrollaron tres formas de persistencia capaces de sobrevivir al reinicio.

El privilegio requerido no es superuser, pero sigue siendo sensible

El vector completo asignado a la vulnerabilidad es CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H. Indica un ataque ejecutable de forma remota, de baja complejidad y sin interacción del usuario, pero condicionado a la existencia de privilegios elevados.

La clasificación PR:H puede parecer contradictoria con el hecho de que la cuenta no tenga que ser administradora. En realidad, describe un requisito específico: el atributo REPLICATION debe haberse concedido previamente.

Este privilegio suele asignarse a cuentas técnicas utilizadas por servidores standby, soluciones de backup, plataformas CDC y sistemas de monitorización. Por tanto, el compromiso de una de estas credenciales puede convertirse en ejecución de código en el sistema operativo.

No se conocían pruebas de concepto públicas en los repositorios examinados hasta el 4 de septiembre. En esa misma fecha, CVE-2026-6471 no figuraba en el catálogo CISA Known Exploited Vulnerabilities ni tenía asociada una fecha límite KEV.

Por tanto, no hay indicios públicos de explotación activa. No obstante, el impacto sigue siendo relevante, sobre todo allí donde las cuentas de servicio se comparten, se supervisan poco o están autorizadas a conectarse desde redes amplias.

El parche introduce una lista de permitidos para los output plugins

La corrección añade el parámetro del servidor:

output_plugin_libraries

El valor predeterminado autoriza dos bibliotecas:

pgoutput, test_decoding

Después de la actualización, los plugins de terceros como wal2json y decoderbufs deben añadirse explícitamente a la lista de permitidos. De lo contrario, los slots que los utilicen no podrán iniciar correctamente el logical decoding.

Antes de instalar el parche, los administradores pueden identificar los plugins asociados a los slots mediante:

SELECT DISTINCT plugin
FROM pg_replication_slots
WHERE plugin IS NOT NULL;

La consulta devuelve los plugins utilizados correctamente al menos una vez. No detecta necesariamente todas las integraciones configuradas pero todavía no activadas.

Después de actualizar PostgreSQL, todos los plugins legítimos que no estén incluidos en el valor predeterminado deben añadirse a output_plugin_libraries. La configuración puede volver a cargarse con:

pg_ctl reload

o bien:

SELECT pg_reload_conf();

El cambio del parámetro por sí solo no requiere reiniciar el servicio. Siguen siendo válidas las instrucciones más restrictivas de cada distribución, como el reinicio previsto por la actualización de Ubuntu.

PostgreSQL ha optado por una lista de permitidos en lugar de limitarse a ampliar las reglas de LOAD. Esta última solución habría obligado a instalar todos los plugins externos bajo $libdir/plugins, lo que habría interrumpido numerosas configuraciones existentes.

También queda pendiente una limitación operativa. pg_createsubscriber crea slots con pgoutput sin comprobar el nuevo parámetro: --dry-run puede completarse correctamente, mientras que la operación real puede fallar si la lista de permitidos excluye el plugin. Hasta el 4 de septiembre, un parche señalado por Hayato Kuroda, de Fujitsu, todavía estaba en revisión.

En las migraciones desde PostgreSQL 17 o versiones posteriores, la lista de permitidos del nuevo clúster también debe configurarse antes de ejecutar:

pg_upgrade --check

De lo contrario, la comprobación puede fallar cuando los slots existentes dependan de plugins no autorizados.

Comprobaciones inmediatas, mitigaciones y señales que conviene buscar

Si el parche no puede aplicarse de inmediato, los administradores deberían revocar REPLICATION a las cuentas que no tengan una necesidad documentada y restringir en pg_hba.conf las direcciones autorizadas para las conexiones de replicación.

También conviene bloquear desde los servidores de bases de datos el tráfico SMB saliente por el puerto 445 y el tráfico NFS por el puerto 2049, cuando no sean necesarios. autofs debería deshabilitarse en los sistemas que no lo utilicen.

Después de la actualización, los intentos de cargar plugins excluidos de la lista de permitidos generan en los registros un error que contiene:

may not be used as an output plugin

La presencia de este mensaje puede indicar una configuración legítima que todavía no se ha adaptado, pero también un intento de cargar una biblioteca no autorizada. Por tanto, debe correlacionarse con la cuenta, la dirección de origen y el nombre del archivo solicitado.

El análisis también debería incluir:

• cuentas con el atributo REPLICATION;
• slots enumerados en pg_replication_slots;
• plugins asociados a los slots;
• modificaciones inesperadas en el catálogo de roles;
• nuevas formas de persistencia creadas por el usuario operativo de la base de datos;
• conexiones SMB o NFS anómalas originadas desde el servidor PostgreSQL.

La prioridad sigue siendo instalar una versión corregida. La lista de permitidos reduce la exposición sin obligar a reorganizar por completo los plugins, pero requiere un inventario preciso para evitar interrupciones en los pipelines de replicación y change data capture.