Inyección de prompt por correo en Manus: el código se ejecutó antes de la alerta

Salt Labs informó que un correo preparado podía llevar a Manus a ejecutar código en su entorno del servidor antes de alertar al usuario. Los investigadores dicen que divulgaron el problema de forma responsable y que ya está resuelto; no hay CVE ni compromiso real de una víctima reportado.^[1]

💡 Explicación en Lenguaje Sencillo (ELI5)

Imagina a una persona de clasificación que lee una carta en voz alta y sigue las instrucciones ocultas antes de preguntar a su supervisor si la carta es fiable. La advertencia llega después de actuar. La barrera de seguridad debe impedir desde el principio que el texto no confiable se convierta en instrucciones ejecutables.^[1]

Conceptos Clave y Términos

Inyección indirecta de prompt: Instrucciones incluidas en contenido que la IA debe analizar, como un correo, en vez de proporcionadas directamente por el usuario.^{[1], [5]}
Entorno de ejecución del agente: Proceso y herramientas que un agente puede usar. Sus permisos y aislamiento determinan el impacto de las acciones influenciadas por el modelo.^{[1], [6]}
Aplicación antes de ejecutar: Control que bloquea una acción antes de ejecutar código o invocar una herramienta. Una alerta posterior no puede impedir esa ejecución.^{[1], [6]}
CWE-94 (asociación editorial): Control inadecuado de la generación o ejecución de código. FlawOpen usa esta asociación conceptual para la transición demostrada de contenido no confiable a código; Salt Labs no asignó CWE ni CVE.^{[4], [1]}

Mapeos de marcos

Mapeo conceptual de FlawOpen a MITRE CWE; ningún proveedor ni registro CVE asignó este identificador de debilidad a esta demostración de investigación. CWE-94
OWASP GenAI 2025 — LLM01:2025 Inyección de prompts
OWASP GenAI 2025 — LLM06:2025 Agencia excesiva

Flujo de Ataque Paso a Paso

Paso 1

El usuario pide a Manus que revise el correo

Salt Labs dice que en su prueba controlada bastó con pedir a Manus que inspeccionara la bandeja de entrada; no hizo falta otro clic ni robar credenciales.^[1]

Paso 2

Un mensaje aporta contenido no confiable

El correo incluía instrucciones dentro del contenido ordinario. La clasificación o advertencia del modelo no constituye una barrera de seguridad para esos datos.^[1]

Paso 3

El contenido llega a una ruta de ejecución en el servidor

Salt Labs informa que Manus procesó el contenido mediante un entorno Node.js y ejecutó código antes de mostrar la advertencia y la solicitud de aprobación. La implementación interna exacta no es pública; es el relato de los investigadores, no una auditoría del código fuente.^[1]

Paso 4

El contexto de ejecución alcanza permisos conectados

En su prueba controlada, Salt Labs informa que el entorno podía acceder a tokens asociados con servicios conectados por el usuario. El alcance potencial dependía de las integraciones y permisos disponibles allí.^[1]

Paso 5

La divulgación se resolvió

Salt Labs dice que informó del problema mediante el programa de recompensas de Meta y que la técnica concreta ya no es explotable. Fue una demostración de investigación, no una brecha de clientes; no hay CVE ni diff público del parche.^[1]

Código Fuente: Vulnerable vs. Seguro

Salt Labs no publica el código vulnerable de Manus ni el diff del parche del proveedor. Estos ejemplos ilustran un fallo general del límite de confianza y una arquitectura defensiva; no reconstruyen el producto. Mantén el correo no confiable en una ruta de resumen sin capacidad de ejecución. Una política separada del servidor debe autorizar la acción exacta antes de que una herramienta o entorno pueda realizarla.^{[1], [6]}

IMPLEMENTACIÓN VULNERABLE

// Diseño inseguro ilustrativo; no es código fuente de Manus.
async function inspectEmail(email: Email) {
  return agent.process(email.body, { tools: [serverSideRuntime] });
}

PARCHE SEGURO Y ROBUSTO

// Límite más seguro ilustrativo; no es la implementación ni el parche de Manus.
async function inspectEmail(email: Email, session: AuthenticatedSession) {
  const summary = SummarySchema.parse(
    await readOnlyModel.summarize({ content: email.body })
  );
  const proposal = ActionRequestSchema.parse(
    await readOnlyModel.proposeAction({ summary })
  );
  if (!proposal) return summary;

  const approval = await approvalStore.consumeExact({
    actorId: session.userId,
    action: proposal.action,
    resourceId: proposal.resourceId
  });
  const permit = await serverPolicy.authorize({
    actorId: session.userId,
    action: proposal.action,
    resourceId: proposal.resourceId,
    approval
  });
  if (!permit.allowed) throw new Error("Action denied");
  return narrowTools.execute(permit.approvedAction);
}

Lista de Verificación de Seguridad para Ingeniería

✓Trata cuerpos de correo, adjuntos, hilos citados y contenido web recuperado como datos no confiables, aunque el modelo los clasifique como benignos o maliciosos.^{[1], [5]}
✓No permitas que el resumen de correo invoque un runtime de código de propósito general. Separa el análisis de solo lectura de la ejecución de herramientas y usa herramientas limitadas y tipadas.^{[1], [6]}
✓Aplica la autorización antes de ejecutar en una política del servidor; vincula la aprobación al actor autenticado, la acción y el recurso exactos y una caducidad breve.^[6]
✓Mantén un aislamiento real: no expongas tokens OAuth ni credenciales amplias de conectores a un runtime que procesa contenido.^{[1], [6]}
✓Falla de forma segura si no están disponibles la aprobación, la auditoría o la evaluación de políticas. Una alerta posterior no previene la acción.^[6]
✓Conserva registros de llamadas a herramientas y del runtime, y prueba que un correo adversarial no pueda activar ejecución antes de la autorización.^{[1], [6]}
✓Salt Labs afirma que la vulnerabilidad divulgada ya está resuelta. Verifica las indicaciones de seguridad actuales de Manus y no supongas que otras plataformas comparten el mismo fallo.^[1]

Fuentes

← AI Security Directory →