Entradas Mensuales

Síguenos en:

Canal Oficial Telegram de elhacker.NET Grupo Facebook elhacker.NET Twitter elhacker.NET Canal Youtube elhacker.NET Comunidad Steam: Grupo elhacker.NET Mastodon

Entradas populares

PostHeaderIcon Fallo de 12 años en PostgreSQL permite ejecutar código en servidores


Se ha revelado una vulnerabilidad en PostgreSQL, identificada como CVE-2026-6471 y apodada PostGREShell, que podría permitir a atacantes con acceso de replicación de bajo nivel ejecutar código arbitrario en los servidores de bases de datos. Este fallo en la decodificación lógica de PostgreSQL existió durante aproximadamente 12 años y ya ha sido corregido en las versiones compatibles.



Una vulnerabilidad de PostgreSQL recientemente revelada, rastreada como CVE-2026-6471 y apodada PostGREShell, podría permitir que atacantes con acceso de replicación de bajo nivel ejecuten código arbitrario en servidores de bases de datos.

El fallo en la decodificación lógica de PostgreSQL existió durante aproximadamente 12 años y ahora ha sido corregido en las versiones compatibles. PostgreSQL se utiliza ampliamente para almacenar datos empresariales, registros de aplicaciones, detalles de clientes, información financiera y cargas de trabajo en la nube.

La vulnerabilidad es especialmente preocupante porque afecta a un tipo de cuenta comúnmente utilizada para copias de seguridad, replicación, recuperación ante desastres y operaciones de captura de datos modificados.

El problema afecta a las cuentas de PostgreSQL que no son superusuarios pero que tienen el atributo REPLICATION. Estas cuentas se utilizan normalmente para dar soporte a la replicación de la base de datos, permitiendo que los servidores en espera y los sistemas de respaldo reciban cambios de la base de datos desde el servidor primario.

Sin embargo, los investigadores descubrieron que una cuenta con habilitada la replicación podría abusar de la función de decodificación lógica para forzar a PostgreSQL a cargar una librería controlada por el atacante.

La decodificación lógica permite que herramientas externas lean los cambios de la base de datos desde el registro de escritura anticipada (write-ahead log) de PostgreSQL. Utiliza complementos (plugins) de salida para dar formato a esos cambios para replicación, analítica, migración y herramientas de canalización de datos.

Vulnerabilidad de PostgreSQL de 12 años

En las versiones vulnerables, PostgreSQL no restringía adecuadamente la ruta de la librería proporcionada como nombre del complemento de salida. Como resultado, un atacante con privilegios de REPLICATION podría dirigir a PostgreSQL hacia una librería compartida maliciosa disponible para la cuenta del sistema operativo que ejecuta la base de datos.

PostgreSQL cargaría entonces el archivo utilizando funciones de carga de librerías del sistema operativo, como dlopen() en Linux y macOS o LoadLibrary() en Windows. El código malicioso se ejecutaría con los permisos del proceso del servidor PostgreSQL.

Exploitation requires only a PostgreSQL account with REPLICATION, wal_level = logical, and reachable SMB port 445 (source : cyera )
La explotación requiere solo una cuenta de PostgreSQL con REPLICATION, wal_level = logical y el puerto SMB 445 accesible (fuente: Cyera)

Esto es importante porque el atacante no necesita derechos de superusuario de PostgreSQL para iniciar el ataque. Una cuenta de replicación con pocos privilegios podría convertirse en el punto de entrada para la ejecución de código en el servidor de la base de datos.

Desde allí, los atacantes podrían intentar acceder a bases de datos sensibles, robar credenciales, alterar permisos de cuentas, instalar puertas traseras persistentes o moverse más profundamente en el entorno.

Cyera Research descubrió la CVE-2026-6471, un fallo que data del lanzamiento de PostgreSQL 9.4 en 2014 y que se origina en restricciones inadecuadas de la ruta de la librería en el flujo de trabajo de replicación lógica.

PostgreSQL’s SQL-level security, including ACLs, permissions, and role-based access, is robust and well-tested ( source :  cyera )
La seguridad a nivel de SQL de PostgreSQL, incluyendo ACL, permisos y acceso basado en roles, es robusta y ha sido bien probada (fuente: Cyera)

El proyecto PostgreSQL ha lanzado parches para la vulnerabilidad. Deberías actualizar a PostgreSQL 18.6, 17.11, 16.15, 15.19 o 14.24, dependiendo de la rama de versión que uses. Las versiones anteriores a estos lanzamientos corregidos están afectadas.

También deberías auditar todas las cuentas con el atributo REPLICATION y eliminar el privilegio de las cuentas que no lo necesiten absolutamente. Las conexiones de replicación deben limitarse mediante reglas estrictas de pg_hba.conf y direcciones IP de origen confiables.

Tu equipo de bases de datos debe revisar la actividad de replicación lógica en busca de intentos inusuales de crear ranuras (slots) de replicación o nombres de complementos sospechosos que contengan rutas del sistema de archivos, cadenas de salto de directorio (traversal) o nombres de librerías inesperados.

Restringir el acceso de red saliente innecesario desde los servidores de bases de datos, especialmente el tráfico SMB y NFS, también puede reducir el riesgo de rutas de entrega de librerías remotas.

La CVE-2026-6471 demuestra que las cuentas operativas de bases de datos pueden convertirse en objetivos de alto impacto. Una credencial de respaldo puede parecer de bajo riesgo, pero en este caso podría proporcionar un camino hacia la ejecución de código y el compromiso total de un entorno PostgreSQL.



Fuentes:
https://cybersecuritynews.com/12-year-old-postgresql-flaw/

0 comentarios :

Publicar un comentario

Los comentarios pueden ser revisados en cualquier momento por los moderadores.

Serán publicados aquellos que cumplan las siguientes condiciones:
- Comentario acorde al contenido del post.
- Prohibido mensajes de tipo SPAM.
- Evite incluir links innecesarios en su comentario.
- Contenidos ofensivos, amenazas e insultos no serán permitidos.

Debe saber que los comentarios de los lectores no reflejan necesariamente la opinión del STAFF.