Base de datos de Moltbook completamente abierta: 1,5 millones de claves API de agentes, 35.000 correos electrónicos

Moltbook es una red social estilo Reddit creada para que solo los agentes de IA puedan publicar. Su fundador, Matt Schlicht, la lanzó el 28 de enero de 2026 y dijo públicamente en X que no había escrito ni una sola línea de su código: «Solo tenía una visión de la arquitectura técnica, y la IA la hizo realidad», según lo cita Wiz. Tres días después, el 31 de enero de 2026, 404 Media informó de que cualquiera podía tomar el control de cualquier agente de IA del sitio. Wiz, que había encontrado la misma configuración incorrecta de forma independiente, publicó el informe técnico el 2 de febrero: una clave de API de Supabase codificada de forma fija en el JavaScript del lado del cliente de Moltbook apuntaba a una base de datos de producción sin Row Level Security, y una solicitud no autenticada a la tabla de agentes devolvía tokens de autenticación activos de los agentes de la plataforma, incluidos los más conocidos. Wiz contabilizó 1,5 millones de tokens de API, 35.000 direcciones de correo electrónico y 4.060 conversaciones privadas entre agentes que podían leerse de esa manera, y confirmó que también podía reescribir publicaciones activas. El archivo clasifica el episodio como un incidente de credenciales de gravedad crítica con una fecha precisa al día del 31 de enero de 2026, una calificación de confianza A y daños reales registrados, junto con el resto de sus registros de infraestructura de agentes en el Orca AI Incident Archive.

La clave nunca fue el secreto

Supabase es un servicio de Postgres alojado con una API REST que Wiz describe como popular entre las aplicaciones creadas con vibe coding porque es fácil de configurar. Su clave publicable está diseñada para residir en el código del lado del cliente: identifica el proyecto, y se supone que el control de acceso proviene de las políticas de seguridad a nivel de fila de las tablas que hay detrás. Gal Nagli, de Wiz, afirma el punto explícitamente en el informe: exponer la clave "no indica automáticamente una falla de seguridad", y cuando RLS está configurado correctamente "la clave pública de la API es segura de exponer: actúa como un identificador de proyecto". En la implementación de Moltbook, escribe Wiz, "faltaba esta línea crítica de defensa".

El mecanismo era un bundle. Según Wiz, el archivo JavaScript de producción en moltbook.com/_next/static/chunks/18e24eafc444b2b9.js contenía tanto la dirección del proyecto de Supabase, ehxbxtjliybbloantpwq.supabase.co, como la clave, sb_publishable_4ZaiilhgPir-2ns8Hxg5Tw_JqZU_G6-. Wiz envió entonces una solicitud a la tabla agents pidiendo tres nombres y claves de API, una consulta que debería haber devuelto un array vacío o un error de autorización. En cambio, devolvió filas, incluidos los tokens de autenticación de los agentes más populares de la plataforma. A partir de ahí, Wiz mapeó el esquema usando mensajes de error de PostgREST e introspección de GraphQL, y contó aproximadamente 4,75 millones de registros expuestos.

El resumen del archivo dice que Moltbook "nunca habilitó" Row Level Security, y las fuentes son más laxas que eso. Ninguna de las dos muestra un historial de configuración, así que lo que está documentado es que RLS no estaba en vigor durante la revisión: Wiz encontró las tablas abiertas, e Implicator.ai, al informar sobre el relato de quien hizo el hallazgo, escribe que Moltbook "nunca activó RLS. O, si lo hizo, no se configuró ninguna política". Que la configuración nunca se habilitara o se habilitara sin políticas establecidas no lo establece ninguno de los dos relatos, y el resultado práctico es el mismo.

¿Qué había realmente en las tablas?

Wiz nombra las tablas y su contenido. La tabla agents contenía, por fila, la api_key que autenticaba al agente, un claim_token usado para reclamar su propiedad, un verification_code emitido en el registro, y los recuentos de karma y seguidores del agente. Eso es un kit completo de toma de control de cuentas más que una filtración de datos: con una de esas claves, una petición puede publicar, enviar mensajes y actuar en general como ese agente, y Wiz señala que esto incluía cuentas con alto karma y agentes de personajes conocidos.

La tabla owners contenía información personal de más de 17.000 usuarios, incluidas direcciones de correo electrónico, además del identificador de X y el nombre visible de cada agente. Una tabla que Wiz encontró después a través del endpoint GraphQL, observers, contenía otras 29.631 direcciones de correo electrónico pertenecientes a registros de acceso anticipado al producto planificado de Moltbook, "Build Apps for AI Agents". La tabla agent_messages contenía 4.060 conversaciones privadas de mensajes directos entre agentes, almacenadas sin cifrado ni controles de acceso, y Wiz informa de que algunas contenían credenciales de terceros en texto plano, incluidas claves de API de OpenAI que los agentes habían compartido entre sí.

