Twee coole GitHub-acties zijn voor de tweede keer uitgeschakeld nadat de repositories vorige week toegankelijk werden, maanden nadat ze werden gecompromitteerd tijdens de Mini Shai-Hulud-campagne van mei 2026.
De getroffen GitHub-acties worden hieronder vermeld:
Als u een van de repository’s bezoekt, wordt nu het bericht weergegeven: “Toegang tot deze repository is uitgeschakeld door GitHub-personeel vanwege een schending van de servicevoorwaarden van GitHub. Als u de eigenaar van de repository bent, kunt u contact opnemen met GitHub Support voor meer informatie.”
“Op 16 september 2026 werden beide repository’s weer toegankelijk”, zegt Socket-onderzoeker Karlo Zanki. “Hun releasetags zijn niet eerst opgeschoond. Ze verwijzen nog steeds naar de kwaadaardige inhoud die op 18 mei is geïntroduceerd, dus elke workflow die naar een actie verwijst via een versietag, hervat het downloaden en uitvoeren van de payload bij de volgende run.”
De twee GitHub Actions-workflows werden oorspronkelijk op 18 mei 2026 gecompromitteerd om kwaadaardige code uit te voeren die gevoelige inloggegevens verzamelde van CI/CD-pijplijnen die ze uitvoerden en de details naar een door de aanvaller bestuurde server exfiltreerde.
De activiteit werd vervolgens gekoppeld aan het Mini Shai-Hulud-activiteitencluster, waarbij overlappingen werden aangehaald in het exfiltratiedomein (“tm-kosche(.)com”) dat werd gebruikt in de GitHub Actions-workflows en de npm-pakketten van het @antv-ecosysteem.
“Dat wijst op hetzelfde Mini Shai-Hulud-activiteitencluster, en niet op een afzonderlijk NPM-incident”, vertelde Philipp Burckhardt, hoofd van de dreigingsinformatie bij Socket, destijds aan The Hacker News.
De opslagplaatsen werden opnieuw ingeschakeld op 16 september 2026, ergens tussen 11:09 uur en 18:16 uur GMT+2. Het is momenteel niet bekend waarom dit gebeurde.
Maar de laatste ontwikkeling wijst op een ander probleem: de kwaadaardige code bleef in de getroffen codebases staan en werd nooit opgeschoond, en het enige dat nodig was om de dreiging te activeren was dat de repository’s weer konden worden gedownload.
Gezien het feit dat er nog steeds verschillende workflows zijn die gebruik maken van de twee GitHub-acties, had de blootstelling kunnen leiden tot ernstige beveiligingsrisico’s voor de softwaretoeleveringsketen zonder dat de bedreigingsactoren een nieuwe exploit hoefden te gebruiken of een nieuwe infrastructuur moesten opzetten.
“Beide acties automatiseren het bijhouden van problemen en opmerkingen, zoals het sluiten van inactieve problemen, het controleren van nieuw geopende problemen of het up-to-date houden van een enkele botcommentaar”, aldus Socket.
“De workflows die ze aanroepen, draaien meestal volgens een dagelijks schema of wanneer iemand een issue of pull-request opent. In de praktijk draaiden de meeste getroffen repository’s de payload waarschijnlijk binnen een dag na het opnieuw inschakelen, zonder dat er verdere actie nodig was van de bedreigingsacteur.”
Het probleem heeft geen invloed op workflows die een van beide acties vastpinnen op de volledige commit SHA van een versie van vóór 18 mei 2026. Ontwikkelaars wordt aangeraden de volgende stappen uit te voeren:
- Zoek elke verwijzing naar de betreffende acties en behandel “actions-cool/[email protected]” als getroffen.
- Verwijder de acties en zet ze vast op een bekende schone SHA die dateert van vóór 18 mei 2026.
- Roteer alle blootgestelde geheimen.
- Bekijk de workflow-uitvoeringsgeschiedenis en controleer op nieuwe succesvolle uitvoeringen na een lange periode van mislukte taakinstellingen.
- Controleer de geschiedenis van de opslagplaats op onverwachte commits na 16 september 2026.
“Bij de meeste supply chain-incidenten gaat het om iets nieuws: een nieuw gepubliceerde kwaadaardige versie, een nieuw gekaapt account of een nieuw geïnjecteerde workflow”, aldus Zanki. “Deze niet. Er is geen nieuwe code gepubliceerd en er is geen configuratie gewijzigd.”
“Dit incident laat zien dat een veranderlijke tag kan worden aangetast, ingeperkt en vervolgens opnieuw kan worden geactiveerd zonder enige wijziging in uw eigen workflowbestand. SHA-pinning neemt die afhankelijkheid van de status van de upstream-repository weg.”
