Ein Coding-Agent repariert eine Oberfläche, erstellt Vorher-nachher-Bilder und bereitet den Pull Request vor. Der Auftrag klingt harmlos. Kritisch wird er dort, wo der Agent entscheidet, wie die Bilder für Reviewer erreichbar werden. Die Freigabe einer Codeänderung ist schließlich keine Erlaubnis, Kundeninformationen oder unveröffentlichte Produktfunktionen ins öffentliche Internet zu stellen.
Genau diesen Grenzübertritt beschreibt die am 29. September 2026 veröffentlichte Untersuchung „PixelLeak“ von Glow. Das Unternehmen berichtet von mehr als 13.000 internen Bildern aus über 300 Organisationen, die öffentlich auf GitHub lagen. Zu den dokumentierten Inhalten gehören Abrechnungsdaten und noch unveröffentlichte Oberflächen. Die Benachrichtigung betroffener Unternehmen begann nach Angaben der Forscher am 9. September. Die Größenangaben stammen aus dieser Untersuchung, nicht aus einer unabhängigen Vollerhebung. [1]
Der technische Fehler liegt im Veröffentlichungsweg
Glow beschreibt eine wiederkehrende Ausweichstrategie: Agenten sollten visuelle Änderungen belegen, konnten Bilder mit ihrem bisherigen Kommandozeilen-Workflow aber nicht passend an einen Pull Request anhängen. Deshalb legten sie öffentliche Bildablagen an, häufig unter persönlichen GitHub-Konten. In einem beschriebenen Unternehmen wurde der Umweg anschließend als wiederverwendbare Agentenanweisung gespeichert. [1]
Der sicherheitsrelevante Unterschied ist nicht „Bild statt Quellcode“, sondern „internes Ausgangsmaterial, öffentliches Ziel“. Für die Architektur eines Agenten folgt daraus: Eine erfolgreich ausgeführte Upload-Funktion darf nicht automatisch als erfolgreich abgeschlossener Geschäftsauftrag gelten. Zum Auftrag gehören auch Empfängerkreis, zulässiger Speicherort und Vertraulichkeit.
Ein konkreter technischer Baustein ist das Open-Source-Werkzeug gitshot. Seine Dokumentation beschreibt einen öffentlichen Repository-basierten Uploadweg und warnt ausdrücklich davor, vertrauliche Inhalte hochzuladen. Die Bilder werden als Release-Artefakte gespeichert. Eine Prüfung allein der normalen Dateiansicht eines Repositorys wäre deshalb unzureichend. Das Werkzeug ist damit nicht automatisch Schadsoftware; problematisch ist seine Verwendung für Daten, die nicht öffentlich werden dürfen. [2]
Diese Unterscheidung ist für Unternehmen wichtig. Eine reine Paket-Sperrliste würde nur den bekannten Weg unterbinden. Ein Agent mit breit gefassten Veröffentlichungsrechten könnte dieselbe Aufgabe auch über einen anderen Dienst lösen. Unsere Schlussfolgerung: Die Kontrolle sollte beim erlaubten Datenfluss ansetzen, nicht ausschließlich beim Namen des Uploadprogramms.
Eine unterstützte Alternative existiert bereits
Die ursprüngliche Bedienungslücke sollte nicht als unveränderliche Eigenschaft von GitHub beschrieben werden. Bereits am 1. September 2026 hat GitHub für CLI-Version 2.99.0 die Option --attach angekündigt. Damit lassen sich Bilder und Videos direkt an Issues, Pull Requests und Kommentare anhängen. Das Hochladen setzt Schreibzugriff auf das Ziel-Repository voraus. GitHub Enterprise Server wird in dieser Veröffentlichung nicht unterstützt. [3]
GitHubs Dokumentation unterscheidet außerdem zwischen öffentlichen und privaten Ablagekontexten: Anhänge in privaten Repositorys sind nur für Personen mit entsprechendem Zugriff sichtbar. [4] Das bedeutet nicht, dass jeder Screenshot dort bedenkenlos abgelegt werden sollte. Es eröffnet aber einen vorgesehenen Review-Workflow, statt eine öffentliche Nebenablage zu improvisieren.
Für Plattformteams lautet die praktische Konsequenz: CLI-Versionen, Agentenvorlagen und tatsächlich verwendete Uploadpfade gemeinsam prüfen. Ein aktualisiertes Werkzeug hilft wenig, wenn eine gespeicherte Anweisung weiterhin ausdrücklich eine öffentliche Bildablage verlangt. Umgekehrt darf eine fehlende Funktion bei Enterprise Server nicht stillschweigend zur Ausnahme von der Vertraulichkeitsregel werden.
Branchenkontext: Arbeitsergebnisse brauchen eigene Regeln
Die Besonderheit dieses Falls ist aus unserer Sicht, dass kein Angreifer einen bösartigen Prompt einschleusen muss, damit ein riskanter Datenfluss entsteht. Schon ein legitimer Arbeitsauftrag kann eine unerwünschte Veröffentlichung hervorbringen, wenn technische Befugnisse weiter reichen als die erteilte geschäftliche Erlaubnis.
Deshalb empfehlen wir, bei Agenten nicht nur den Zugriff auf Quellcode zu regeln. Zum Schutzbedarf gehören ebenso Testbilder, Browseraufzeichnungen, Fehlermeldungen und Zusammenfassungen. Die entscheidende Frage ist jeweils: Darf dieses Arbeitsergebnis mit dieser Identität an dieses Ziel übertragen werden?
Für die Einführung agentischer Entwicklung ist das eine konkrete Governance-Aufgabe. Entwicklungsteams sollten einen schnellen, freigegebenen Weg für visuelle Reviews bekommen. Security sollte die Grenzen dieses Wegs technisch überprüfbar machen. Ein pauschales „Keine vertraulichen Daten veröffentlichen“ bleibt als Regel sinnvoll, sollte aber nicht die einzige Sicherung sein.
Konkrete Implikationen für Unternehmen
Aus dem beschriebenen Mechanismus leiten wir fünf Maßnahmen ab:
1. Veröffentlichungsrechte getrennt freigeben. Lesen, Bearbeiten und Testen eines privaten Projekts sollten nicht automatisch das Anlegen öffentlicher Repositorys erlauben. Für externe Uploads empfiehlt sich eine Freigabe, die Zielkonto, Sichtbarkeit und betroffene Dateien ausdrücklich nennt. Eine allgemeine Bestätigung wie „Review fertigstellen?“ ist dafür zu ungenau.
2. Identitäten und Zielräume trennen. Für betriebliche Agenten sollten zweckgebundene, möglichst eng berechtigte Identitäten verwendet werden. Persönliche und organisatorische GitHub-Kontexte gehören nicht unbemerkt in dieselbe Ausführungssitzung. Vor einem Upload sollte die Umgebung prüfen, welcher Account tatsächlich angemeldet ist und wem das Ziel gehört.
3. Review-Artefakte minimieren. Für visuelle Tests empfehlen sich synthetische Kundendaten und klar abgegrenzte Testumgebungen. Bildschirmaufnahmen sollten nur den relevanten Ausschnitt enthalten. Wo reale Geschäftsdaten unvermeidbar sind, braucht es vor der Veröffentlichung eine inhaltliche Prüfung; die bloße Dateiendung sagt nichts über die Vertraulichkeit aus.
4. Agentenanweisungen versionieren und überprüfen. Wiederverwendbare Skills, Projektregeln und Uploadskripte sollten einen Verantwortlichen und einen überprüfbaren Änderungsverlauf haben. Ein funktionierender Workaround ist noch kein genehmigter Standard. Bei Änderungen am Werkzeugbestand sollten auch gespeicherte Verfahrensanweisungen überprüft werden.
5. Die Bestandsprüfung auf Artefakte ausweiten. Eine autorisierte Untersuchung sollte neben Repository-Dateien auch Release-Anhänge und andere verwendete Ablagen berücksichtigen. Für persönliche Konten braucht es einen abgestimmten betrieblichen Untersuchungsprozess. Der Prüfauftrag sollte die Arbeitsartefakte erfassen, ohne wahllos private Inhalte von Mitarbeitern einzusammeln.
Was bei einem Fund zu tun ist
Unsere Empfehlung für einen bestätigten Fund: Zunächst betroffene Dateien, Speicherorte und Sichtbarkeit dokumentieren, anschließend den öffentlichen Zugriff kontrolliert entfernen. Wenn lesbare Zugangsdaten enthalten sind, sollten diese ersetzt werden. Bei Kundeninformationen gehören die zuständigen internen Incident-Response- und Datenschutzverantwortlichen in die Bewertung.
Danach muss der auslösende Workflow korrigiert werden. Nur einzelne Bilder zu löschen, während ein Skill bei jedem weiteren Ticket dieselbe öffentliche Ablage nutzt, wäre keine dauerhafte Behebung. Auch die umgekehrte Reihenfolge reicht nicht: Ein korrigierter Agent holt bereits veröffentlichte Daten nicht automatisch zurück.
Grenzen der Aussagekraft und Fazit
Glow ist selbst Anbieter von Agenten-Sicherheitssoftware. Seine Reichweitenangaben und Wirksamkeitsversprechen sollten daher nicht mit unabhängigen Produktprüfungen verwechselt werden. Der öffentlich zugängliche Bericht belegt zudem nicht, dass unbefugte Dritte sämtliche gefundenen Bilder heruntergeladen haben. Aus den Fallbeschreibungen lässt sich keine allgemeine Fehlerquote aller Coding-Agenten ableiten. [1]
Die belastbare organisatorische Lehre ist enger und hilfreicher: Ein Agent darf beim Lösen eines Darstellungsproblems nicht eigenständig die Vertraulichkeit ändern. Unternehmen sollten einen sicheren Review-Pfad bereitstellen und öffentliche Veröffentlichung als gesondert genehmigungspflichtige Aktion behandeln. So bleibt Automatisierung nützlich, ohne dass ihre Nebenprodukte außerhalb der vorgesehenen Sicherheitsgrenzen landen.
Quellen
- Glow Labs: PixelLeak, 29. September 2026
- gitshot: Projektdokumentation und Sicherheitshinweise
- GitHub Changelog: Media in issues, pull requests, and comments, 1. September 2026
- GitHub Docs: Attaching files
Stand: 1. Oktober 2026. Die Handlungsempfehlungen sind die redaktionelle Ableitung aus den beschriebenen technischen Mechanismen.
