Moltbook: Anatomía de un desastre de seguridad anunciado

TL;DR:

Moltbook, red social para agentes de IA, expuso 1.5 millones de tokens, 35,000 emails y 4,060 mensajes privados
El sitio fue construido íntegramente con "vibe coding" (código generado por IA) sin validación de seguridad
Una API key de Supabase con permisos administrativos expuesta en el cliente permitió acceso total a producción
El hackeo tomó minutos y reveló que 17,000 humanos controlaban los "agentes autónomos"

El experimento que se convirtió en caso de estudio

En enero de 2026, Matt Schlicht, CEO de Octane AI, lanzó Moltbook: una red social exclusivamente para agentes de inteligencia artificial. El concepto sonaba innovador: permitir que bots interactúen entre sí sin intervención humana, creando una "sociedad digital autónoma". La plataforma alcanzó 1.5 millones de registros en su primer fin de semana.

El problema es que la implementación fue un desastre de seguridad de principio a fin.

El 2 de febrero de 2026, Wiz Security publicó un análisis devastador: la base de datos completa de Moltbook estaba expuesta debido a una configuración negligente de Supabase. Los investigadores accedieron sin restricciones a todos los datos de la plataforma en cuestión de minutos.

Este artículo analiza técnicamente qué salió mal, cómo ocurrió el exploit, y qué lecciones críticas deja para la industria.

Arquitectura técnica: cuando la velocidad mata la seguridad

Schlicht afirmó públicamente que no escribió "una sola línea de código manualmente". Moltbook fue construido usando "vibe coding" — generación de código asistida por IA mediante su herramienta Moltbot (ahora OpenClaw).

Stack tecnológico identificado

Capa	Tecnología	Vulnerabilidad crítica
Frontend	Next.js / React	API key con permisos administrativos hardcodeada en JavaScript público
Backend	Supabase (PostgreSQL)	Row Level Security (RLS) completamente deshabilitado en producción
Autenticación	Tokens por agente	Sin validación de identidad real; cualquiera podía crear agentes falsos
Verificación	Tweet opcional	Verificación basada en confianza, sin enforcement técnico

Supabase es una plataforma de backend-as-a-service construida sobre PostgreSQL. Ofrece APIs REST y realtime, autenticación integrada, y un sistema de seguridad basado en Row Level Security (RLS). El problema es que RLS está deshabilitado por defecto y requiere configuración manual.

Moltbook nunca habilitó RLS. Peor aún, expuso una API key con permisos totales en el código del cliente.

El exploit: tan simple que duele

El hackeo no requirió técnicas sofisticadas. Según el reporte de Wiz Security, el proceso fue el siguiente:

1. Inspección del código cliente

Los investigadores abrieron las DevTools del navegador (F12) y examinaron el código JavaScript cargado por la página. Encontraron una API key de Supabase con permisos de lectura/escritura completos.

// Código simplificado de lo encontrado (valores ficticios)
const SUPABASE_URL = "https://xxx.supabase.co"
const SUPABASE_ANON_KEY = "eyJhbGc... [key con permisos administrativos]"

Esta key no era la clave pública estándar (anon). Era una clave con permisos equivalentes a service_role, que debería permanecer exclusivamente en el backend.

2. Acceso directo a la base de datos

Con la API key expuesta, los atacantes podían inicializar el cliente de Supabase y ejecutar queries arbitrarios:

import { createClient } from '@supabase/supabase-js'

const supabase = createClient(SUPABASE_URL, EXPOSED_API_KEY)

// Leer todos los agentes registrados
const { data: agents } = await supabase
  .from('agents')
  .select('*')

// Acceder a mensajes privados
const { data: messages } = await supabase
  .from('direct_messages')
  .select('*')

// Suplantar cualquier agente
await supabase
  .from('posts')
  .insert({
    author_id: 'cualquier_agente_id',
    content: 'Contenido malicioso inyectado',
    submolt: 'cualquier_comunidad'
  })

3. Extracción masiva de datos

Wiz Security documentó que pudieron acceder a:

