CVE-2026-78699 revela un fallo de severidad alta en AshPostgres capaz de romper el aislamiento entre clientes de una aplicación SaaS. Bajo una configuración específica, un usuario que puede cambiar el nombre de su inquilino puede provocar que la aplicación apunte su registro hacia el esquema PostgreSQL de otro cliente y acceda a datos que no le corresponden.
La vulnerabilidad fue publicada el 30 de agosto de 2026 y afecta a ash_postgres desde la versión 0.25.0 hasta las anteriores a 2.13.0. El problema no está en PostgreSQL: la base de datos rechaza correctamente el cambio cuando el esquema de destino ya existe. La debilidad aparece porque la función rename_tenant/3 ignora ese error, responde como si la operación hubiera sido exitosa y permite que la transacción de la aplicación confirme un estado incoherente.
No todas las aplicaciones con AshPostgres son explotables. Se requiere multitenencia basada en esquemas, una versión afectada y una función accesible que permita al usuario escoger un nuevo identificador de inquilino —por ejemplo, un slug de organización o subdominio—. Tampoco existe evidencia pública de explotación activa. Aun así, el posible impacto sobre confidencialidad e integridad exige actualizar, buscar renombramientos fallidos y comprobar que ningún registro quedó asociado con el esquema de otro cliente.
Qué ocurre exactamente en CVE-2026-78699
AshPostgres permite implementar multitenencia mediante esquemas separados de PostgreSQL. Cada organización puede tener un identificador que determina el esquema donde se realizan sus lecturas y escrituras. Cuando ese identificador cambia, la función vulnerable intenta renombrar el esquema con una sentencia ALTER SCHEMA ... RENAME TO ....
La base de datos devuelve un resultado de éxito o error. Si el nuevo nombre ya pertenece a otro esquema, PostgreSQL rechaza la operación. También puede rechazarla por privilegios insuficientes o un tiempo de espera de bloqueo. La versión afectada utiliza una consulta que no genera una excepción, descarta el resultado y devuelve :ok incondicionalmente. Por eso la capa superior cree que el cambio funcionó.
El registro lógico del inquilino puede entonces guardar el nuevo nombre aunque el esquema original nunca se renombró. Si ese nombre coincide con el esquema real de otro cliente, las operaciones posteriores se resuelven contra datos ajenos. El aviso del proyecto describe impacto alto sobre confidencialidad e integridad, sin impacto directo sobre disponibilidad, y asigna una puntuación CVSS 4.0 de 7,2.
Cuatro condiciones que determinan la exposición real
| Condición | Expuesto cuando | Evidencia que debe revisarse |
|---|---|---|
| Versión | ash_postgres está entre 0.25.0 y una versión anterior a 2.13.0. | Lockfile, manifiesto de despliegue, SBOM y artefacto realmente ejecutado. |
| Modelo | La aplicación usa multitenencia por esquemas PostgreSQL. | Configuración, repositorio, catálogo de esquemas y documentación de arquitectura. |
| Función | Un usuario puede impulsar un renombramiento del inquilino. | Rutas, acciones, API, permisos, interfaz administrativa y registro de cambios. |
| Nombre | El usuario puede elegir un identificador que colisiona con otro esquema. | Validación de unicidad, restricciones, logs de errores y nombres históricos. |
Si alguna condición no se cumple, la ruta descrita por el aviso no está completa. Eso no exime de actualizar una dependencia afectada, pero permite priorizar. Una aplicación que usa AshPostgres sin multitenencia por esquemas no tiene el mismo riesgo que un SaaS donde cada cliente modifica libremente su subdominio.
La versión declarada en el repositorio tampoco basta. La organización debe comprobar el artefacto desplegado en cada entorno, trabajadores en segundo plano, réplicas, imágenes de contenedor y ramas de larga duración. Una actualización aplicada al servicio web puede dejar otra instancia procesando operaciones con la versión anterior.
Por qué un error ignorado cruza la frontera de clientes
La multitenencia promete que múltiples clientes comparten una plataforma sin compartir acceso a los datos. Esa frontera puede imponerse en diferentes capas: aplicación, base de datos, esquema, fila, cuenta de nube o instancia. Cuando el enrutamiento depende de un identificador mutable, una inconsistencia entre el registro lógico y el objeto físico puede desviar operaciones aunque la base de datos funcione correctamente.
Este caso demuestra que el manejo de errores forma parte del control de acceso. La sentencia SQL fue rechazada, pero la aplicación transformó el fracaso en éxito. El control no falló por una contraseña débil ni por una consulta sin filtro, sino por la falta de una propiedad transaccional: si no cambia el esquema, tampoco debe cambiar el registro que lo referencia.
En una aplicación SaaS, el impacto puede superar una lectura accidental. Una vez enrutado hacia el esquema de otra organización, el usuario podría leer o modificar datos dentro de los permisos de la aplicación. La disponibilidad no es el efecto descrito, pero la integridad de registros y la obligación de investigar posibles accesos cruzados pueden exigir suspensión temporal de funciones y notificación según el contexto.
Cómo determinar si ya ocurrió un cruce
La búsqueda debe comenzar por eventos de renombramiento durante el periodo en que una versión vulnerable estuvo desplegada. Se comparan los cambios de identificador registrados por la aplicación con los resultados reales de ALTER SCHEMA en PostgreSQL. Interesan especialmente errores por esquema duplicado, privilegios o bloqueos que coincidan con una actualización confirmada por la capa de negocio.
Después se construye una correspondencia entre cada registro de inquilino y cada esquema existente. No debería haber dos registros que apunten al mismo esquema, identificadores lógicos que carezcan de objeto físico ni esquemas huérfanos sin propietario. La revisión debe considerar nombres normalizados, mayúsculas, codificación y transformaciones que la aplicación aplique antes de formar el nombre.
Si aparece una inconsistencia, hay que preservar registros antes de corregirla. El equipo debe analizar sesiones, consultas, objetos leídos o modificados y exportaciones realizadas desde la identidad afectada. La ausencia de una alerta no descarta el evento si la telemetría no registra contexto de inquilino, usuario y esquema en cada operación sensible.
Un análisis forense digital puede ayudar a reconstruir la ventana y determinar si existió acceso o modificación. La conclusión debe diferenciar vulnerabilidad, estado incoherente y explotación: son tres niveles de evidencia distintos.
Respuesta priorizada para equipos de desarrollo y seguridad
- Confirmar la dependencia efectiva. Identificar todas las cargas que ejecutan
ash_postgresy registrar versión, entorno, propietario y función. - Actualizar a 2.13.0 o posterior. Desplegar el arreglo en servicios web, trabajadores, tareas programadas e imágenes reutilizadas. Validar el artefacto en ejecución.
- Restringir temporalmente el renombramiento. Si la actualización no puede completarse de inmediato, deshabilitar o limitar la función y evitar identificadores elegidos libremente.
- Buscar errores ignorados. Correlacionar renombramientos con fallos de PostgreSQL y transacciones que la aplicación marcó como exitosas.
- Validar correspondencias. Comparar registros de inquilino y esquemas para detectar colisiones, duplicados y objetos huérfanos.
- Investigar el acceso. Ante una inconsistencia, preservar evidencia, revisar lecturas y escrituras y evaluar obligaciones contractuales y regulatorias.
- Probar el arreglo. Crear una prueba automatizada donde el nombre de destino ya exista y comprobar que toda la transacción se revierte.
Un análisis de vulnerabilidades ayuda a localizar versiones y configuraciones expuestas. Para validar si controles de autorización, APIs y transacciones resisten rutas no previstas, un ejercicio de Ethical Hacking debe diseñarse sobre las reglas reales de multitenencia y con datos de prueba autorizados.
Qué debe cambiar en el ciclo de desarrollo seguro
La primera lección es tratar los errores como parte del modelo de autorización. Toda operación que modifica simultáneamente el identificador lógico y el recurso físico necesita atomicidad: ambos cambios se confirman o ambos se revierten. Las pruebas deben cubrir colisiones, permisos insuficientes, bloqueos, caídas de conexión y reintentos, no solo el camino exitoso.
La segunda es reducir la autoridad de los identificadores elegidos por el usuario. Un nombre visible para clientes no tiene que ser la clave física del esquema. La plataforma puede mantener un identificador interno inmutable y usar el slug únicamente como alias, con unicidad validada y un flujo administrativo auditado. Esto reduce la posibilidad de que una preferencia de presentación modifique una frontera de datos.
La tercera es hacer observable el contexto. Cada evento sensible debería registrar inquilino lógico, esquema físico, usuario, acción, resultado y correlación de transacción, evitando almacenar contenido confidencial innecesario. Esa telemetría permite detectar dos clientes asociados con un mismo destino y acelera una investigación.
La cuarta es incorporar inventario de componentes. SBOM, lockfiles y escaneo de dependencias deben conectarse con el despliegue real y el propietario del servicio. Detectar una CVE sin saber qué aplicación usa la función vulnerable produce ruido; conocer función, configuración y exposición convierte el aviso en una decisión.
Lectura para empresas SaaS de Colombia
Las fuentes no identifican organizaciones afectadas en Colombia ni explotación activa. La relevancia es editorial y arquitectónica: empresas locales desarrollan plataformas multiempresa para comercio, salud, educación, finanzas, nómina y servicios profesionales. Cuando varios clientes comparten aplicación y base de datos, un fallo de aislamiento puede transformar una incidencia técnica en acceso cruzado a información contractual o personal.
Dirección debería exigir cuatro respuestas: si se usa la dependencia, si la configuración vulnerable existe, si hubo renombramientos durante la ventana y qué evidencia demuestra la correspondencia correcta entre clientes y esquemas. No es suficiente recibir un reporte de “parche aplicado” sin investigación del estado anterior.
Un CISO as a Service puede coordinar desarrollo, infraestructura, privacidad, atención a clientes y dirección, definir criterios de notificación y asegurar que la remediación técnica se traduzca en evidencia de cierre. La prioridad aumenta cuando la plataforma procesa datos sensibles o presta un servicio crítico a múltiples empresas.
Plan estructural para los siguientes 30 días
Primero, documentar el modelo de aislamiento y sus invariantes: un registro por esquema, nombres únicos, transacciones atómicas y prohibición de apuntar a recursos ajenos. Cada invariante debe tener una prueba automatizada y una consulta de auditoría capaz de comprobarla en producción sin exponer datos.
Segundo, revisar todas las funciones que cambian identidad del inquilino: alta, renombramiento, fusión, suspensión, eliminación, restauración y migración. Los flujos administrativos suelen recibir menos pruebas adversariales que el inicio de sesión, aunque controlan fronteras de datos.
Tercero, ejecutar un ejercicio controlado con dos inquilinos ficticios. El equipo intenta provocar colisiones, reintentos, bloqueos y errores parciales; seguridad observa si aparecen alertas y desarrollo confirma la reversión. El ejercicio debe terminar con cambios concretos de código, telemetría y procedimiento.
Límites de la evidencia disponible
CVE-2026-78699 describe una condición reproducida y corregida, pero no una campaña activa. Requiere una configuración y una función específicas. La puntuación 7,2 expresa severidad técnica bajo ese escenario; no sustituye el análisis de exposición de cada aplicación.
La mera presencia de PostgreSQL, Elixir, Ash o AshPostgres no demuestra vulnerabilidad. Tampoco un error de renombramiento confirma acceso a datos ajenos. Solo la correlación entre versión, configuración, evento, estado inconsistente y actividad posterior permite determinar el alcance.
Demuestre que cada cliente sigue dentro de su propia frontera
Insylux puede ayudar a localizar la dependencia, validar el modelo de aislamiento, revisar evidencia histórica y probar de forma autorizada las rutas de multitenencia.
Solicite una revisión de seguridad para su plataforma SaaS con el Equipo Insylux.
Fuentes y alcance
- Ash Project, aviso oficial GHSA-6fqq-j9c4-5766, 30 de agosto de 2026.
- Erlang Ecosystem Foundation CNA, CVE-2026-78699, 30 de agosto de 2026.
- OSV, versiones y configuración afectadas, 30 de agosto de 2026.
Fuentes consultadas el 31 de agosto de 2026. Versiones, puntuación, condiciones y arreglo proceden de los avisos citados. La lectura para Colombia y las recomendaciones de desarrollo seguro son análisis defensivo del Equipo Insylux.
