Filtración de Moltbook expuso 1,5 millones de claves de API
La filtración de Moltbook, informada por Wiz el 2 de febrero de 2026, expuso 1,5 millones de tokens de autenticación de API, 35.000 direcciones de correo y mensajes privados de la red social para agentes de IA. Una base de datos Supabase sin políticas de acceso daba a cualquiera acceso total de lectura y escritura, y Moltbook lo corrigió en horas. Para las empresas que crean apps con herramientas de programación con IA, muestra cómo un solo valor predeterminado omitido puede abrir todas las cuentas de una plataforma.
Qué encontró Wiz en la base de datos de Moltbook
La firma de ciberseguridad Wiz encontró una base de datos Supabase mal configurada detrás de Moltbook, una red social creada para agentes de IA, que daba a cualquiera acceso total de lectura y escritura a todos los datos de la plataforma. Wiz lo reportó el 2 de febrero de 2026.
La exposición incluyó 1,5 millones de tokens de autenticación de API, 35.000 direcciones de correo y mensajes privados entre agentes. Wiz dice que divulgó el problema de inmediato, que Moltbook lo aseguró en horas con su ayuda y que se borraron todos los datos a los que se accedió durante la investigación. SiliconANGLE informó que no había evidencia de que los datos se explotaran antes de la corrección.
Por qué una app hecha con vibe coding terminó con una base de datos abierta
Moltbook es un sitio al estilo Reddit donde los agentes de IA publican, comentan, votan y ganan karma. Su fundador dijo públicamente en X que no escribió una sola línea de código y que la IA lo construyó a partir de su visión de la arquitectura, una práctica conocida como vibe coding.
La plataforma usaba Supabase, un servicio de PostgreSQL alojado y de código abierto popular en las apps de vibe coding por lo fácil que es configurarlo. Supabase está diseñado para exponer una clave de API pública en el navegador. Esa clave es segura solo cuando las políticas de seguridad a nivel de fila (Row Level Security, RLS) limitan a qué puede acceder. Moltbook no tenía esas políticas.
Cómo funcionó la exposición
Wiz hizo una revisión no intrusiva navegando por el sitio como un usuario normal. En minutos encontró la clave de API de Supabase en el JavaScript del lado del cliente. Una consulta directa que no debía devolver nada devolvió las claves de API de los agentes como si Wiz fuera administrador.
Con mensajes de error e introspección de GraphQL, Wiz mapeó el esquema completo y encontró unos 4,75 millones de registros expuestos. Cada registro de agente contenía una clave de API completa, un token de reclamación y un código de verificación, suficiente para tomar el control de cualquier cuenta con una sola llamada a la API.
Qué expuso la filtración de Moltbook
Los datos abarcaban más que credenciales. La tabla de propietarios tenía información personal de más de 17.000 usuarios, y otra tabla guardaba 29.631 direcciones de correo más de registros tempranos para un futuro producto para desarrolladores.
La tabla agent_messages almacenaba 4.060 conversaciones privadas entre agentes sin cifrado ni controles de acceso. Algunas contenían credenciales de terceros, incluidas claves de API de OpenAI en texto plano. El acceso de escritura también siguió abierto en tablas públicas tras la primera corrección, y Wiz pudo editar publicaciones en vivo, lo que significa que cualquiera pudo haber plantado contenido o cargas de inyección de prompts leídas por los agentes.
Qué mostraron los datos sobre la propia plataforma
La base de datos también contradijo la imagen pública de la plataforma. Moltbook decía tener 1,5 millones de agentes registrados, pero la base de datos mostraba solo 17.000 propietarios humanos detrás de ellos, una proporción de 88:1.
Cualquiera podía registrar agentes en masa con un ciclo simple, porque no había límite de solicitudes, y una persona podía publicar como «agente» con una solicitud web básica. Wiz concluyó que la red era en gran parte humanos operando flotas de bots.
Qué cambia para las empresas que construyen con herramientas de programación con IA
Para una empresa, la lección es que el código generado por IA puede entregar un producto que funciona con un valor predeterminado inseguro. La falla fue una configuración errónea básica, no un ataque sofisticado, y alcanzó a todas las cuentas de la plataforma.
El riesgo también se extiende: los agentes guardaban en sus mensajes claves de servicios externos, así que una base de datos expuesta podía comprometer sistemas conectados. Las empresas que dejan que sus equipos creen apps con asistentes de IA necesitan revisar antes del lanzamiento las reglas de acceso a la base de datos, los secretos en el código del front-end y los permisos de escritura.
«La oportunidad no es frenar el vibe coding sino elevarlo». — Gal Nagli, jefe de exposición a amenazas en Wiz
Nagli dijo que los asistentes de IA que generan backends de Supabase pueden activar RLS de forma predeterminada, y que las plataformas de despliegue pueden escanear en busca de credenciales expuestas.
Preguntas y respuestas
¿Cuántas claves de API expuso Moltbook?
Wiz encontró 1,5 millones de tokens de autenticación de API, junto con 35.000 direcciones de correo y mensajes privados entre agentes.
¿Qué causó la exposición de la base de datos de Moltbook?
Una clave de API pública de Supabase en el JavaScript del sitio apuntaba a una base de datos sin políticas de Row Level Security, así que la clave daba acceso total de lectura y escritura.
¿Se hizo mal uso de los datos expuestos?
Moltbook aseguró la base de datos en horas tras el reporte de Wiz. SiliconANGLE informó que no había evidencia de que los datos se explotaran antes de eso.
La visión de MOZGII
Cómo lo construiríamos
Este caso trata de un valor predeterminado ausente, no de un ataque ingenioso. Una app creada rápido con ayuda de IA salió a producción con una base de datos que cualquiera podía leer y escribir, y los agentes guardaban en sus mensajes las claves de otros servicios.
Si construyéramos una plataforma de agentes, empezaríamos con las reglas de datos antes que con cualquier función. Cada tabla tendría políticas de acceso desde el primer día, con una prueba que intenta leerla y escribirla como usuario anónimo y que hace fallar el lanzamiento si lo logra. Los secretos nunca estarían en el código del front-end ni en el texto de los mensajes: un escáner bloquearía un despliegue que incluya una clave, y la plataforma detectaría y ocultaría las claves pegadas en las conversaciones.
Los agentes recibirían tokens acotados que caducan y que se pueden revocar uno por uno, de modo que una fuga signifique rotar algunas claves y no todas. El acceso de escritura a lo que leen los agentes se registraría y se limitaría, porque el contenido editado se convierte en instrucciones para cada agente que lo lee.
Un asistente de programación puede escribir todo esto, pero una persona revisaría las reglas de acceso y las verificaciones de lanzamiento, porque son las partes que una construcción rápida omite. Se rompería donde la velocidad gana a la revisión. La métrica que vigilaríamos es el número de tablas accesibles sin autenticación, que debe ser cero. Después construiríamos límites de solicitudes y una verificación simple de que una cuenta es lo que dice ser.
Fuentes
De dónde salen los datos de esta nota.
- 01Hacking Moltbook: AI Social Network Reveals 1.5M API Keys | Wiz Blogwiz.io
- 02AI agent social network Moltbook left millions of credentials publicly exposed - SiliconANGLEsiliconangle.com
- 03AI agent social media network Moltbook is a security disaster - millions of credentials and other details left unsecured | TechRadarTech RadarTech Radar ProTech Radar GamingTech Radar Protechradar.com