Hackeo de MoltBook: un error de configuración de Supabase expuso 1.5 millones de claves API

 (wiz.io)
10 puntos por GN⁺ 2026-02-04 | 8 comentarios | Compartir por WhatsApp
  • La base de datos de Moltbook, una plataforma social centrada en agentes de IA, estaba mal configurada y dejó expuestos 1.5 millones de tokens de autenticación API, junto con 35 mil correos electrónicos y mensajes privados
  • En el JavaScript del cliente había una clave API de Supabase hardcodeada y, como no había configuración de Row Level Security (RLS), cualquiera podía leer y escribir en toda la base de datos
  • Los datos incluían información de 17,000 usuarios reales y de los 1.5 millones de cuentas de agentes que operaban, lo que confirma una proporción de humanos frente a agentes de 1:88
  • Entre la información expuesta había claves API de OpenAI y otras credenciales de terceros, conversaciones privadas e incluso permisos para editar publicaciones, lo que generaba un riesgo para la integridad del contenido de la plataforma
  • El incidente deja al descubierto los límites de seguridad del “vibe coding” basado en IA y muestra la necesidad de automatizar configuraciones seguras por defecto y reforzar los procesos de verificación en entornos de desarrollo con IA

Resumen de Moltbook y de la exposición de seguridad

  • Moltbook es una red social centrada en IA donde los agentes de IA publican, comentan, votan e interactúan mediante puntajes de reputación, y se presenta como “la primera página del internet de agentes”
    • El cofundador de OpenAI, Andrej Karpathy, llamó al proyecto “el salto de ciencia ficción más sorprendente”, lo que atrajo atención hacia la plataforma
  • El fundador de la plataforma afirmó que “la IA escribió directamente el código”, y que fue desarrollada con un enfoque de “vibe coding”
  • El equipo de investigación de Wiz descubrió una configuración incorrecta en la base de datos de Supabase que permitía acceso de lectura y escritura a todos los datos; el problema fue corregido en cuestión de horas tras ser notificado

Credenciales de Supabase expuestas

  • La información de conexión a Supabase fue encontrada hardcodeada dentro del bundle de JavaScript del cliente del sitio web de Moltbook
    • Proyecto: ehxbxtjliybbloantpwq.supabase.co
    • Clave API: sb_publishable_4ZaiilhgPir-2ns8Hxg5Tw_JqZU_G6-
  • Supabase permite exponer claves públicas, pero si no existen políticas RLS, se puede acceder a toda la base de datos
  • En Moltbook, RLS estaba desactivado, por lo que todos los permisos de lectura y escritura sobre todas las tablas quedaban públicos

Acceso no autenticado a la base de datos

  • El equipo de investigación llamó directamente a la API REST usando la clave API y recibió una respuesta de nivel administrador
  • La respuesta incluía claves API y tokens de autenticación de agentes destacados, lo que hacía posible tomar control total de las cuentas
  • A partir de mensajes de error de PostgREST y de la introspección de GraphQL, identificaron el esquema completo y confirmaron la exposición de aproximadamente 4.75 millones de registros

Datos sensibles expuestos

  • Credenciales de agentes: cada cuenta incluía api_key, claim_token y verification_code
    • Con esto, un atacante podía iniciar sesión como cualquier agente, publicar contenido y enviar mensajes
  • Correos e identidad de usuarios: se expusieron correos electrónicos de más de 17,000 usuarios y sus handles de X (Twitter)
    • Además, en la tabla observers se encontraron 29,631 correos electrónicos
  • Mensajes privados y credenciales de terceros: había 4,060 mensajes directos almacenados sin cifrado, y algunos incluían claves API de OpenAI en texto plano
  • Exposición de permisos de escritura: era posible editar publicaciones sin autenticación, con riesgo de insertar contenido malicioso o alterar el sitio
    • En una prueba real, la modificación de una publicación tuvo éxito; después quedó bloqueada al aplicar políticas RLS

Cinco lecciones de seguridad para desarrollar apps de IA

  • 1. La velocidad de desarrollo puede generar riesgos sistémicos si faltan configuraciones seguras por defecto
    • Una sola línea de configuración de Supabase fue la causa de toda la exposición
  • 2. Es necesario verificar las métricas de participación
    • De 1,500,000 agentes, solo 17,000 eran humanos reales, lo que sugiere una posible actividad inflada con una proporción de 88:1
  • 3. El colapso de la privacidad tiene efectos en cadena
    • La exposición de mensajes directos también filtró credenciales de servicios externos como claves API de OpenAI
  • 4. Los permisos de escritura representan una amenaza de integridad más grave que una simple fuga de datos
    • Pueden habilitar manipulación de contenido, prompt injection y control de narrativas
  • 5. La madurez en seguridad es un proceso de mejora continua
    • Los equipos de Wiz y Moltbook protegieron todas las tablas tras varias rondas de corrección y verificación

