Nach Darstellung von Xygeni wurde die Folgeaktivität am 9. März aufgrund von Hinweisen aus der Community erkannt; der manipulierte Tag wurde im Rahmen der laufenden Incident-Response entfernt. Das Unternehmen betont, es sei kein Schadcode in den Hauptzweig des Repositorys eingeflossen, es gebe keine Hinweise auf eine Kompromittierung der Xygeni-Plattform oder von Kundendaten, und der betroffene Tag sei dauerhaft gelöscht worden.
Als Ursache benennt Xygeni die Kompromittierung des privaten Schlüssels einer GitHub-App, die im Repository installiert war und über unnötig weitreichende Berechtigungen verfügte. Der Angreifer kombinierte den persönlichen Zugangstoken (PAT) eines Maintainers mit den Anmeldedaten der GitHub-App: das eine, um Pull Requests zu erstellen, das andere, um sie zu genehmigen — keines der beiden hätte für sich allein die Schutzmechanismen des Repositorys umgehen können. Wie der private Schlüssel abgezogen wurde, ist laut Xygeni noch in Untersuchung; solche .pem-Dateien könnten etwa über fehlkonfigurierte Workflows, kompromittierte Entwicklerrechner oder unsichere Secret-Speicherung abfließen.
Für die Zukunft kündigte Xygeni an, Release-Immutabilität in den Repositories durchzusetzen, Berechtigungen und Mitwirkendenzugänge zu härten, kryptografisch signierte Commits für Maintainer verpflichtend zu machen und Schreibzugriff auf wenige Maintainer und Administratoren zu beschränken. Kunden sollten ihre Workflows auf den sicheren Commit-SHA festlegen, CI-Logs prüfen und Secrets rotieren, die während des Kompromittierungszeitraums den CI-Runnern ausgesetzt waren.
Einer der ersten öffentlichen Hinweise stammte vom 9. März aus einem Blogbeitrag von Varun Sharma, CEO und Mitgründer von StepSecurity. Demnach schleuste ein Angreifer mit Zugriff auf Maintainer-Konten und einen GitHub-App-Token eine vollständige C2-Reverse-Shell in xygeni/xygeni-action ein, getarnt als Schritt zur “Telemetrie der Scanner-Version”. Drei Pull Requests mit dem Schadcode seien geöffnet und ohne Merge wieder geschlossen worden, doch der Angreifer habe zusätzlich den v5-Tag auf den manipulierten Commit verschoben. Sieben Tage lang — vom 3. bis 10. März — habe jeder, der xygeni/xygeni-action@v5 referenzierte, ein C2-Implantat ausgeführt.
Der eigentliche Angriff war laut Sharma der v5-Tag, den jeder mit Schreibzugriff auf einen beliebigen Commit zeigen lassen konnte. Das Schließen der Pull Requests und das Löschen der Workflows habe den aktiven Vorfall nicht gestoppt, da der Tag das gesamte Auslieferungsmittel gewesen sei. Jeder Workflow-Lauf mit @v5 in diesem Zeitraum habe dem Angreifer ein dreiminütiges Fenster für beliebige Befehlsausführung auf dem CI-Runner verschafft — mit Zugriff auf GITHUB_TOKEN, Repository-Secrets und Quellcode. Sharma zufolge enthielt die erste Korrektur vom 9. März noch den v5-Tag; behoben wurde dies erst am 10. März, nachdem StepSecurity das Problem gemeldet hatte.
Xygeni widerspricht einzelnen Punkten der StepSecurity-Analyse, darunter dem Zeitpunkt der Tag-Manipulation. StepSecurity datiert die Verschiebung auf etwa 10:49 UTC am 3. März, unmittelbar nach dem Schließen der Pull Requests. Diese Zeitangabe konnte Xygeni nicht bestätigen, da Force-Push-Ereignisse auf Tags nicht im Aktivitätsprotokoll von GitHub erfasst werden; gesichert sei nur, dass der Tag nach Erstellung des bösartigen Commits und vor der Entdeckung am 9. März vergiftet wurde.