Detalles del fallo
PostgreSQL ha lanzado actualizaciones para abordar una falla de seguridad que permite a una cuenta con el atributo REPLICATION ejecutar código arbitrario como el usuario del sistema operativo que ejecuta el servidor de base de datos. La vulnerabilidad, rastreada 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 afectadas son anteriores a PostgreSQL 18.6, 17.11, 16.15, 15.19 y 14.24.
La explotación requiere una cuenta con el atributo REPLICATION y un servidor que funcione con wal_level = logical. Las herramientas de copia de seguridad, los servidores en espera, los pipelines de captura de datos de cambio (CDC) y los sistemas de monitoreo poseen rutinariamente ese atributo.
El parche
La corrección, enviada el 13 de agosto, agrega un parámetro de servidor llamado output_plugin_libraries que enumera qué bibliotecas pueden cargarse como plugins de salida de decodificación lógica, con un valor predeterminado de 'pgoutput, test_decoding'. Las instalaciones que utilicen cualquier otro plugin de salida, como wal2json y decoderbufs, tendrán rechazada la decodificación lógica después de actualizar hasta que un administrador agregue la biblioteca a esa lista y recargue la configuración del servidor.
Anteriormente, un usuario de replicación podía seleccionar cualquier biblioteca cargable para la decodificación lógica, permitiendo diversos tipos de explotación. Para permitir bloquear esto sin romper configuraciones que funcionaban antes, se introduce una lista blanca de plugins de salida permitidos.
El Grupo de Desarrollo Global de PostgreSQL acreditó a Vladimir Tokarev y Yu Kunpeng por reportar el problema. Tokarev lo detalló en un escrito del 1 de septiembre para la firma de seguridad de datos Cyera Research, que llama a la falla PostGREShell.
El nombre del plugin proporcionado en un comando CREATE_REPLICATION_SLOT se pasa directamente a la función que carga la biblioteca, según Cyera. La restricción existente de PostgreSQL sobre las rutas de los plugins, que confina a los no superusuarios a un único directorio controlado por el administrador, nunca se aplica en la ruta de replicación. El analizador del protocolo de replicación acepta casi cualquier carácter dentro de un nombre de plugin entre comillas dobles, incluidos separadores de ruta y el recorrido ../, por lo que una ruta completa del sistema de archivos llega al cargador tal como se escribió.
En Windows, el servidor resuelve una ruta de red sobre Server Message Block (SMB) y obtiene la biblioteca desde una máquina controlada por el atacante, sin escribir nada en el objetivo, según Cyera. En Linux y macOS, el mismo resultado requiere habilitar el montaje automático de Network File System (NFS). En otros lugares, 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 backend de la base de datos como el usuario del sistema operativo postgres.
El plugin de prueba de Cyera luego escribió directamente el catálogo de roles para convertir la cuenta de replicación en un superusuario de PostgreSQL. También estableció tres mecanismos de persistencia que sobreviven a un reinicio del servidor.
Evaluación y respuesta
Cyera describe el atributo REPLICATION como una credencial de copia de seguridad de bajo privilegio, pero PostgreSQL puntuó la falla con Privilegios Requeridos establecidos en Alto, una calificación reproducida en la propia evaluación de SUSE. PostgreSQL rechazó aplicar su restricción LOAD existente a la ruta de replicación.
Los usuarios de REPLICATION no estaban previamente sujetos a restricciones en las rutas de los plugins de salida, por lo que podían eludir las protecciones de tiempo de LOAD durante la decodificación lógica. Desafortunadamente, agregar las restricciones estándar de LOAD ahora haría que todos los plugins de salida de terceros deban instalarse en el directorio $libdir/plugins de manera retroactiva,
dijo Jacob Champion, quien escribió el parche, en el mensaje de confirmación. Las cargas fallidas aparecen en el registro del servidor como ERROR: library "..." may not be used as an output plugin, con una sugerencia que nombra la configuración, según la documentación del parámetro.
Pasos recomendados para administradores
- Ejecute SELECT DISTINCT plugin FROM pg_replication_slots WHERE plugin IS NOT NULL; antes de actualizar para identificar los plugins de salida en uso, que solo mostrará los plugins utilizados con éxito en algún momento.
- Actualice a 18.6, 17.11, 16.15, 15.19 o 14.24, o al paquete de distribución equivalente.
- Agregue cualquier plugin no predeterminado a output_plugin_libraries y recargue la configuración con pg_ctl reload o SELECT pg_reload_conf(). No se requiere reinicio.
- Establezca 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 plugins de slot del clúster anterior.
Los paquetes corregidos están disponibles en Amazon RDS para las cinco ramas, así como en Debian, SUSE y Ubuntu.
El aviso de PostgreSQL cubre las ramas compatibles 14 a 18 y no aborda las anteriores. PostgreSQL 14 dejará de recibir correcciones el 12 de noviembre de 2026, según el anuncio de lanzamiento del proyecto.
El parche de upstream "requiere cambios adicionales en la configuración si se usan algunas extensiones", advierte el aviso de Debian, nombrando sus paquetes wal2json y decoderbufs. El USN-8653-1 de Ubuntu, 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 dice a los administradores que reinicien PostgreSQL después de la actualización.
Al 4 de septiembre, el proyecto wal2json había actualizado su documentación para indicar a los usuarios que agreguen el plugin a output_plugin_libraries, citando el CVE.
Brecha restante
Una brecha en el parche sigue abierta. pg_createsubscriber crea slots de replicación usando pgoutput sin verificar el nuevo parámetro, por lo que un --dry-run tiene éxito y la conversión falla posteriormente.
El comando pg_createsubscriber crea slots de replicación con el plugin 'pgoutput', sin verificar el GUC. Esto significa que si el nombre del plugin 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. Un parche estaba bajo revisión y no se había confirmado al 4 de septiembre. CVE-2026-6471 seguía ausente del catálogo de vulnerabilidades explotadas conocidas (KEV) de CISA al 4 de septiembre. The Hacker News no encontró código de prueba de concepto público en esa misma fecha.
Mitigaciones temporales
Hasta que se pueda aplicar la actualización, Cyera dijo que la exposición se puede reducir eliminando el atributo REPLICATION de 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 deshabilitando autofs donde no sea necesario.
