
Sicherheitsforschungslabor: kontrollierte Reproduktion von GHSA-3g6g-gq4r-xjm9 / CVE-2026-35580 (Shell-Injection über workflow_dispatch-Eingaben in GitHub Actions) gegen einen festgepinnten Snapshot von NationalSecurityAgency/emissary
Automatisiertes Forschungsobjekt — nicht das Upstream-Projekt.
Dieses Repository ist ein Wegwerf-Labor, das von einer automatisierten Testumgebung für eine Masterarbeit an der Université Laval zur Reproduktion veröffentlichter GitHub-Actions-Workflow- Schwachstellen erstellt wurde. Es ist eine wörtliche Momentaufnahme von
NationalSecurityAgency/emissarybeim Commit898488b489615581ea66d17954742c8e4ffb0323(2026-01-09), weiterverteilt unter der eigenen Lizenz dieses Projekts, deren Datei unverändert in dieser Momentaufnahme enthalten ist.Das Upstream-Projekt ist nicht beteiligt, wird niemals angegriffen, und die hier untersuchte Schwachstelle ist bereits öffentlich. Jedes Secret und jede Variable in diesem Repository ist ein zufällig generierter Dummy-Wert — es sind keine echten Anmeldedaten vorhanden. Aktionsreferenzen und Runner-Images sind auf den Stand vom 2026-01-09 fixiert; siehe
pinning.mdin der Testumgebungs-Ausgabe für jede an der Momentaufnahme vorgenommene Änderung.Fragen oder Einwände: [email protected]

Emissary ist eine P2P-basierte, datengetriebene Workflow-Engine, die in einem heterogenen, möglicherweise weit verteilten, mehrstufigen P2P-Netzwerk aus Rechenressourcen läuft. Workflow- Itinerare werden nicht wie bei herkömmlichen Workflow-Engines vorab geplant, sondern entdeckt, während mehr Informationen über die Daten bekannt werden. In einem Emissary-Workflow gibt es typischerweise keine Benutzerinteraktion; vielmehr werden die Daten zielorientiert verarbeitet, bis sie einen Abschlusszustand erreichen.
Emissary ist hochgradig konfigurierbar, tut aber in dieser Basisimplementierung fast nichts. Benutzer dieses Frameworks sollen Klassen bereitstellen, die emissary.place.ServiceProviderPlace erweitern, um an emissary.core.IBaseDataObject-Nutzlasten zu arbeiten.
Es können verschiedene Dinge durchgeführt werden, und der Workflow wird in Stufen verwaltet, z. B. STUDY, ID, COORDINATE, TRANSFORM, ANALYZE, IO, REVIEW.
Die Klassen, die für die Steuerung des Workflows verantwortlich sind, sind die emissary.core.MobileAgent und daraus abgeleitete Klassen, die den Pfad einer Gruppe verwandter Nutzlastobjekte durch den Workflow verwalten, sowie der emissary.directory.DirectoryPlace, der die verfügbaren Dienste, deren Kosten und Qualität verwaltet und das P2P-Netzwerk verbunden hält.
Lies den Leitfaden DEVELOPING.md für Informationen zur Installation der erforderlichen Komponenten, zum Abrufen des Quellcodes, zum Erstellen und Ausführen von Emissary.
Führe mvn clean package aus, um Emissary zu kompilieren, zu testen und zu paketieren
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 9.132 s
[INFO] Finished at: 2022-01-10T22:31:05Z
[INFO] ------------------------------------------------------------------------
Es gibt ein Bash-Skript in Emissary, das alles ausführt. Es befindet sich im obersten Emissary-Verzeichnis. Das Skript führt die Klasse emissary.Emissary aus, die über mehrere Picocli- Befehle verfügt, um verschiedene Funktionen zu behandeln.
Wenn das emissary-Skript ohne Argumente ausgeführt wird, erhältst du eine Auflistung aller Konfigurations-Unterbefehle und eine kurze Beschreibung.
./emissary
Die Ausführung von ./emissary help liefert dieselbe Ausgabe wie die Ausführung ohne Argumente. Wenn du detailliertere
Informationen zu einem Befehl sehen möchtest, füge den Befehlsnamen nach help hinzu. Um beispielsweise alle
Argumente mit Beschreibungen für den Befehl server zu sehen, führe aus:
./emissary help server
Die übrigen Befehle haben alle Argumente (-b oder --projectBase), die gesetzt werden können, aber sie müssen mit PROJECT_BASE übereinstimmen.
Das Konfigurationsverzeichnis ist standardmäßig auf /config gesetzt, kann aber auch mit (-c oder --config) übergeben werden. Wenn du aus dem Git-Checkout heraus arbeitest, solltest du target als projectBase verwenden. Du kannst die Konfigurationsdateien in target/config gerne ändern, bevor du startest.
Die Protokollierung wird von logback übernommen. Du kannst mit dem Argument --logbackConfig auf eine benutzerdefinierte Datei verweisen.
Siehe help -c für jeden Befehl, um weitere Informationen zu erhalten.
Dieser Befehl startet einen Emissary-Server und initialisiert alle Places, einen Pickup-Place und Drop-off-Filter, die konfiguriert sind. Er startet im Standalone-Modus, wenn -m oder --mode nicht angegeben ist. Standardmäßig wird die Anzahl der MobileAgents basierend auf den Spezifikationen der Maschine berechnet. Auf modernen Computern kann dies hoch sein. Du kannst die Anzahl der Agents mit -a oder --agents steuern. Hier ist ein Beispiel für die Ausführung.
./emissary server -a 2