La proporción entre agentes y personas es lo que socavaba el relato público de la plataforma. Wiz informa de 1,5 millones de agentes registrados frente a unos 17.000 propietarios humanos, aproximadamente 88 agentes por persona, y atribuye la diferencia a la ausencia de limitación de velocidad o verificación de identidad: cualquiera podía registrar agentes en bucle, y un humano podía publicar como "agente" con una solicitud POST básica. La conclusión de Wiz es contundente: "la revolucionaria red social de IA estaba compuesta en gran medida por humanos operando flotas de bots".

El recuento de correos electrónicos no cuadra de forma limpia y Wiz no explica por qué. Su cifra principal es de 35.000 direcciones de correo electrónico; sus propios recuentos a nivel de tabla son más de 17.000 correos electrónicos de propietarios y 29.631 correos electrónicos de observadores, que suman aproximadamente 46.600. Ambas cifras son de Wiz, y este artículo no estableció cómo se obtuvo la cifra de 35.000, ya sea mediante la deduplicación entre las dos tablas o a partir de una instantánea tomada antes de que se encontrara la tabla de observadores.

La mitad de escritura de la exposición

Leer los datos no fue el hallazgo completo. Wiz informa que, incluso después de que la primera ronda de correcciones bloqueara el acceso de lectura a las tablas sensibles, el acceso de escritura a las tablas públicas siguió abierto. Lo probó enviando una solicitud PATCH a una publicación activa y reemplazando su título y cuerpo con la cadena "@galnagli - responsible disclosure test", y luego confirmó que la edición era visible en el sitio. Después de que se aplicara la restricción de escritura, Wiz ya no pudo revertir su propia publicación de prueba; el equipo de Moltbook eliminó el contenido unas horas más tarde, escribe Wiz, y agradeció a los investigadores por el informe.

La preocupación declarada de Wiz no es la desfiguración por sí misma. Una vía de escritura no autenticada hacia las publicaciones significa que cualquiera podría inyectar cargas de inyección de prompts en contenido que otros agentes leen, y Wiz plantea la integridad de las publicaciones, los votos y el karma de la plataforma durante la ventana de exposición como una cuestión abierta en lugar de una medida. Ninguna fuente consultada para este artículo cuantifica cuánto contenido se alteró ni por quién.

Tres horas y doce minutos, cuatro arreglos separados

La cronología de divulgación de Wiz comienza a las 21:48 UTC del 31 de enero de 2026, con un contacto inicial con el mantenedor de Moltbook mediante mensaje directo de X, y termina a las 01:00 UTC del 1 de febrero, cuando se aseguró la última de las tablas expuestas. Después de ese primer contacto, registra siete pasos más: el informe a las 22:06, una primera corrección a las 23:29 que abarca las tablas agents, owners y site_admins, una segunda a las 00:13 que abarca agent_messages, notifications, votes y follows, el descubrimiento de la ruta de escritura a las 00:31, la tercera corrección que la cierra a las 00:44, el descubrimiento de las tablas observers, identity_verifications y developer_apps a las 00:50, y la corrección final a las 01:00.

Ese cronograma es el argumento más contundente contra la versión más simple de esta historia. Implicator.ai describe la solución en dos sentencias SQL: escribe que "la solución requería dos sentencias SQL. No existían", y el resumen del archivo mantiene el mismo enfoque de "dos líneas de SQL". La reparación central de la exposición de lectura probablemente fue así de pequeña: habilitar RLS y añadir políticas en las tablas. Pero el propio registro de Wiz muestra cuatro correcciones a lo largo de tres horas, una segunda brecha de acceso de escritura, separada, que la corrección de lectura no cerró, y tres tablas más —incluidas las 29,631 direcciones de observadores— que solo aparecieron después de las dos primeras rondas. La lección final de Wiz es que "trabajó con el equipo a través de múltiples rondas de remediación, y cada iteración sacó a la luz superficies expuestas adicionales". La versión de dos líneas describe el cambio de configuración, no la remediación.

Dos descubrimientos, y una diferencia en el registro

El hallazgo suele atribuirse a Jamieson O'Reilly, fundador de la empresa australiana de seguridad Dvuln, quien demostró la toma de control a 404 Media; Implicator.ai informa de que 404 Media verificó la capacidad actualizando la propia cuenta de Moltbook de O'Reilly con su permiso. La publicación de Wiz es de Gal Nagli e incluye una nota al final que atribuye el mérito a O'Reilly: «El investigador de seguridad Jameson O'Reilly también descubrió la mala configuración subyacente de Supabase, que ha sido reportada por 404 Media». La nota continúa diciendo que la publicación de Wiz comparte un descubrimiento independiente del mismo problema.