1.5 millones de tokens de autenticación de agentes registrados
35,000 direcciones de correo electrónico de usuarios humanos
4,060 mensajes privados intercambiados entre bots
Credenciales completas y configuraciones de agentes

La ausencia de Row Level Security significaba que no había restricciones a nivel de base de datos. Un atacante podía leer, modificar o eliminar cualquier registro.

Análisis de las vulnerabilidades

CVE-like classification

Si este fuera un CVE formal, las vulnerabilidades serían:

1. Exposed Administrative Credentials (CWE-798)

Severidad: Crítica
CVSS Score estimado: 9.8 (Critical)
Descripción: API key con permisos administrativos expuesta en código JavaScript del cliente

2. Missing Authorization (CWE-862)

Severidad: Crítica
CVSS Score estimado: 9.1 (Critical)
Descripción: Ausencia total de Row Level Security en base de datos de producción

3. Improper Authentication (CWE-287)

Severidad: Alta
CVSS Score estimado: 7.5 (High)
Descripción: Sistema de verificación de identidad basado en confianza sin validación técnica

Falta de defensa en profundidad

Moltbook carecía de múltiples capas de seguridad básicas:

❌ Sin secrets management: API keys hardcodeadas en código versionado
❌ Sin RLS en Supabase: Políticas de seguridad no configuradas
❌ Sin rate limiting: APIs sin throttling ni protección contra abuso
❌ Sin validación de identidad: Registro de agentes sin verificación real
❌ Sin logging/monitoring: No se detectó el acceso no autorizado en tiempo real
❌ Sin Content Security Policy: Headers de seguridad HTTP ausentes

La realidad detrás de los "agentes autónomos"

El hackeo reveló un dato inesperado: 17,000 humanos controlaban múltiples bots simultáneamente. La "sociedad autónoma de IA" era en gran medida humanos roleplayeando como agentes.

Wiz Security y otros investigadores documentaron que:

Muchos agentes eran controlados manualmente vía requests HTTP directos
Los "debates filosóficos" entre bots seguían scripts predefinidos
La verificación por Twitter era opcional y fácilmente falsificable
El sistema no distinguía entre agentes autónomos reales y cuentas puppet

Esto plantea una pregunta incómoda: ¿Moltbook era un experimento de IA, o un LARP (Live Action Roleplay) colectivo con branding de IA?

Respuesta del equipo y timeline

2 de febrero, 10:00 AM (aprox.): Wiz Security descubre las vulnerabilidades

2 de febrero, 12:00 PM: Notificación responsable al equipo de Moltbook

2 de febrero, 4:00 PM: Moltbook corrige la configuración de Supabase y rota las API keys

2 de febrero, 6:00 PM: Wiz publica el análisis técnico

Hay que reconocer que el equipo de Moltbook actuó con rapidez una vez notificado. Las correcciones incluyeron:

✅ Habilitación de Row Level Security en todas las tablas ✅ Rotación de API keys comprometidas ✅ Eliminación de la key administrativa del código del cliente ✅ Implementación de políticas de acceso restrictivas

Sin embargo, el daño reputacional estaba hecho. Reuters, Business Insider, El País y Infobae publicaron análisis críticos del incidente.

Lecciones técnicas para la industria

1. Vibe coding no reemplaza security audits

Lección: La generación de código asistida por IA acelera el desarrollo, pero no garantiza seguridad.

Recomendación:

Implementar checklist de seguridad pre-deployment
Auditar configuraciones de servicios en la nube (Supabase, Firebase, AWS)
No confiar en defaults; verificar explícitamente RLS, CORS, API permissions

Checklist mínimo:

# Antes de deploy a producción
- [ ] RLS habilitado en todas las tablas con datos sensibles
- [ ] API keys públicas limitadas a permisos read-only donde aplique
- [ ] Service role keys NUNCA expuestas en frontend
- [ ] Rate limiting configurado en APIs públicas
- [ ] Logging y monitoring activos
- [ ] Security headers (CSP, HSTS, X-Frame-Options)

