E-Mail-Prompt-Injection in Manus: Code lief vor der Warnung

Salt Labs berichtet, dass eine präparierte E-Mail Manus dazu bringen konnte, Code in seiner Server-Laufzeit auszuführen, bevor die Plattform den Nutzer warnte. Die Forscher geben an, den Fehler verantwortungsvoll gemeldet zu haben; er sei behoben. Ein CVE oder ein realer Opferkompromiss wurde nicht gemeldet.^[1]

💡 Einfache Erklärung (ELI5)

Stellen Sie sich eine Poststelle vor, deren Mitarbeiter einen Brief vorliest und darin versteckte Anweisungen ausführt, bevor er die Leitung fragt, ob der Brief vertrauenswürdig ist. Die Warnung kommt erst nach der Handlung. Die Sicherheitsgrenze muss verhindern, dass nicht vertrauenswürdiger Brieftext überhaupt zu ausführbaren Anweisungen wird.^[1]

Kernkonzepte & Begriffe

Indirekte Prompt-Injection: Anweisungen in Inhalten, die eine KI untersuchen soll, etwa einer E-Mail, statt in der direkten Nutzereingabe.^{[1], [5]}
Agenten-Laufzeit: Prozess und Werkzeuge, die ein Agent nutzen kann. Berechtigungen und Isolation bestimmen die Auswirkungen modellbeeinflusster Aktionen.^{[1], [6]}
Durchsetzung vor Ausführung: Eine Kontrolle, die eine Aktion vor der Codeausführung oder dem Werkzeugaufruf blockiert. Eine nachträgliche Warnung kann die Ausführung nicht verhindern.^{[1], [6]}
CWE-94 (redaktionelle Zuordnung): Unzureichende Kontrolle der Codegenerierung oder -ausführung. FlawOpen nutzt dies als konzeptionelle Zuordnung für den demonstrierten Übergang von nicht vertrauenswürdigem Inhalt zu Code; Salt Labs hat keine CWE oder CVE vergeben.^{[4], [1]}

Framework-Zuordnungen

Konzeptionelle Zuordnung von FlawOpen zu MITRE CWE; weder ein Anbieter noch ein CVE-Datensatz hat diese Schwachstellen-ID dieser Forschungsdemonstration zugewiesen. CWE-94
OWASP GenAI 2025 — LLM01:2025 Prompt-Injection
OWASP GenAI 2025 — LLM06:2025 Übermäßige Autonomie

Schritt-für-Schritt Angriffsablauf

Schritt 1

Der Nutzer bittet Manus, E-Mails zu prüfen

Laut Salt Labs genügte im kontrollierten Test die Aufforderung, den Posteingang zu prüfen; ein zusätzlicher Klick oder gestohlene Zugangsdaten waren nicht erforderlich.^[1]

Schritt 2

Eine E-Mail liefert nicht vertrauenswürdige Inhalte

Die Nachricht enthielt Anweisungen im normalen E-Mail-Text. Eine Klassifizierung oder Warnung des Modells bildet für diese Daten keine Sicherheitsgrenze.^[1]

Schritt 3

Der Inhalt erreicht einen serverseitigen Ausführungspfad

Salt Labs berichtet, Manus habe den Inhalt über eine Node.js-Laufzeit verarbeitet und Code ausgeführt, bevor Warnung und Genehmigungsabfrage erschienen. Die genaue interne Implementierung ist nicht öffentlich; dies ist der Bericht der Forscher, kein Quellcode-Audit.^[1]

Schritt 4

Der Ausführungskontext besitzt verbundene Berechtigungen

Im kontrollierten Test konnte die Laufzeit laut Salt Labs auf Token verbundener Dienste zugreifen. Die mögliche Reichweite hing von den verfügbaren Integrationen und Berechtigungen ab.^[1]

Schritt 5

Die Offenlegung wurde behoben

Salt Labs zufolge wurde der Fehler über das Meta-Bug-Bounty-Programm gemeldet und die konkrete Technik ist nicht mehr ausnutzbar. Es war eine Forschungsdemonstration, kein Kundenleck; es gibt weder CVE noch öffentliches Patch-Diff.^[1]

Quellcode: Verwundbar vs. Sicher

Salt Labs veröffentlicht weder den verwundbaren Manus-Quellcode noch das Patch-Diff des Anbieters. Diese Beispiele zeigen einen allgemeinen Vertrauensgrenzenfehler und eine defensive Architektur; sie rekonstruieren das Produkt nicht. Nicht vertrauenswürdige E-Mails gehören in einen Zusammenfassungspfad ohne Ausführungsfähigkeit. Eine separate Serverrichtlinie muss die genaue Aktion autorisieren, bevor ein Werkzeug oder eine Laufzeit sie ausführt.^{[1], [6]}

VERWUNDBARE IMPLEMENTIERUNG

// Illustratives unsicheres Design; kein Manus-Quellcode.
async function inspectEmail(email: Email) {
  return agent.process(email.body, { tools: [serverSideRuntime] });
}

GEHÄRTETER SICHERHEITS-PATCH

// Illustrative sicherere Grenze; weder Manus-Implementierung noch Patch.
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);
}

Checkliste für Engineering & Systemsicherheit

✓Behandeln Sie E-Mail-Texte, Anhänge, zitierte Verläufe und abgerufene Webinhalte als nicht vertrauenswürdige Daten, auch wenn das Modell sie als harmlos oder bösartig einstuft.^{[1], [5]}
✓Lassen Sie die E-Mail-Zusammenfassung keine universelle Code-Laufzeit aufrufen. Trennen Sie schreibgeschützte Analyse von Werkzeugausführung und verwenden Sie eng begrenzte, typisierte Werkzeuge.^{[1], [6]}
✓Setzen Sie die Autorisierung vor der Ausführung in einer serverseitigen Richtlinie durch; binden Sie die Genehmigung an authentifizierten Akteur, genaue Aktion, Zielressource und kurze Gültigkeit.^[6]
✓Sorgen Sie für wirksame Isolation: Legen Sie OAuth-Token oder weitreichende Connector-Zugangsdaten nicht in einer Laufzeit offen, die Inhalte verarbeitet.^{[1], [6]}
✓Verweigern Sie standardmäßig, wenn Genehmigung, Audit oder Richtlinienprüfung nicht verfügbar sind. Eine Warnung nach der Ausführung ist keine Prävention.^[6]
✓Bewahren Sie Protokolle zu Werkzeugaufrufen und Laufzeit auf und testen Sie, dass adversariale E-Mails vor der Autorisierung keine Aktion auslösen können.^{[1], [6]}
✓Salt Labs zufolge ist der gemeldete Fehler behoben. Prüfen Sie aktuelle Manus-Sicherheitshinweise; leiten Sie daraus keinen gleichartigen Fehler in allen Agentenplattformen ab.^[1]

Quellen

← AI Security Directory →