Vibe coding y los desafíos de seguridad

  • La IA ha reducido la barrera de entrada al desarrollo, pero la barrera de seguridad sigue siendo alta
  • Las herramientas de desarrollo con IA deben aplicar automáticamente configuraciones seguras por defecto como activar RLS o escanear credenciales
  • Cuando la seguridad se convierta en un elemento integrado por defecto del desarrollo con IA, será posible construir un ecosistema de software de IA seguro e innovador

Línea de tiempo

  • 31 de enero de 2026 21:48 UTC: primer contacto con el responsable de Moltbook
  • 22:06: reporte de configuración incorrecta de Supabase RLS
  • 23:29: primera corrección (protección de las tablas agents, owners y site_admins)
  • 1 de febrero 00:13: segunda corrección (protección de agent_messages y otras)
  • 00:31: descubrimiento de la vulnerabilidad para editar publicaciones
  • 00:44: tercera corrección para bloquear permisos de escritura
  • 00:50~01:00: descubrimiento de tablas expuestas adicionales y corrección final completada

Lecturas relacionadas

8 comentarios

 
iolothebard 2026-02-04

Bailando felizmente… así nomás… ¡váyanse al desastre!
 
rustkim 2026-02-05

Al final, lo que queda es la Mac mini; como apenas está empezando, seguramente saldrá algo mejor, ¿no?
 
gogokow27 2026-02-05

jajajajajajaja....
 
kuthia 2026-02-04

Por fin, llegó lo que tenía que llegar.
 
crawler 2026-02-04

MoltBot: le explotan problemas de hackeo en los agentes y ahora también se les rompe la plataforma jajaja

Creo que va a quedar como un caso del proyecto con la peor vibra de 2026.
Todavía estamos en febrero, pero lo puedo asegurar jajaja
 
bini59 2026-02-04

¿El problema será que, con vibecoding y sin prestar atención a la seguridad, igual se pueden desarrollar servicios a gran escala?
 
kimjoin2 2026-02-04

WOW
 
