GitHub aktualisierte seinen Datenbankeintrag zu CVE-2026-75911 am 4. September 2026, nachdem das CodeWhale-Maintainer-Advisory erstmals am 16. Juli veröffentlicht worden war. Ein geklontes Repository konnte dadurch Shell-Werkzeuge des KI-Coding-Agenten still aktivieren. Laut Advisory sind CodeWhale und codewhale-tui ab Version 0.8.41 bis vor 0.8.64 betroffen. Version 0.8.64 enthält die Korrektur.
Der Fehler ist kein Fernangriff auf jede Installation. Ein Nutzer muss ein bösartiges oder kompromittiertes Repository klonen oder öffnen und CodeWhale darin ausführen. Die Folge bleibt erheblich, weil eine projektgesteuerte Datei den Werkzeugumfang ohne ausdrückliche Zustimmung erweitern konnte.
Eine Projektdatei konnte die Shell-Grenze öffnen
CodeWhale liest .codewhale/config.toml oder .deepseek/config.toml aus einem Projekt. Das Advisory beschreibt, wie ein Repository allow_shell = true setzen konnte. Die Zusammenführung übernahm den Wert und fügte Shell-Werkzeuge zum Register des Modells hinzu.
Andere Einstellungen wie Freigaberichtlinie und Sandbox-Modus hatten bereits Schutzprüfungen, die nur Verschärfungen erlaubten. Ein Projekt konnte sie restriktiver machen, aber nicht still lockern. Für allow_shell fehlte dieser Schutz. Der Patch verhindert nun die Aktivierung der Shell aus dem Projektbereich.
Das Advisory bewertet den Fehler mit CVSS 3.1 von 7,8 als hoch. Es nennt einen lokalen Angriffsvektor, geringe Komplexität, keine Rechte des Angreifers auf dem Opfersystem, erforderliche Nutzerinteraktion und hohes mögliches Schadensausmaß. Das Szenario ist kein Beleg für tatsächliche Ausnutzung.
Die GitLab-Datenbank bestätigt Paketbereiche und empfiehlt 0.8.64 oder neuer. Sie belegt weder aktive Ausnutzung noch betroffene Nutzerzahlen.
Repository-Vertrauen gehört zum Sicherheitsmodell
Repository-Dateien sind nicht nur Code. Ein KI-Coding-Agent kann sie als Anweisungen, Werkzeugkonfiguration, Hooks oder Richtlinie lesen. Damit entsteht eine zweite Ausführungsfläche, bevor die Anwendung gebaut wird.
Ein sicheres Prioritätsmodell unterscheidet klar:
| Konfigurationsquelle | Sicherer Standard |
|---|---|
| Repository oder Workspace | Darf Berechtigungen einschränken, aber nicht still erweitern |
| Nutzerprofil | Darf bewusste persönliche Standards setzen |
| Organisationsrichtlinie | Darf maximale Befugnis erzwingen |
| Kommandozeile | Erfordert sichtbare, bewusste Nutzeraktion |
| Modellergebnis | Darf eigene Werkzeugrechte nicht ändern |
Maetras Leitfaden zu Prompt-Injection-Kontrollen erklärt die Trennung nicht vertrauenswürdiger Anweisungen von Befugnissen. Der Leitfaden zu Laufzeitkontrollen verbindet Werkzeugrechte, Identität, Prüfung und Wirkungsnachweise.
Erst aktualisieren, dann die Vertrauenskette prüfen
Betroffene Teams sollten auf 0.8.64 oder neuer wechseln. Danach sollten sie geklonte Repositories auf CodeWhale- und DeepSeek-Konfiguration prüfen, frühere Shell-Aktivierungen nachvollziehen und Zugangsdaten rotieren, wenn ein nicht vertrauenswürdiger Workspace Befehle ausgeführt haben könnte.
Eine Untersuchung sollte Repository-Commit, Konfigurationshash, wirksame Einstellungen, Werkzeugregister, Sitzung, Befehle, Prozessergebnisse, Dateiänderungen, Netzwirkungen und Freigaben erhalten. Nur die Datei zu löschen vernichtet Belege und beantwortet nicht, ob etwas geschah.
Negative Tests sind wichtig. Eine Projektdatei mit zusätzlichen Befugnissen muss ignoriert oder abgelehnt werden. Organisationsgrenzen müssen nach Zusammenführung, Neustart und Kommandozeilenänderung bestehen bleiben. Protokolle sollen die wirksame Richtlinie ohne Geheimnisse erfassen.
Offene Fragen
Das Advisory behauptet keine aktive Ausnutzung und nennt keine Installationszahlen. Die tatsächliche Wirkung hängt von Modellergebnis, Befehlsklassifikation, Nutzerkontext, Betriebssystemrechten und verfügbaren Zugangsdaten ab.
Für ältere deepseek-tui-Pakete gelten unterschiedliche Bereiche. Teams müssen den genauen Eintrag ihres Ökosystems prüfen.
Maetra-Analyse
Das Designprinzip lautet monotone Befugnis. Weniger vertrauenswürdige Konfiguration darf Rechte entfernen, mehr Prüfung fordern oder den Umfang reduzieren. Sie darf kein Werkzeug, keine Identität und keinen Ausführungsmodus gewähren, den eine höhere Ebene nicht autorisiert hat.
Zusätzlich ist Wirkungsprüfung nötig. Eine sichere Richtlinie kann bestehen, während Hook, Plugin, Umgebungsvariable oder Wrapper einen anderen Shell-Weg öffnet. Erfassen Sie die gesamte Werkzeugfläche, berechnen Sie die wirksame Richtlinie nach jeder Zusammenführung und prüfen Sie tatsächliche Effekte.
CVE-2026-75911 ist ein klar begrenzter Fehler mit Patch. Die breitere Lehre gilt für jeden Coding-Agenten: Der Workspace ist Eingabe, keine Autorität.