PostgreSQL lanzó actualizaciones para corregir la vulnerabilidad CVE-2026-6471, que permitía a usuarios con atributos de replicación ejecutar código arbitrario en el servidor. El fallo, presente desde 2014, se soluciona mediante una nueva lista blanca de librerías permitidas llamada output_plugin_libraries. Se recomienda actualizar a las versiones más recientes y configurar manualmente los complementos externos para evitar interrupciones en el servicio.







PostgreSQL ha lanzado actualizaciones para solucionar un fallo de seguridad que permite que una cuenta con el atributo REPLICATION ejecute código arbitrario como el usuario del sistema operativo que ejecuta el servidor de la base de datos.

El fallo, registrado como CVE-2026-6471 (puntuación CVSS: 7.2), ha estado presente desde que se introdujo la decodificación lógica en PostgreSQL 9.4 en 2014. Las versiones anteriores a PostgreSQL 18.6, 17.11, 16.15, 15.19 y 14.24 están afectadas.

La explotación requiere una cuenta con el atributo REPLICATION y un servidor que se ejecute con wal_level = logical. Las herramientas de respaldo, los servidores en espera, las canalizaciones de captura de datos modificados (CDC) y los sistemas de monitoreo suelen tener ese atributo.

La solución, publicada el 13 de agosto, añade un parámetro del servidor llamado output_plugin_libraries que enumera qué librerías pueden cargarse como complementos de salida de decodificación lógica, siendo los valores predeterminados 'pgoutput, test_decoding'.

Las instalaciones que utilicen cualquier otro complemento de salida, entre ellos wal2json y decoderbufs, verán rechazada la decodificación lógica después de actualizar hasta que un administrador añada la librería a esa lista y recargue la configuración del servidor.

