PostGREShell: falla en PostgreSQL convirtió cuentas de respaldo en puertas traseras

Una falla presente desde 2014 en la replicación de PostgreSQL podía convertir una cuenta rutinaria de respaldo en ejecución de código, acceso de superusuario y una puerta trasera persistente. El problema ya fue corregido en las ramas afectadas, pero la amplitud de su uso obliga a revisar credenciales, configuraciones y conexiones de red. ***

• La vulnerabilidad CVE-2026-6471 afecta versiones anteriores a PostgreSQL 18.5, 17.11, 16.15, 15.19 y 14.24, según los avisos de seguridad disponibles.
• Una cuenta con el atributo REPLICATION podía cargar una biblioteca maliciosa y ejecutar código dentro del proceso de la base de datos.
• Cyera Research encontró 114 complementos maliciosos de PostgreSQL en circulación, aunque no los vinculó con la explotación de esta falla.

Una vulnerabilidad que permaneció durante más de una década en PostgreSQL podía transformar una cuenta rutinaria de respaldo en una vía para tomar el control de la base de datos y del servidor. El fallo, identificado como CVE-2026-6471 y bautizado PostGREShell por Cyera Research, afecta la funcionalidad de replicación lógica y permite cargar código arbitrario con una cuenta que tenga el atributo REPLICATION, sin exigir privilegios de superusuario.

El alcance potencial es amplio porque PostgreSQL sostiene sistemas de respaldo, réplicas, migraciones, captura de datos modificados y análisis en tiempo real para miles de organizaciones. La investigación señaló que más de 39.000 empresas verificadas utilizan la base de datos en producción, entre ellas Netflix, Instagram, Spotify y Uber, además de servicios como AWS RDS, Azure Database, Google Cloud SQL, Supabase y Neon.

Una falla escondida en la replicación

En una instalación de producción, la base de datos primaria suele trabajar junto con una o más réplicas que mantienen copias sincronizadas. Esta arquitectura permite sostener respaldos, recuperación ante desastres y escalamiento de lecturas, por lo que las cuentas de replicación suelen considerarse componentes operativos de bajo riesgo, aunque mantienen una conexión directa con funciones sensibles del servidor.

PostgreSQL utiliza un protocolo específico para sincronizar esos sistemas y exige el atributo REPLICATION para iniciar la replicación en streaming. Las mismas credenciales aparecen en herramientas de respaldo, servidores en espera, canales de captura de cambios y sistemas de monitoreo que leen el registro de escritura anticipada, de modo que una cuenta aparentemente limitada puede estar presente en numerosos entornos críticos.

El problema se encontraba en los complementos de salida que dan formato a los cambios de la replicación lógica. Cuando un cliente crea un espacio de replicación, también indica el nombre del complemento, que puede ser una biblioteca compilada con extensiones como .so, .dll o .dylib y que PostgreSQL carga dentro del proceso principal de la base de datos.

El sistema ya tenía una defensa llamada check_restricted_library_name(), diseñada para impedir que usuarios no superusuarios cargaran bibliotecas desde rutas absolutas o mediante técnicas de recorrido de directorios. Sin embargo, la ruta utilizada por la replicación no invocaba esa comprobación, por lo que el nombre del complemento llegaba directamente al cargador del sistema operativo sin la validación aplicada al comando SQL LOAD.

De una biblioteca maliciosa al control del servidor

El parser del protocolo de replicación aceptaba numerosos caracteres dentro del nombre del complemento, incluidas barras, puntos, secuencias como ../ y rutas UNC de Windows. Un atacante que lograra entregar un nombre especialmente manipulado podía hacer que PostgreSQL solicitara una biblioteca ubicada en una ruta arbitraria, activando funciones como dlopen() en Linux y macOS o LoadLibrary() en Windows.

La carga de la biblioteca ejecuta de inmediato su función de inicialización dentro del proceso de PostgreSQL. Como el complemento opera en el mismo espacio de direcciones y no existe un aislamiento de código C, las protecciones normales del modelo de permisos SQL dejan de ser suficientes una vez que la biblioteca maliciosa comienza a ejecutarse.

Las condiciones de explotación cambian según el sistema operativo. En Windows, una cuenta con REPLICATION, un servidor configurado con wal_level = logical y acceso de red hacia el puerto SMB 445 podían bastar para que PostgreSQL cargara una DLL alojada en un servidor remoto mediante una ruta UNC, sin que el atacante tuviera que copiar previamente el archivo al equipo objetivo.

En Linux y macOS, la investigación describió escenarios basados en montajes NFS automáticos, especialmente cuando estaba activo autofs, además de casos en los que el atacante ya podía escribir una biblioteca en el disco. En entornos estándar, contenedores Docker o clústeres Kubernetes, la explotación requería ese canal adicional para colocar localmente el archivo malicioso, mientras que Windows ofrecía una ruta completamente remota bajo las condiciones señaladas.

