El Compromiso de MemOS y MemoryOS: Qué Revisar y Qué Rotar

1. Contexto: Qué Pasó el 23 de Septiembre de 2026

GitHub describe MemOS como un sistema operativo de memoria para LLMs y agentes de IA; MemoryOS es su paquete en PyPI y el plugin de npm lo conecta con OpenClaw, un asistente personal de IA de código abierto. No fue typosquatting: los nombres eran los reales. Según el registro de OSV, un atacante con permisos de escritura en el repositorio de GitHub subió commits maliciosos y un tag v2.0.34, y el propio workflow de release del proyecto construyó y subió el archivo a PyPI. En npm, la reconstrucción de SafeDep muestra cinco versiones en unas dos horas, alternando maliciosas y limpias.

Consecuencia práctica: la pregunta no es ‘¿mi versión es vulnerable?’ sino ‘¿algo en esta máquina cargó alguna vez una de estas cuatro versiones?’. Semgrep dice que hay que tratar como comprometido cualquier host que cargó una versión afectada de npm o importó la de PyPI, incluso los runners de CI que solo corrieron tests.

2. Cuatro Implicaciones para Equipos con Memoria de IA y Plugins de Agentes

Estas son las cuatro consecuencias que cambian cómo trataría las dependencias de agentes, ordenadas por la frecuencia con que van a importar en una semana normal.

# 1. Lockfiles, manifiestos y SBOMs en cada repo y caché de CI
grep -rnEi 'memos-cloud-openclaw-plugin|memoryos' \
  --include='package-lock.json' --include='pnpm-lock.yaml' --include='yarn.lock' \
  --include='requirements*.txt' --include='poetry.lock' --include='uv.lock' \
  --include='*.sbom.json' .

# 2. Qué está instalado ahora mismo
npm ls --all 2>/dev/null | grep -i memos-cloud-openclaw-plugin
pip show MemoryOS 2>/dev/null | grep -i '^version'

# 3. Artefactos del host que nombran los reportes
ls -la ~/.openclaw/.cache/runtime ~/.memos/.cache/runtime 2>/dev/null
pgrep -fl sckit
# PowerShell: Get-Process sckit -ErrorAction SilentlyContinue

# 4. Logs de DNS, proxy y egress desde el 23-09: skyleen.fr y subdominios
grep -rniE 'skyleen\.fr' /var/log 2>/dev/null

3. Qué Hacer Esta Semana

Cinco días hábiles. Los días 1–2 te dicen si estuviste expuesto; los días 3–4 asumen que sí; el día 5 hace más difícil el próximo.

4. Qué Está Confirmado y Qué No (Revisado el 14 de Octubre de 2026)

‘Confirmado’ significa al menos dos registros independientes: un registro, OSV o GitHub más un informe de un proveedor, o dos proveedores con análisis propio. Todo lo demás va redactado como ‘según’.

Conclusión

El compromiso de MemTensor es un ejemplo limpio de hacia dónde van los ataques a la cadena de suministro: no un hook de instalación, sino nombres de paquete reales desde un camino de release secuestrado, ejecutándose cuando tu agente arranca o recuerda algo, justo al lado de tus prompts y tokens. Las versiones afectadas ya no están en los registros; la exposición es una propiedad de las máquinas que alguna vez las cargaron.

Hacé el pase de cinco días: encontrar, rotar y después endurecer el pipeline desde el que publicás. Si mantenés paquetes, los puntos del día 5 son los que no postergaría: el token de la próxima víctima podría ser el tuyo.

Fuentes

• Semgrep — The AI Ecosystem Has Worms Now: Inside the MemTensor Compromise
• OSV — MAL-2026-16475 (MemoryOS en PyPI)
• GitHub Advisory Database — GHSA-mhjf-v53x-7p87 (malware en el plugin npm)
• SafeDep — paquetes npm y PyPI de MemTensor golpeados por un gusano en Go
• Socket — compromiso de MemTensor
• Aikido — malware supplychain.local en npm y PyPI de MemTensor
• Cloud Security Alliance — AI Memory, Compromised: el ataque a la cadena de suministro de MemTensor
• Registro npm — metadatos de @memtensor/memos-cloud-openclaw-plugin (revisado el 14 oct 2026)
• PyPI — metadatos JSON de MemoryOS (revisado el 14 oct 2026)
• GitHub — releases de MemTensor/MemOS
• GitHub Advisory Database — GHSA-v9vw-ccqp-q298 (advisory de autenticación de MemOS, sin relación)