El resumen del archivo describe a ambos como investigadores de Wiz. La propia publicación de Wiz no lo hace: nombra a Nagli como su autor y describe a O'Reilly como un investigador independiente cuyo hallazgo fue reportado por 404 Media, e Implicator.ai ubica a O'Reilly en Dvuln. La ortografía tampoco está resuelta entre las fuentes —Wiz escribe "Jameson", mientras que el propio sitio de Dvuln enumera a su fundador como "Jamieson"—, y este artículo ha utilizado la ortografía que usa ese sitio. Lo que no está en disputa es que hubo dos descubrimientos independientes de la misma configuración incorrecta en cuestión de días.

El relato de la respuesta varía según la fuente, y la diferencia merece reportarse en lugar de resolverse. Según el relato de O'Reilly, transmitido por Implicator.ai, se acercó directamente a Schlicht y le ofreció ayuda para parchear la falla; la respuesta fue: «Voy a darle todo a la IA. Así que envíame lo que tengas». Según ese relato, transcurrió un día entero sin seguimiento, y Schlicht no respondió a la solicitud de comentarios de 404 Media. Wiz, que contactó al mantenedor por separado, registra su informe presentado a las 22:06 UTC y la última de cuatro correcciones a la 01:00 UTC, tres horas y doce minutos después del primer contacto. Las dos cronologías transcurren por canales distintos y ninguna fuente dice si una provocó la otra; ambas pueden ser exactas.

Lo que el expediente establece, y lo que no

Los hechos establecidos son la configuración, las clases de datos, los dos descubrimientos independientes, la secuencia de corrección y la proporción entre humanos y agentes de la plataforma. Todo en esa lista proviene del informe técnico de primera mano de Wiz o de reportes basados en el relato de quien hizo el hallazgo, y ambos coinciden en el mecanismo.

Lo que no está establecido comienza con el acceso previo. Wiz afirma que todos los datos a los que se accedió durante su investigación y verificación de la corrección se han eliminado, y eso no dice nada sobre nadie más. Implicator.ai expone la laguna con claridad: nadie puede saber si alguien encontró la base de datos antes que O'Reilly, ni cuántas de las publicaciones que circularon durante la semana viral de la plataforma fueron salida genuina del agente y cuántas provinieron de una clave robada. Ninguna fuente consultada para este artículo informa de un uso indebido confirmado de ninguna credencial expuesta, y ninguna informa de un recuento de cuentas realmente comprometidas. La marca real_harm del archivo es verdadera porque los datos personales y las credenciales activas de terceros eran genuinamente legibles por cualquiera, no porque se haya registrado un uso indebido específico.

Los recuentos de agentes también discrepan, y la discrepancia sigue el crecimiento de la plataforma en lugar de los hechos de la exposición. Implicator.ai, escribiendo el 1 de febrero desde la cuenta del descubridor, describe "más de 32.000" agentes registrados —en un artículo que también dice que el sitio superó los 37.000 en su primera semana— y 1,49 millones de registros expuestos. Wiz, al revisar el 2 de febrero, contó 1,5 millones de agentes y aproximadamente 4,75 millones de registros. El resumen del archivo registra que la plataforma finalmente acumuló 1,7 millones de agentes registrados y casi 7 millones de comentarios; este artículo no corroboró de forma independiente ninguno de los dos totales finales. El único número que todos los relatos respaldan es la forma del asunto: muchos más agentes que humanos, y ningún mecanismo que pudiera distinguir la diferencia.

Qué cambió y qué no solucionó el ajuste

Lo que cambió es limitado y está documentado: las políticas RLS en las tablas sensibles, una restricción de escritura en las públicas, la eliminación de la publicación de prueba de los investigadores y, según Wiz, una plataforma que estaba totalmente parcheada a las 01:00 UTC del 1 de febrero. Nada en las fuentes consultadas para este artículo describe que Moltbook haya añadido limitación de velocidad, verificación de identidad de los agentes o una auditoría del contenido escrito durante ese periodo. Las recomendaciones de Wiz están dirigidas a las herramientas más que a la plataforma: los asistentes de IA que generan backends de Supabase podrían habilitar RLS por defecto, y las plataformas de despliegue podrían escanear en busca de credenciales expuestas y configuraciones inseguras.

La parte que perdura más allá del SQL es la premisa que la base de datos dejó a la vista. Una red cuyo principal atractivo era que solo los agentes de IA podían publicar no tenía forma de verificar que un agente fuera un agente, y su capa de credenciales era lo único que separaba a un humano con un script de todas las identidades del sitio. Por eso el registro se archiva como un hito y no como una mala configuración rutinaria: la exposición era ordinaria, y lo que exponía —una capa de identidad autenticada para agentes autónomos— no lo era.