El salto a superusuario y la persistencia

El acceso inicial como usuario del sistema postgres no constituía el final del ataque, según el análisis divulgado. El código cargado podía manipular estructuras internas de PostgreSQL, convertirse en el superusuario de arranque de la sesión y modificar directamente pg_authid, el catálogo que define los privilegios de los roles.

Al operar fuera del ejecutor SQL, esa modificación no atravesaba las verificaciones habituales de listas de control de acceso ni las reglas de permisos. El atacante podía activar los indicadores de superusuario y añadir un mecanismo para que las comprobaciones posteriores devolvieran una respuesta favorable, mientras el cambio quedaba registrado de forma similar a una alteración normal del catálogo.

Con privilegios de superusuario, el atacante podía leer tablas de todas las bases de datos, incluidos datos de clientes, registros financieros, secretos de aplicaciones y credenciales almacenadas. También podía utilizar funciones como COPY ... TO PROGRAM para ejecutar comandos, leer archivos sensibles mediante pg_read_file() o escribir en ubicaciones accesibles para el usuario del sistema con herramientas como lo_export().

La investigación describió además varios mecanismos de persistencia que podían sobrevivir a reinicios y dificultar la limpieza. Entre ellos figuraban cambios en pg_hba.conf para permitir conexiones sin contraseña, copias del complemento en una ruta estable y su registro en shared_preload_libraries, junto con la reaplicación del privilegio de superusuario si un administrador intentaba revertirlo.

Corrección, alcance y medidas urgentes

El Equipo de Seguridad de PostgreSQL recibió el reporte en febrero de 2026 y confirmó la vulnerabilidad el 27 de febrero, antes de coordinar una corrección para una actualización menor. CSO Online informó que los parches se publicaron el 13 de agosto para las versiones 18.6, 17.11, 16.15, 15.19 y 14.24. Los avisos de seguridad identifican como afectadas las versiones anteriores a esas revisiones, mientras que la falla se remonta a ramas que comenzaron con PostgreSQL 9.4, lanzada en 2014.

Aunque CVE-2026-6471 recibió una puntuación CVSS de 7,2, el impacto descrito combina ejecución de código, escalamiento de privilegios, acceso a información y persistencia. La severidad práctica depende de la exposición de las cuentas de replicación, de la configuración de red y de la plataforma, pero la presencia de esas credenciales en operaciones esenciales vuelve insuficiente confiar únicamente en que no sean cuentas de administrador.

La revisión de amenazas de Cyera Research en VirusTotal identificó 114 complementos maliciosos de PostgreSQL, incluidos troyanos, mineros de criptomonedas y shells inversas. La empresa no vinculó esos archivos con la explotación de CVE-2026-6471, por lo que el hallazgo demuestra que los complementos ya atraen actividad maliciosa, pero no confirma que esta vulnerabilidad haya sido utilizada por esos ejemplares.

Los administradores deben instalar primero la actualización correspondiente y auditar todas las cuentas con el atributo REPLICATION. También conviene eliminar ese privilegio cuando no sea estrictamente necesario, limitar las conexiones en pg_hba.conf a direcciones conocidas y evitar reglas de replicación abiertas a todo Internet, como 0.0.0.0/0.

El endurecimiento debe incluir el bloqueo de conexiones salientes innecesarias hacia SMB en el puerto 445 y NFS en el puerto 2049 desde los servidores de bases de datos, además de desactivar autofs cuando no sea requerido. Los equipos de seguridad deberían buscar comandos CREATE_REPLICATION_SLOT desde direcciones inesperadas, nombres de complementos con barras o secuencias de recorrido y espacios de replicación inusuales.

El caso también expone un problema recurrente en los sistemas extensibles: la ruta de carga de complementos puede quedar separada del modelo de seguridad que protege las operaciones principales. PostgreSQL había protegido una vía de carga, pero la ruta de replicación no conectó esa defensa con el mismo control, dejando durante años una entrada secundaria que podía convertir infraestructura rutinaria en compromiso total.

Este contenido se ofrece únicamente con fines informativos generales y no constituye un asesoramiento financiero, de inversión, legal ni fiscal. Cualquier evento, recompensa, promoción en línea o información relacionada que se mencione en el presente documento no debe considerarse como una recomendación, solicitud o invitación a comprar, vender, operar o de negociar de otra manera con cualquier criptoactivo. Los criptoactivos son sumamente volátiles y pueden provocar pérdidas. La disponibilidad de los servicios, productos y eventos relacionados de WEEX puede variar según la región. Tienes la responsabilidad de asegurarte de que tu participación esté de acuerdo con las leyes y regulaciones locales vigentes.