Megalodon a transformat GitHub Actions într-un backdoor pe 5.561 depozite

O campanie automatizată a împins 5.718 commit-uri în 5.561 de depozite GitHub în șase ore, într-o luni de mai. Commit-urile arătau ca o întreținere obișnuită de CI („ci: add build optimization step”, „build: improve ci performance”, „chore: optimize pipeline runtime”) și veneau de la autori cu nume banale: build-bot, auto-ci, pipeline-bot. Când dimineața de 18 mai s-a încheiat, fiecare dintre acele depozite avea un fișier de workflow cu un payload bash codificat în base64 înăuntru.

Campania se numește Megalodon. Echipa de cercetare de la SafeDep a dezvăluit-o pe 21 mai, după ce a descompus commit-urile și a urmărit traseul artefactelor până la un singur server de comandă și control la 216.126.225.129:8443. Partea interesantă nu e că GitHub a fost atacat. Partea interesantă e că atacatorul nu a avut nevoie să compromită GitHub. A folosit GitHub Actions, sistemul CI/CD proiectat tocmai pentru a garanta integritatea codului, ca vehicul de livrare pentru backdoor.

Două workflow-uri, unul de masă și unul adormit

Megalodon a funcționat în două moduri. Varianta de masă adăuga un fișier de workflow nou numit SysDiag care se declanșa la fiecare push și la fiecare pull request, capturând tot ce trecea prin el. Varianta țintită, Optimize-Build, a făcut ceva mai răbdător: a înlocuit un workflow existent cu un declanșator workflow_dispatch, care stă adormit până când cineva îl invocă manual. Un backdoor care doarme în directorul CI al unui proiect e mult mai greu de observat decât un workflow nou numit SysDiag, pentru că cei mai mulți menținători nu auditează un fișier pe care l-au scris ei înșiși.

Odată ce workflow-ul rulează, payload-ul citește tot ce poate atinge în mediul CI. Variabile de mediu CI. Chei de acces, chei secrete și token-uri de sesiune AWS. Token-uri de acces GCP. Chei SSH private. Credențiale .npmrc. Configurații Docker. Configurații Kubernetes. Token-uri OIDC de GitHub Actions, care permit atacatorului să se dea drept workflow-ul însuși în fața oricărui cont cloud pentru care fusese autorizat. Înainte de a ieși, payload-ul face grep prin codul sursă al depozitului după mai bine de treizeci de tipare de secrete distincte (chei de API, parole, fragmente de certificate) în caz că vreun om a lipit unul acolo. Endpoint-urile de metadate AWS IMDSv2, GCP și Azure sunt și ele interogate pentru a obține identitatea de mașină în cloud.

O pipeline care livrează propriul backdoor

Cea mai gravă victimă până acum este Tiledesk, o platformă open-source de relaționare cu clienții ale cărei nouă depozite GitHub au fost lovite. Între 19 și 21 mai, Tiledesk a publicat pachetul tiledesk-server pe npm cu backdoor-ul compilat înăuntru. Versiunile 2.18.6 până la 2.18.12 de @tiledesk/tiledesk-server poartă acum codul payload-ului, instalat de fiecare dezvoltator care a rulat npm install în acea fereastră. Aceasta este pârghia pentru care a fost construit Megalodon: să pună un backdoor într-un proiect open-source pentru ca pipeline-ul lui de release să pună backdoor-uri în sute de proiecte dependente.

Black-Iron-Project a pierdut opt depozite. Sute de proiecte mai mici (conturi de dezvoltatori individuali, clustere universitare, sandbox-uri abandonate) au primit unul sau două fiecare. Atacatorul nu părea să aleagă. Tiparul a fost acoperire largă: conturi de unică folosință cu nume aleatoare de opt caractere împingând mesaje de commit identice minut după minut. Serverul C2 înregistra în tăcere ce se întorcea.

De ce fișierele CI au supraviețuit auditului

Acest atac a funcționat din același motiv pentru care se va repeta în tot restul anului 2026. Pipeline-urile CI/CD se bazează pe încredere prin construcție. Un dezvoltator care suspectează un binar ciudat dintr-un download rulează fără să stea pe gânduri un fișier de workflow care i-a apărut în depozit săptămâna trecută, pentru că fișierele de workflow sunt exact asta: cod pe care platforma trebuie să-l ruleze. Log-urile de audit există, dar puține echipe le citesc. Commit-urile noi vin semnate cu nume ca build-bot și ci-bot. Diff-urile sunt mici. Șirul base64 de la sfârșitul workflow-ului e opac intenționat.

Manualul defensiv e simplu și nesatisfăcător. Rotează fiecare secret care a atins un depozit între 18 mai și astăzi. Auditează directorul .github/workflows al fiecărui proiect sub administrare. Inspectează commit-urile al căror email de autor nu se potrivește cu niciun membru cunoscut al echipei. Tratează orice blob base64 dintr-un fișier Actions ca vinovat până la decodare. Organizațiile care folosesc Tiledesk ar trebui să se întoarcă la 2.18.5 sau să aștepte un release curat. Oricine are încredere OIDC între Actions și un furnizor de cloud ar trebui să revoce și să reemita acea relație de încredere.

Megalodon este prima campanie la această scară care tratează workflow-ul CI însuși ca ținta moale. Nu va fi ultima. Lecția pe care o lasă atacul e una pe care dezvoltatorii o auziseră deja, mai în șoaptă: partea din pipeline pe care n-o citești e partea pe care atacatorul o scrie pentru tine.

Mai multe articole similare

Apple Fitness+ Revoluționează Fitness-ul în 2025 cu Noi Experiențe Captivante

Îmblânzirea conversațiilor de grup: Cum ne reproiectează WhatsApp viața socială digitală

O inteligență artificială a scris un exploit zero-day funcțional — Google l-a oprit la timp

O alianță strategică: ‘Talking Tom’ și ‘Miraculous’ lansează un crossover multi-platformă

DeepSeek V4 costă o cincime din GPT-5 şi rulează fără cipuri Nvidia

Drona autonomă cu Starlink care transformă dispeceratul de urgență într-o decizie algoritmică