01 · Contexto
Qué está ocurriendo
Hechos verificados. El 9 de octubre de 2026, el proyecto oficial AWS Amplify publicó el aviso GHSA-69c4-mvf5-5xm3, asociado a CVE-2026-108096. Describe autorización incorrecta en resolutores de consultas generados para determinados modelos respaldados por SQL. Un usuario autenticado podía formular consultas que permitieran leer registros pertenecientes a otros usuarios de la misma aplicación.
La condición informada combina una API GraphQL con origen de datos SQL, reglas de autorización por propietario o grupo e índices secundarios. El aviso identifica como afectados graphql-index-transformer desde 2.2.0 y antes de 3.1.2, graphql-api-construct desde 1.4.0 y antes de 1.21.4, y data-construct anterior a 1.17.4. Las correcciones corresponden a 3.1.2, 1.21.4 y 1.17.4, respectivamente. El mantenedor indica que no existe una solución alternativa disponible. La publicación no demuestra por sí sola explotación en una instalación particular.
02 · Impacto
Por qué importa
Análisis editorial. Este caso muestra por qué la autenticación no resuelve toda la seguridad de una API. Una sesión válida puede acceder a una función legítima y, aun así, recibir información que pertenece a otra persona. Además, comprobar la consulta principal no garantiza que una ruta alternativa por índice conserve exactamente los mismos límites. Para los equipos que generan infraestructura o resolutores desde librerías, la revisión debe conectar la versión de la dependencia con el código realmente desplegado. Un repositorio actualizado y un entorno operativo antiguo son estados distintos; registrar solo el cambio del archivo de paquetes puede dejar una falsa sensación de cierre.
03 · Recomendaciones
Qué conviene hacer
- Recomendaciones editoriales. Inventariar aplicaciones que usen esos paquetes y confirmar si cumplen la combinación técnica descrita antes de declarar exposición. Revisar el archivo de dependencias resueltas, la configuración del modelo y el mecanismo de despliegue. Preparar la actualización compatible, probarla y verificar que los resolutores corregidos lleguen al entorno correspondiente. Conservar la versión anterior y un procedimiento de reversión que no vuelva a habilitar silenciosamente una condición conocida.
- Construir pruebas con dos identidades y datos ficticios separados. La identidad A debe poder consultar sus propios registros y no obtener los de B, tanto por la ruta habitual como por cada índice secundario autorizado. Repetir el control para reglas de grupo cuando sean aplicables, incluyendo respuestas vacías, errores y paginación. Revisar registros disponibles para buscar accesos anómalos, sin equiparar un resultado negativo con ausencia de exposición histórica. Si aparece evidencia de acceso indebido, activar el procedimiento de incidentes y preservar los registros antes de realizar cambios que puedan destruirlos.