"Anteriormente, un usuario de replicación podía seleccionar cualquier librería cargable para la decodificación lógica, permitiendo exploits de diversos tipos. Para permitir bloquear esto sin romper las configuraciones que funcionaban antes, introducimos una lista blanca de complementos de salida permitidos", afirmó el Grupo de Desarrollo Global de PostgreSQL en las notas de lanzamiento de la versión 18.6 [https://www.postgresql.org/docs/release/18.6/].

El Proyecto PostgreSQL acreditó a Vladimir Tokarev y Yu Kunpeng por informar el problema.

Tokarev lo detalló en un informe del 1 de septiembre [https://www.cyera.com/research/postgreshell-the-database-powering-much-of-the-internet-had-an-open-door-for-12-years] para la firma de seguridad de datos Cyera Research, que denomina al fallo PostGREShell.

El nombre del complemento proporcionado en un comando CREATE_REPLICATION_SLOT se pasa directamente a la función que carga la librería, señaló Cyera.

La restricción existente de PostgreSQL sobre las rutas de los complementos, que limita a los no superusuarios a un único directorio controlado por el administrador, nunca se invoca en la ruta de replicación. El analizador del protocolo de replicación acepta casi cualquier carácter dentro de un nombre de complemento entre comillas dobles, incluidos los separadores de ruta y el salto de directorio ../, por lo que una ruta completa del sistema de archivos llega al cargador tal como fue escrita.



En Windows, el servidor resuelve una ruta de red a través de Server Message Block (SMB) y obtiene la librería de una máquina que el atacante controla, sin escribir nada en el objetivo, explicó Cyera.

En Linux y macOS, el mismo resultado requiere habilitar el montaje automático de Network File System (NFS). En cualquier otro caso, el atacante necesita una forma existente de escribir un archivo en el disco del servidor. El código cargado de esta manera se ejecuta dentro del proceso del backend de la base de datos como el usuario del sistema operativo postgres.

El complemento de prueba de Cyera escribió entonces el catálogo de roles directamente para convertir la cuenta de replicación en un superusuario de PostgreSQL. También configuró tres mecanismos de persistencia que sobreviven al reinicio del servidor.

Cyera describe el atributo REPLICATION como una credencial de respaldo de bajos privilegios, pero PostgreSQL calificó el fallo con Privilegios Requeridos configurados como Altos, una calificación reproducida en la propia evaluación de SUSE [https://www.suse.com/security/cve/CVE-2026-6471.html].



PostgreSQL rechazó aplicar su restricción de LOAD existente a la ruta de replicación.

"Los usuarios de REPLICATION no estaban sujetos anteriormente a restricciones en las rutas de los complementos de salida, por lo que podían evadir las protecciones de tiempo de LOAD durante la decodificación lógica. Desafortunadamente, añadir las restricciones estándar de LOAD ahora requeriría retroactivamente que todos los complementos de salida de terceros se instalaran bajo el directorio $libdir/plugins", dijo Jacob Champion, quien escribió la solución, en el mensaje del commit [https://git.postgresql.org/pg/commitdiff/226e49cbed592eaf7a08320efecb814b7492972e].

Las cargas fallidas aparecen en el registro del servidor como ERROR: library "..." may not be used as an output plugin, con una pista que nombra el ajuste, según la documentación del parámetro [https://www.postgresql.org/docs/current/runtime-config-replication.html].

Pasos recomendados para administradores

Se aconseja que tomes las siguientes medidas:

1. Ejecuta SELECT DISTINCT plugin FROM pg_replication_slots WHERE plugin IS NOT NULL; antes de actualizar para identificar los complementos de salida en uso.
2. Actualiza a 18.6, 17.11, 16.15, 15.19, o 14.24, o al paquete de distribución equivalente.
3. Añade cualquier complemento que no sea predeterminado a output_plugin_libraries y recarga la configuración con pg_ctl reload o SELECT pg_reload_conf(). No es necesario reiniciar.
4. Configura el output_plugin_libraries del nuevo clúster antes de ejecutar pg_upgrade --check al migrar desde la versión 17 o posterior, ya que la verificación falla si la lista no permite los complementos de slot del clúster antiguo.

Los paquetes corregidos están disponibles en Amazon RDS [https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html] para las cinco ramas, así como en Debian, SUSE y Ubuntu.

El aviso de PostgreSQL [https://www.postgresql.org/support/security/CVE-2026-6471/] cubre las ramas compatibles de la 14 a la 18 y no aborda las anteriores. PostgreSQL 14 dejará de recibir correcciones el 12 de noviembre de 2026, informó el proyecto en su anuncio de lanzamiento [https://www.postgresql.org/about/news/postgresql-186-1711-1615-1519-1424-and-19-beta-3-released-3365/].

La corrección original "requiere cambios adicionales en la configuración si se utilizan algunas extensiones", advierte el aviso de Debian [https://www.mail-archive.com/debian-lts-announce@lists.debian.org/msg04945.html], mencionando sus paquetes wal2json y decoderbufs.

El USN-8653-1 de Ubuntu [https://ubuntu.com/security/notices/USN-8653-1], que envió la corrección para 22.04, 24.04 y 26.04 LTS el 20 de agosto, no menciona el parámetro y solo indica a los administradores que reinicien PostgreSQL después de la actualización.

Hasta el 4 de septiembre, el proyecto wal2json había actualizado su documentación [https://github.com/eulerto/wal2json/blob/master/README.md] para indicar a los usuarios que añadan el complemento a output_plugin_libraries, citando el CVE.

Todavía queda un vacío en la solución. pg_createsubscriber crea slots de replicación usando pgoutput sin comprobar el nuevo parámetro, por lo que un --dry-run tiene éxito y la conversión posterior falla.

"El comando pg_createsubscriber crea slots de replicación con el complemento 'pgoutput', sin comprobar el GUC. Esto significa que si el nombre del complemento no se especifica en el parámetro, el modo --dry-run pasa pero la conversión real falla. Es muy sorprendente para los usuarios y debería evitarse", dijo Hayato Kuroda de Fujitsu en un mensaje a la lista de correo pgsql-hackers [https://www.mail-archive.com/pgsql-hackers@lists.postgresql.org/msg237836.html].

Un parche estaba bajo revisión y no había sido implementado hasta el 4 de septiembre. El CVE-2026-6471 seguía ausente del catálogo de Vulnerabilidades Explotadas Conocidas (KEV) de CISA [https://www.cisa.gov/known-exploited-vulnerabilities-catalog] hasta el 4 de septiembre.

The Hacker News no encontró código de prueba de concepto en repositorios públicos en la misma fecha.

Hasta que se pueda aplicar la actualización, Cyera señaló que puedes reducir la exposición eliminando el atributo REPLICATION de las cuentas que no lo necesiten, restringiendo las entradas de replicación en pg_hba.conf a direcciones conocidas, bloqueando el tráfico saliente SMB (puerto 445) y NFS (puerto 2049) desde los servidores de base de datos y desactivando autofs donde no sea necesario.

Fuente:
THN