La cuarta semana de septiembre dejó cinco exposiciones que no se arreglan con un parche del vendor, porque ninguna tiene CVE. Son configuraciones por defecto, credenciales que no parecen credenciales y permisos heredados que nadie revisó.
En dos de los casos (GitLab y Google) el propio proveedor dijo que el comportamiento es el esperado. Eso deja la corrección del lado tuyo.
Supabase: 16.326 bases con tablas legibles desde internet
UpGuard publicó el 25 de septiembre un estudio sobre unos 300.000 dominios que usan Supabase, el servicio de backend sobre PostgreSQL. Encontró 16.326 bases con tablas que cualquiera puede leer, y más de la mitad con indicios de datos personales.
El mecanismo es simple: la URL del proyecto y la clave pública quedan en el JavaScript de la aplicación web, y con eso se consulta la API REST. Si la tabla no tiene Row Level Security (RLS, la seguridad a nivel de fila que decide qué registros ve cada usuario) o tiene políticas mal armadas, devuelve todo.
Algunos de los casos confirmados:
- Un servicio de valet de Estados Unidos con más de 100.000 clientes (teléfonos, patentes e historial de visitas).
- Un servicio de inmigración canadiense con casi 5.000 registros y 884 contraseñas en texto plano.
- Una plataforma de contenidos de India con datos de pago y más de 100.000 mensajes privados.
- Un consulado africano con datos y domicilios de 25.000 personas.
El dato que conecta con las apps «vibe-coded» (generadas casi enteras con IA): Supabase activa RLS por defecto en las tablas creadas desde su editor visual, pero no en las creadas por API, que es justamente como trabajan los agentes de programación. El CISO de Supabase, Bil Harmer, le dijo a TechCrunch que los proyectos son «seguros por defecto» y que la seguridad es responsabilidad compartida.
Qué revisar:
- Que todas las tablas del esquema público tengan RLS activado, incluidas las que creó un script o un agente.
- Que ninguna clave
service_roleesté en el código del frontend. - Los avisos del «Security Advisor» del panel de Supabase.
Cloudflare Containers: bloques de disco con datos de otro cliente
Oren Yomtov, investigador de Accomplish, reportó el 4 de septiembre por HackerOne que un cliente del plan Workers Paid podía recuperar restos de datos de contenedores de otros clientes. Cloudflare lo explicó en su blog el 24 de septiembre.
La causa era la opción skip_block_zeroing del aprovisionamiento fino de Linux (dm-thin): los bloques de 64 KiB se reasignaban sin borrarse. Una escritura de 4 KiB dejaba intactos los otros 60 KiB del dueño anterior.
El investigador encontró residuos en 18 de 24 ubicaciones y en 20 de 22 nodos, incluidas bases SQLite completas. Cloudflare terminó la limpieza el 19 de septiembre y dice no tener evidencia de abuso.
Qué revisar: los clientes no tienen que hacer nada. La lección sirve para tu propia infraestructura: si reciclás volúmenes entre inquilinos, verificá que se borren antes de reasignarse.
GitLab: una dirección de email que empuja código a main
GitLab le da a cada usuario una dirección para crear issues por email, con la forma incoming+proyecto-glimt-XXXX-issue@incoming.gitlab.com. Aikido Security mostró el 23 de septiembre que ese glimt- es un token de la cuenta entera, no del proyecto, y no vence.
GitLab no verifica el remitente. Cambiando el sufijo -issue por -merge-request y adjuntando un parche, los investigadores lograron:
- Hacer commit en una rama protegida de un repositorio privado, a pesar de una lista de IP permitidas.
- Modificar
.gitlab-ci.ymly correr jobs como el dueño del token. - Leer variables y secretos de CI/CD y usar el
CI_JOB_TOKENpara llegar más lejos.
El doble factor tampoco frena el ataque. GitLab cerró el reporte en mayo como «comportamiento esperado» y sólo actualizó los textos de la interfaz y la documentación.
Qué revisar:
- Buscar direcciones
incoming+publicadas en READMEs, guías de contribución y páginas de soporte (Aikido encontró una docena vivas). - Resetear el «Incoming email token» en la configuración de tokens personales: cambia todas las direcciones de golpe.
- Revisar commits y pipelines recientes que nadie reconozca.
GKE Config Connector: un YAML y sos dueño de la organización
Config Connector permite administrar recursos de Google Cloud declarándolos como objetos de Kubernetes. Ejecuta cada llamada con su propia cuenta de servicio, que suele tener roles/owner o administración de la organización, sin chequear qué permisos tiene en GCP quien envió el YAML.
El resultado es un «confused deputy» (un intermediario con privilegios que actúa en nombre de quien no debería): alcanza con poder crear un recurso IAMPolicyMember en un namespace vigilado para otorgarse owner de toda la organización.
La técnica, bautizada ConfigConfusion, la reportó Justin O’Leary a Google en marzo y se hizo pública en junio. Google respondió que funciona «según lo previsto», no asignó CVE ni sacó corrección. El 23 de septiembre Varonis publicó un análisis que la volvió a poner en circulación.
Qué revisar:
- Usar el modo por namespace, con una cuenta de servicio distinta y acotada para cada uno.
- Quitarle a Config Connector los roles de organización que no necesite.
- Restringir quién puede crear
IAMPolicyMembery alertar sobre cambios de IAM a nivel organización.
GitHub Actions: rehabilitadas con Mini Shai-Hulud adentro
Las acciones actions-cool/issues-helper y actions-cool/maintain-one-comment fueron comprometidas el 18 de mayo por la campaña Mini Shai-Hulud, y GitHub las deshabilitó al día siguiente. Pero los tags de versión maliciosos nunca se borraron.
Según Socket, los repositorios volvieron a estar disponibles del 16 al 25 de septiembre, y todo workflow que las referenciaba por tag volvió a ejecutar el payload, que roba tokens y secretos de CI/CD. Sólo issues-helper tiene unos 15.000 repositorios dependientes. Socket no pudo confirmar quién pidió la rehabilitación.
Qué revisar:
- Buscar ambas acciones en tus workflows y las ejecuciones desde el 16 de septiembre.
- Rotar todos los secretos a los que esos workflows tenían acceso.
- Fijar las acciones de terceros por SHA de commit completo, nunca por tag.
Una más, fuera de esta lista: InfoQ informó el 28 de septiembre que el protocolo de Radicle (forja Git entre pares) transmitía en texto plano después del handshake, y la recomendación es frenar el uso de repos privados sobre internet abierta hasta migrar a Iroh.
Lo que ningún escáner de CVE va a encontrar
Los cinco casos comparten algo: ninguno aparece en un escaneo de vulnerabilidades. Una tabla sin RLS, un email publicado en un README o una cuenta de servicio con rol de owner se detectan revisando configuración y permisos, no versiones.
¿Tu inventario de secretos incluye direcciones de email, claves públicas y tags de acciones? Te leemos en los comentarios.
Fuentes
- UpGuard — Everything Everywhere: Systemic Data Exposure in Supabase Apps
- TechCrunch — Some Supabase customers are publicly exposing reams of people’s data to the web
- Cloudflare — How Cloudflare addressed a cross-tenant data exposure vulnerability in Containers
- Aikido Security — Send GitLab an email, push to main
- BleepingComputer (Varonis) — How One Kubernetes YAML Can Hand Over a GCP Organization
- The Register — Google told researcher «Nice catch!» then denied bug bounty
- Socket — Re-Enabled GitHub Actions Expose Thousands of Repositories to Mini Shai-Hulud
- InfoQ — Radicle network vulnerabilities
