GhostApproval: Symlink-Lücke lässt KI-Coding-Agenten Dateien ausserhalb der Sandbox schreiben — sechs Tools betroffen

TL;DR — 90 Sekunden

Betroffen?

Sechs KI-Coding-Agenten: Amazon Q Developer (<1.69.0), Cursor (<3.0), Google Antigravity (bis 1.19.6), Anthropic Claude Code (v2.1.42, Befund als "outside threat model" zurückgewiesen), Augment (0.754.3) und Windsurf (V1.9566).

Risiko?

Ein bösartiges Repository enthält einen Symlink mit harmlos aussehendem Namen (z. B. project_settings.json), der tatsächlich auf sensible Dateien wie ~/.ssh/authorized_keys oder ~/.zshrc zeigt. Der Agent schreibt scheinbar in die harmlose Datei — tatsächlich landet der Inhalt am Symlink-Ziel. Die Freigabe-Dialoge zeigen dabei den vermeintlichen, nicht den tatsächlichen Zielpfad.

Sofortmaßnahme?

Betroffene Tools auf die gepatchten Versionen aktualisieren (Amazon Q ≥1.69.0, Cursor ≥3.0). Für Tools ohne Fix (Augment, Windsurf) oder mit abgelehntem Befund (Claude Code): Agenten mit eingeschränktem Dateisystemzugriff bzw. in Sandboxes betreiben und Repositories vor der Agent-Nutzung auf Symlinks prüfen.

Empfehlung?

Kein CVSS-Score offiziell vergeben — nur qualitative Einstufungen (Critical/High) je Anbieter. Keine bestätigte aktive Ausnutzung in freier Wildbahn, aber verwandte Muster wurden bereits im Miasma-Wurm beobachtet.

Kritikalität?

hoch (Hero-Badge) — betrifft sechs marktführende Tools, dokumentierte Credential-Exfiltration bei mindestens einem Anbieter (Augment), uneinheitlicher Patch-Stand.

Was ist das Problem?

Sicherheitsforscher von Wiz haben am 8. Juli 2026 unter dem Namen "GhostApproval" eine Schwachstellenklasse veröffentlicht, die sechs verbreitete KI-Coding-Agenten betrifft: Amazon Q Developer, Cursor, Google Antigravity, Anthropic Claude Code, Augment und Windsurf. Kern des Problems ist eine Kombination aus Symlink-Following (CWE-61) und einer irreführenden Darstellung in der Nutzeroberfläche (CWE-451) — Wiz beschreibt es als "Trust Boundary Gap".

Der Angriff: Ein Repository enthält einen Symlink, dessen Name harmlos wirkt (z. B. project_settings.json), dessen tatsächliches Ziel aber eine sensible Datei ausserhalb des Projektverzeichnisses ist — etwa ~/.ssh/authorized_keys oder eine Shell-Startdatei wie ~/.zshrc. Fordert der Nutzer den Agenten auf, diese Datei zu bearbeiten (z. B. angeleitet durch eine präparierte README), schreibt der Agent tatsächlich an das Symlink-Ziel. Der Freigabe-Dialog vieler Tools zeigt dabei weiterhin den harmlosen, scheinbaren Pfad an — nicht den aufgelösten, tatsächlichen Zielpfad. Wiz fasst das Kernproblem so zusammen: Wenn der Bestätigungsdialog einen Pfad anzeigt, während das tatsächliche Ziel ein anderes ist, hat die Nutzer-Autorisierung keinen substanziellen Wert mehr.

Wer ist betroffen?

Betroffen ist grundsätzlich jeder, der einen dieser Agenten im Auto-Approve- oder reduzierten Freigabe-Modus auf nicht vollständig vertrauenswürdigen Repositories einsetzt — etwa beim Klonen von Open-Source-Projekten, Bewerber-Take-Home-Assignments oder externen Contributor-Branches. Der Schweregrad unterscheidet sich deutlich je Anbieter: Bei Windsurf erfolgt der Schreibzugriff laut Wiz bereits vor der Anzeige eines Freigabe-Dialogs; bei Augment werden Symlinks für Lese- und Schreibzugriffe kommentarlos verfolgt, dokumentierte Credential-Exfiltration inklusive; bei Cursor zeigte die Diff-Oberfläche den Symlink-Pfad an, während das Backend das Ziel ohne Warnung auflöste; bei Amazon Q erfolgen Schreibzugriffe vor der Autorisierung mit nur nachträglicher Rückgängig-Option.

Auswirkungen

Am gravierendsten ist das dokumentierte Szenario bei Augment: vollständige Credential-Exfiltration durch stille Symlink-Verfolgung ohne jede Nutzerzustimmung. Bei den übrigen betroffenen Tools reicht die Bandbreite von der Manipulation von SSH-authorized_keys (Persistenzmechanismus für Angreifer) bis zur Veränderung von Shell-Startdateien (Ausführung beliebigen Codes beim nächsten Login). Da die Freigabe-Dialoge den falschen Pfad anzeigen, ist eine informierte Nutzerentscheidung in den betroffenen Versionen faktisch nicht möglich — das Sicherheitsversprechen "der Nutzer bestätigt jede Dateiänderung" ist ausgehebelt.

Einschränkend: Es liegen laut Wiz keine Belege für aktive Ausnutzung in freier Wildbahn vor. Die Offenlegung ist Ergebnis gezielter Sicherheitsforschung, keine Reaktion auf einen laufenden Vorfall. Verwandte Muster — bösartige Repository-Inhalte, die KI-Coding-Agenten zu ungewollten Aktionen verleiten — wurden allerdings bereits beim Miasma-Wurm beobachtet, den dieser Blog im Juni 2026 behandelt hat.