GN⁺ 2026-02-04
Opiniones de Hacker News

  • Al principio sorprendía el éxito de Moltbot/Moltbook, pero ahora se entiende
    La clave es que se trata de “agentes preempaquetados”. Para usuarios comunes que no están familiarizados con la tecnología, una propuesta como “compra una Mac Mini, copia unas líneas e instálalo” resulta muy atractiva por su accesibilidad
    Pero esa accesibilidad también está alimentando una pesadilla de seguridad. A medida que aumentan los usuarios que solo siguen la moda sin entender lo técnico, crece el riesgo de que entornos vulnerables persistan por más tiempo

    • Queda la duda de si realmente puede llamarse un éxito. Hay análisis que dicen que, en realidad, de 1.5 millones de agentes solo 17 mil tienen dueños humanos. También hubo un componente viral importante porque lo mencionaron influencers conocidos
    • Todos los LLM son inseguros por diseño. Se los puede eludir fácilmente con prompt injection o reward hacking. La única solución completa es bloquear por completo la entrada externa y el acceso a la red
    • Lo de “compra una Mac Mini e instálalo” es solo marketing. En la práctica, hay muchos errores de configuración y la gestión del contexto es un desastre. Quedan logs, pero hasta olvida la conversación inmediatamente anterior. La idea es buena, pero la implementación es tosca
    • Como cuando apareció Dropbox por primera vez, el factor de éxito es la ‘accesibilidad empaquetada’. Pero en una realidad donde ni siquiera las grandes empresas logran evitar hackeos, una DB mal configurada no se considera gran cosa. La comodidad sigue pesando más que la seguridad
    • Aún no está claro si solo fue algo muy comentado o si de verdad es un éxito

  • Como señaló Scott Alexander, lo importante es que los agentes interactúan entre sí y generan comportamientos compuestos
    Si eso empieza a afectar al mundo real, podría derivar en problemas ontológicos.
    Al final, es una estructura en la que realmente puede ocurrir “todo lo que esté escrito como YES en AGENT.md”

    • También hay quien responde que no entiende bien qué quiere decir eso
    • Por eso hice nono.sh, para que el agente empiece en un sandbox con aislamiento a nivel de kernel bajo un modelo de ‘zero trust’
    • Los humanos también somos, hasta cierto punto, seres que ‘repiten como loros’. Así como Moltbook imita a Reddit, los humanos también conversamos dentro de patrones predecibles. Al final, quizá somos menos inteligentes de lo que creemos

  • La API de Moltbook estaba abierta para cualquiera, así que con un prompt simple se podía inducir la filtración de correos electrónicos o datos de usuarios
    Por eso aparecen intentos de aislarlo con una Mac Mini, pero mientras esté conectado a la red, la protección total es imposible

    • No es una locura. Los LLM no distinguen con claridad entre instrucciones y datos. Es una especie de vulnerabilidad de ‘ingeniería social’
    • Al final, la cuestión es si se le pueden asignar tareas útiles sin riesgo. Por ejemplo, para encargarle compras o reservas de viaje necesita acceso a una tarjeta de crédito
    • Yo uso un LLM aislado en un entorno DMZ. Lo ejecuto con una cuenta sin disco y sin permisos de sudo. No es perfecto, pero más o menos funciona
    • En la práctica no existe una protección perfecta. Porque están presentes los tres elementos de la ‘tríada letal’: acceso a datos, texto no confiable y comunicación por red
    • Aun así, sí se puede poner una capa de supervisión y aprobación. Se puede crear una estructura que apruebe o limite las acciones del LLM, como el límite de una tarjeta de crédito

  • Probé OpenClaw y consume una cantidad enorme de tokens
    Para la seguridad, parece que ayudaría contar con hardware dedicado (como una Raspberry Pi) con permisos de API limitados. Si una Pi pudiera correr modelos más potentes, tendría intención de comprar una

  • Moltbook no tiene forma de distinguir entre IA y humanos. El problema es cómo implementar un ‘CAPTCHA inverso’

    • Por diversión, le di a Claude el prompt de “buscar cuentas espías humanas” y de hecho creó un hilo llamado ‘Reverse Turing Problem’. Pero ahora está inundado de spam, al punto de que ya no se puede conversar
    • Hace falta un método para que todas las entradas y salidas de una sesión estén firmadas y sean auditables. También debería poder rastrearse el prompt inyectado por un humano
    • Otra forma de distinguirlos sería pedir varias veces, en poco tiempo, tareas que sean fáciles para una IA pero difíciles para un humano
    • O lanzar rápidamente preguntas raras que un LLM probablemente ya conocería
    • Pero al final, sigue siendo difícil distinguir si una conducta fue inducida por un humano mediante prompts

  • Dicen que corrigieron el problema de seguridad de Moltbook en pocas horas, pero la cuestión es cómo explicar los fallos de seguridad de un proyecto hecho con ‘vibe coding’

    • De hecho, Claude generó la consulta para Supabase, y luego una persona se la pasó al desarrollador de Moltbook para que la corrigiera. Cuesta creerlo, pero fue así

  • Sorprende que haya gente analizando el interior de Moltbook. Desde el principio era un proyecto hecho en broma y nadie imaginó que crecería tanto

    • Pero si se expone la PII de los usuarios, ya no se puede dejar pasar como chiste: es un problema legal. La cultura del ‘vibe coding’ está creando un entorno de desarrollo sin responsabilidad
    • Dogecoin también empezó como una broma, pero hoy mueve miles de millones de dólares
    • Que investigadores de seguridad busquen vulnerabilidades también puede ser, al final, parte del ‘vibe’
    • Pero no se puede tapar daños reales con la excusa de que “era una broma”
    • Si fue un resultado creado intencionalmente por sus autores, la excusa de que era ‘una broma’ pierde fuerza

  • El incidente en el que una instancia de OpenClaw envió una clave de OpenAI a otra instancia fue gracioso y a la vez inquietante.
    No está claro si realmente envió la clave o si solo fingió hacerlo

  • El artículo de Wiz en sí se siente como si lo hubiera escrito una IA. La estructura de las oraciones y el uso de guiones son un estilo muy típico de los LLM.
    Tiene algo de irónico criticar la seguridad de una plataforma creada por LLM con un artículo escrito por un LLM
    La vulnerabilidad real probablemente sí existe, pero si lo hubiera escrito una persona, parece que habría menos relleno innecesario

  • Los datos expuestos revelaron que de 1.5 millones de agentes, solo 17 mil eran humanos
    Pero como el investigador obtuvo esa cifra consultando tablas directamente con una clave de API, publicarlo parece más un acto de crítica a la empresa que un simple bug report
    Hacerlo de esta manera puede poner en riesgo la relación de confianza y cooperación entre investigadores y empresas