2. Supabase != "automágicamente seguro"

Lección: Supabase facilita el desarrollo rápido, pero RLS debe configurarse manualmente.

Ejemplo de configuración correcta:

-- Habilitar RLS en tabla de agentes
ALTER TABLE agents ENABLE ROW LEVEL SECURITY;

-- Política: usuarios solo pueden leer sus propios agentes
CREATE POLICY "Users can only read own agents"
ON agents FOR SELECT
USING (auth.uid() = owner_id);

-- Política: usuarios solo pueden insertar agentes propios
CREATE POLICY "Users can only create own agents"
ON agents FOR INSERT
WITH CHECK (auth.uid() = owner_id);

-- Política: usuarios solo pueden actualizar sus agentes
CREATE POLICY "Users can only update own agents"
ON agents FOR UPDATE
USING (auth.uid() = owner_id);

3. Separar keys públicas de administrativas

Lección: Supabase provee dos tipos de API keys. Solo la anon key debe exponerse en el cliente.

Configuración correcta:

// Frontend (público)
const supabase = createClient(
  process.env.NEXT_PUBLIC_SUPABASE_URL!,
  process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY! // Solo permisos limitados
)

// Backend/Server (privado)
const supabaseAdmin = createClient(
  process.env.SUPABASE_URL!,
  process.env.SUPABASE_SERVICE_ROLE_KEY! // NUNCA exponer
)

4. "Experimental" no exime de responsabilidad legal

Lección: Almacenar datos personales (emails, credenciales) implica obligaciones legales bajo GDPR, CCPA, y legislación local.

Realidad legal:

Moltbook almacenaba 35,000 emails de usuarios reales
Los mensajes privados contenían conversaciones potencialmente sensibles
La exposición de estos datos podría derivar en multas bajo GDPR (hasta 4% de revenue global)

Recomendación:

Si el proyecto almacena PII (Personally Identifiable Information), debe cumplir estándares de seguridad
Implementar encryption at rest y in transit
Proveer mecanismos de data deletion bajo derecho al olvido

El costo del "move fast and break things" aplicado a seguridad

Moltbook es un recordatorio de que no todos los mantras de Silicon Valley escalan bien.

"Move fast and break things" funciona para iterar features. No funciona para seguridad. Un bug en el feed de noticias es molesto. Una brecha de seguridad es un incidente legal.

Andrej Karpathy, ex-director de IA en Tesla, comentó públicamente sobre los riesgos del vibe coding sin supervisión técnica. Otros expertos en seguridad como Jamieson O'Reilly documentaron problemas adicionales en la configuración de proxies de OpenClaw.

La comunidad de seguridad fue clara: esto no debería haber pasado. No en 2026. No con las herramientas y documentación disponibles.

Verificación de fuentes y referencias

Este análisis se basa en:

Reportes técnicos primarios

Wiz Security: Moltbook Database Breach Analysis - Análisis técnico del exploit
Okta: Identity Lessons from Moltbook - Perspectiva de gestión de identidad

Cobertura periodística verificada

Documentación técnica oficial

Conclusión: el precio de la negligencia técnica

Moltbook no fue hackeado por un exploit de día cero sofisticado. Fue comprometido por negligencia básica: API keys expuestas y ausencia de controles de acceso.

El incidente deja tres conclusiones claras:

La IA no reemplaza el criterio de seguridad humano. Vibe coding es una herramienta, no una solución completa.
Los servicios en la nube requieren configuración activa. Los defaults no son seguros para producción.
"Experimental" no es excusa legal. Si almacenás datos reales de usuarios, tenés responsabilidades reales.

Moltbook sigue online, ahora con configuraciones de seguridad corregidas. Pero el daño está hecho. La plataforma pasará a la historia no como un experimento innovador de IA, sino como un caso de estudio de qué no hacer.

Para los developers construyendo con IA, automatización, o agentes autónomos: este es el momento de revisar vuestros proyectos. No querés ser el próximo.

Tincho Fuentes Periodista tecnológico e investigador 🚀