Mitigation / Sofortmaßnahmen

Operativer Entscheidungsblock

• Jetzt handeln, wenn … Sie Amazon Q Developer unter 1.69.0 oder Cursor unter 3.0 einsetzen — hier existiert ein Fix, der eingespielt werden sollte.
• Mit Priorität prüfen, wenn … Sie Augment oder Windsurf einsetzen (kein Fix verfügbar) oder Claude Code im Auto-Approve-Modus auf nicht vertrauenswürdigen Repositories nutzen (Befund zurückgewiesen, nur Warnungen seit v2.1.32).
• Nur beobachten, wenn … Sie Ihre Coding-Agenten ausschließlich auf intern kuratierten, vertrauenswürdigen Repositories mit manueller Freigabe pro Dateiänderung betreiben.

Schritt 1 — betroffene Tools aktualisieren

# Amazon Q Developer Language Server-Version prüfen
q --version
# Cursor-Version prüfen
cursor --version

Schritt 2 — Repositories vor Agent-Nutzung auf Symlinks prüfen

# nach Symlinks in einem frisch geklonten Repository suchen
find . -type l -exec ls -la {} \;
# speziell nach Symlinks mit unauffälligen Namen, die auf Home-Verzeichnis-Dateien zeigen
find . -type l -exec readlink -f {} \; | grep -E "\.ssh|\.zshrc|\.bashrc|authorized_keys"

Schritt 3 — Agenten einschränken statt vertrauen

# Beispiel: Coding-Agent in einem Container ohne Zugriff auf das Host-Home-Verzeichnis betreiben
docker run --rm -it \
  -v "$(pwd)":/workspace:rw \
  --read-only --tmpfs /tmp \
  my-agent-sandbox-image

Schritt 4 — Auto-Approve deaktivieren für nicht vertrauenswürdige Quellen

# Grundsatz: Auto-Approve/Auto-Edit-Modi nur für Repositories aktivieren,
# deren Herkunft und Inhalt vollständig vertrauenswürdig sind.
# Bei externen Repos (Contributor-Branches, Coding-Challenges, Fremd-Projekte):
# jede Dateiänderung manuell prüfen, insbesondere bei Dateien mit
# unauffälligen Namen aber ungewöhnlichem Diff-Ziel.

Detection / Prüfung

Symlinks in vorhandenen geklonten Repositories aufspüren

find ~/projects -type l -exec readlink -f {} \; 2>/dev/null | \
  grep -E "\.ssh|authorized_keys|\.zshrc|\.bashrc|\.profile"

SSH-authorized_keys und Shell-Startdateien auf unerwartete Änderungen prüfen

# Zeitstempel und Inhalt gegen bekannten Stand abgleichen
stat ~/.ssh/authorized_keys ~/.zshrc ~/.bashrc
diff <(git show HEAD:.zshrc 2>/dev/null) ~/.zshrc

Laufzeit-Indikatoren

- neue, unbekannte Public Keys in ~/.ssh/authorized_keys
- unerwartete Ergänzungen in Shell-Startdateien (insbesondere Ausführungs- oder Netzwerk-Aufrufe)
- Coding-Agent-Sitzungen mit Dateizugriffen ausserhalb des erwarteten Projektverzeichnisses
- Freigabe-Dialoge, deren angezeigter Pfad nicht mit dem tatsächlichen Diff-Ziel übereinstimmt

Betreiberempfehlung

Jetzt handeln: Amazon-Q- und Cursor-Nutzer aktualisieren auf die gepatchten Versionen (1.69.0 / 3.0). Augment- und Windsurf-Nutzer schränken den Dateisystemzugriff der Agenten ein, bis ein Fix verfügbar ist.

Priorität: Teams, die KI-Coding-Agenten im Auto-Approve-Modus auf externen oder Contributor-Repositories einsetzen — unabhängig vom Tool —, richten eine Symlink-Prüfung vor jedem Agent-Lauf ein und reduzieren den automatischen Freigabe-Modus auf kuratierte, interne Repositories.

Beobachten: Wer Coding-Agenten ausschließlich mit manueller Freigabe jeder Dateiänderung und auf internen Repositories betreibt, ist strukturell weniger exponiert, sollte die eigene Tool-Version aber im Blick behalten, da sich der Patch-Stand über alle sechs Anbieter hinweg schnell ändert.

Fazit

GhostApproval zeigt ein strukturelles Problem, das nicht auf einen einzelnen Anbieter beschränkt ist: Freigabe-Dialoge, die einen Pfad anzeigen, während das Dateisystem einen anderen auflöst, sind keine wirksame Sicherheitsgrenze — unabhängig davon, wie sorgfältig ein Agent sonst mit Berechtigungen umgeht. Der uneinheitliche Patch-Stand (zwei echte Fixes, zwei laufende, ein zurückgewiesener Befund) bedeutet, dass Teams die Verantwortung nicht allein an den Tool-Anbieter delegieren können: Repository-Hygiene vor dem Einsatz von Coding-Agenten und eingeschränkter Dateisystemzugriff bleiben die verlässlicheren Kontrollen.

Quellen

• Wiz — GhostApproval: A Trust Boundary Gap in AI Coding Assistants (08.07.2026)
• The Hacker News — GhostApproval Symlink Flaws Could Let Malicious Repos Run Code in AI Coding Agents
• The Register — Bug in top AI coding agents shows that Unix-era security headaches never really die