goldendivider/cve-2026-6471-postgres-logical-decoding-dlopenPrueba de concepto del exploit para CVE-2026-6471, que demuestra la escalada de privilegios en PostgreSQL mediante dlopen de decodificación lógica para lograr la ejecución arbitraria de código y una puerta trasera de superusuario.
La decodificación lógica de PostgreSQL permite que un rol que no es superusuario y que posee el privilegio REPLICATION cree un slot de replicación lógica y elija el plugin de salida. En las versiones afectadas no hay ninguna comprobación de autorización en esa elección, por lo que el servidor ejecuta dlopen() sobre lo que apunte el nombre del plugin. Nombrar una ruta de biblioteca ejecuta el código de esa biblioteca dentro del backend de postgres, como la cuenta del sistema operativo que ejecuta el servidor. Eso es ejecución arbitraria de código como el usuario del SO del servidor de base de datos, lo que para una base de datos que contiene los datos de la aplicación equivale efectivamente a una toma de control del servidor.
Corregido en PostgreSQL 18.6, 17.11, 16.15, 15.19 y 14.24 mediante la lista de permitidos output_plugin_libraries (por defecto pgoutput, test_decoding). Cualquier cosa que no esté en esa lista ahora genera un error con library "X" may not be used as an output plugin antes de cualquier dlopen.
Ejecuta los mismos pasos contra ambas compilaciones y solo cambia la versión de PostgreSQL. Una cuenta con privilegios bajos (LOGIN + REPLICATION, no superusuario, sin acceso al SO) hace lo que haría un suscriptor normal de decodificación lógica y luego pide al servidor que cargue una biblioteca arbitraria como plugin de salida. En la compilación vulnerable, esa biblioteca se ejecuta como el usuario postgres del SO y planta un rol backdoor superusuario persistente, por lo que una cuenta solo de replicación termina la ejecución con un inicio de sesión superusuario funcional.
cve-2026-6471-postgres-logical-decoding-dlopen.txt es una solución de Exploitmatic (.txt): datos más aserciones, sin código. El runtime la reproduce contra la máquina. La solución entrega pwn.so en tiempo de ejecución (base64 en el archivo), ejecuta el SQL como el rol de replicación con privilegios bajos y luego inicia sesión como el rol backdoor superusuario que plantó la carga útil.pwn.c es el código fuente de la biblioteca de la carga útil y pwn.so su compilación: un único constructor ELF que se ejecuta como el usuario postgres del SO, se conecta a través del socket local como superusuario de la base de datos (peer/trust) y crea el rol persistente cve6471_backdoor LOGIN SUPERUSER PASSWORD 'BackdoorPass1'. Solo se ejecuta si el servidor realmente carga la biblioteca, es decir, solo en una compilación vulnerable. Compila con gcc -Os -shared -fPIC -o pwn.so pwn.c en una libc de Linux que coincida con la imagen del servidor.Requisitos previos: tienes acceso a docker.
La carpeta lab/ contiene la réplica exacta utilizada para verificar este PoC. Compila y ejecuta las dos máquinas (vulnerable = postgres 16.14, parcheada = postgres 16.15):
docker build -t pg-6471-vuln -f lab/Dockerfile.vuln lab
docker build -t pg-6471-fixed -f lab/Dockerfile.fixed lab
docker run -d --name pg-6471-vuln -p 15432:5432 -e POSTGRES_PASSWORD=lab-super-pw pg-6471-vuln
docker run -d --name pg-6471-fixed -p 15433:5432 -e POSTGRES_PASSWORD=lab-super-pw pg-6471-fixed
Ambas máquinas ejecutan la imagen oficial estándar de postgres con wal_level=logical. El script de inicialización lab/01-repro.sh crea el rol con privilegios bajos que usa la solución, repro_rep LOGIN REPLICATION PASSWORD 'repropass', que no es superusuario.
Luego reproduce la solución:
exploitmatic run cve-2026-6471-postgres-logical-decoding-dlopen.txt 127.0.0.1
Apúntala a la máquina parcheada con una anulación de variable, sin editar archivos:
exploitmatic run cve-2026-6471-postgres-logical-decoding-dlopen.txt 127.0.0.1 \
--var ctr=pg-6471-fixed
ctr es el contenedor docker, pw es la contraseña del rol de replicación.
| objetivo | resultado |
|---|---|
| postgres 16.14 (vulnerable), wal_level=logical | 4/4 verificado, el inicio de sesión backdoor superusuario funciona |
| postgres 16.15 (parcheado), wal_level=logical | 3/4 no verificado, sin backdoor |
Solo para pruebas autorizadas e investigación, en sistemas que poseas o para los que tengas permiso de prueba. Este PoC demuestra una escalada de privilegios posterior a la autenticación: requiere una cuenta de base de datos existente con privilegios bajos y con el atributo REPLICATION, además de una forma de colocar código controlado por el atacante donde el usuario postgres del SO pueda cargarlo. No es un ataque remoto sin autenticación. El código cargado alcanza el superusuario de la base de datos porque la cuenta del SO que posee el servidor puede conectarse a través del socket local como superusuario (peer/trust), que es la práctica estándar de despliegue de PostgreSQL.
| paso | vulnerable 16.14 | parcheado 16.15 |
|---|
| reconocimiento (el rol es de replicación, no superusuario) | pasa | pasa |
| línea base (slot lógico con pgoutput integrado) | pasa | pasa |
| disparador (plugin del slot = ruta de la biblioteca del atacante) | el servidor lo carga | rechazado antes de la carga |
| toma de control (inicio de sesión como backdoor superusuario plantado) | superusuario | no existe tal rol |