Majoritatea articolelor despre securitate din acest newsletter se referă la lucruri care vi se întâmplă direct: un mesaj de phishing, o parolă divulgată, un site de cumpărături fals. Acesta este diferit. Incidentele de mai jos li s-au întâmplat dezvoltatorilor — oamenilor care scriu aplicațiile și serviciile pe care le folosiți în fiecare zi. Dar motivul pentru care își au locul aici este simplu: dacă cineva otrăvește instrumentele folosite pentru a construi software, otrava nu rămâne la constructor. Este livrată odată cu produsul.

Recent s-au întâmplat două lucruri care ilustrează acest aspect. Niciunul nu a ajuns în titlurile ziarelor așa cum ajunge o breșă majoră, pentru că niciunul nu este, în mod specific, o breșă care vă afectează pe voi. Ambele sunt atacuri asupra fluxului care produce software-ul pe care, în cele din urmă, îl instalați, îl deschideți sau în care vă autentificați.

Extensii contrafăcute deghizate în mărci de încredere

Open VSX este o piață publică pentru extensii ale editoarelor de cod — mici module suplimentare pe care dezvoltatorii le instalează pentru autocompletare, linting și integrări pentru instrumentele pe care le folosesc zilnic (Visual Studio Code și câteva dintre variantele sale open-source folosesc această platformă). Între 26 iulie și 1 august 2026, cercetătorii în securitate de la Manifold Security au găsit 77 de extensii contrafăcute în registru. Fiecare copia numele și spațiul de nume al unei extensii reale, de încredere, dar era publicată de un cont care nu deținea originalul — o tactică clasică de impersonare, numită uneori acapararea spațiului de nume.

Numele acaparate nu erau alese la întâmplare. Împrumutau identitățile AMD, LEGO Education, Hyperledger, Azure, Artsy, proiectelor open-source ale Salesforce, unei agenții federale din SUA și — într-o ironie sumbră — chiar pieței de extensii. Fiecare dintre cele 77 de pachete comunica cu un singur domeniu, înregistrat cu doar 11 zile înainte de apariția primului pachet fals, un tipar care sugerează o campanie coordonată și creată special în acest scop, nu o simplă copiere oportunistă.

Majoritatea extensiilor false făceau ceva modest: raportau discret un nume de gazdă către serverul atacatorului, ceea ce, în sine, poate fi doar o verificare pentru a vedea cine a instalat momeala. Dar cercetătorii au descoperit că aproximativ un sfert din cele 77 — 19 pachete — mergeau mai departe. La câteva secunde după activare, colectau numele de gazdă, numele de utilizator al sistemului de operare, detalii despre editor și un ID al mașinii. Apoi citeau orice proiect avea dezvoltatorul deschis: remote-ul git (care dezvăluie organizația și gazda depozitului), domeniul e-mailului din commit, ramura curentă și cel mai recent commit. De asemenea, extrăgeau valorile pentru integrarea continuă — acreditările și configurația care permit sistemelor automate să construiască și să implementeze cod fără ca un om să introducă de fiecare dată o parolă.

Niciuna dintre aceste date nu este utilă pentru a goli contul bancar al cuiva. Sunt utile pentru altceva: pentru a afla pentru ce companii lucrează un dezvoltator, cum arată infrastructura lor internă și cum se poate obține un punct de sprijin în aceasta.

O vulnerabilitate de 9,8 din 10 în mașina care construiește software-ul

Al doilea incident implică TeamCity, o platformă de integrare continuă și livrare continuă (CI/CD) creată de JetBrains. Dacă un editor de cod este locul în care dezvoltatorii scriu software, o platformă CI/CD este hala automatizată a fabricii în care acel cod este compilat, testat și trimis în producție — adesea fără ca vreun om să apese măcar pe „deploy”. TeamCity este o piesă centrală a acestui mecanism în multe companii.

O vulnerabilitate urmărită ca CVE-2026-63077, cu un scor de severitate de 9,8 dintr-un maxim de 10, a fost dezvăluită în versiunile on-premises ale TeamCity. Este o deficiență de deserializare — o categorie de vulnerabilitate în care un program are suficientă încredere în datele primite încât să le transforme direct în cod executabil, fără să verifice mai întâi ce sunt de fapt acele date. În practică, aceasta îi permitea unui atacator să trimită o cerere către un server TeamCity vulnerabil, fără să fie necesară autentificarea, și să ruleze comenzi arbitrare cu aceleași privilegii ca serviciul TeamCity însuși. JetBrains a lansat patch-uri (versiunile 2025.11.7 și 2026.1.3, plus un plugin de patch pentru instalările mai vechi, 2017.1+), dar Agenția pentru Securitate Cibernetică și Infrastructură a SUA (CISA) a avertizat între timp că atacatorii exploatează activ sistemele neactualizate.

Cine controlează serverul de build al unei companii controlează ceea ce livrează compania respectivă. Nu este o ipoteză — aceasta este funcția literală a instrumentului.

Același plan de atac, două uși diferite

Acestea sunt incidente fără legătură între ele, investigate de cercetători diferiți, dar au aceeași structură. Niciunul nu atacă un produs finit. Ambele atacă o etapă anterioară — editorul în care un dezvoltator scrie cod sau serverul care transformă acel cod într-o versiune livrată. Aceasta este trăsătura definitorie a unui atac asupra lanțului de aprovizionare software: în loc să pătrunzi într-o singură țintă, compromiți ceva din amonte, de care depind multe ținte, și lași propriul lor proces de încredere să-ți ducă accesul mai departe.

Merită să fim sinceri în privința lucrurilor pe care încă nu le știm. Niciunul dintre rapoartele apărute în această săptămână nu a dezvăluit un caz confirmat în care o aplicație sau un utilizator din aval să fi fost compromis ca rezultat direct — campania cu extensii pare să fi urmărit recunoașterea și colectarea accesului, iar exploatarea TeamCity este descrisă ca fiind activă, dar fără victime identificate nominal. Acest lucru este normal; compromiterile lanțului de aprovizionare sunt adesea descoperite la punctul de intrare cu mult timp înainte ca eventualul câștig să fie urmărit până la capăt (sau fără ca acesta să fie urmărit vreodată).

De ce este problema voastră, nu doar a lor

Probabil că nu veți instala niciodată o extensie de programare și nu veți rula un server CI/CD. Dar folosiți rezultatul a sute de astfel de sisteme: aplicația bancară, managerul de parole, portalul școlii copilului, browserul în care citiți acest text. Toate au trecut prin editorul unui dezvoltator și prin fluxul de build al unei companii înainte să ajungă pe telefonul vostru. Dacă oricare dintre aceste verigi este compromisă discret, modificarea malițioasă poate fi transportată odată cu o actualizare obișnuită, de rutină — genul pe care îl instalați pentru că vi s-a spus că actualizarea este lucrul sigur de făcut.

Acesta este și motivul pentru care recomandările dintr-un raport post-incident despre o breșă par uneori ciudate pentru cititorii netehnici: o companie spune că sistemele sale au fost compromise prin intermediul unui server de build, al unei acreditări de dezvoltator furate sau al unei dependențe malițioase, iar acest lucru poate părea abstract în comparație cu „cineva mi-a ghicit parola”. Nu este abstract. Este același rezultat — datele voastre sau integritatea aplicației voastre compromise — obținut printr-o ușă despre a cărei existență nu știați.

Ce ajută cu adevărat

Nu puteți audita fluxul CI/CD al băncii voastre și nici nu ar trebui să fie nevoie să o faceți. Dar câteva obiceiuri vă reduc cu adevărat expunerea la această categorie de risc:

Păstrați actualizările automate activate, dar nu considerați actualizările automat de încredere. Patch-urile sunt modul în care remedieri precum cea pentru TeamCity de mai sus ajung în software-ul pe care îl rulați — menținerea la zi închide ferestrele pe care atacatorii le verifică activ. În același timp, o actualizare este la fel de bună ca fluxul care a produs-o, exact lucrul vizat aici; nu există o apărare individuală perfectă împotriva unei versiuni din amonte otrăvite cu adevărat, motiv pentru care aceasta este în esență o problemă de responsabilitate a furnizorului, nu o problemă a voastră.

Dacă lucrați cu dezvoltatori sau îi coordonați, iată două lucruri concrete și verificabile: verificați ca orice extensie de editor de cod să fie instalată de la contul real al editorului verificat, nu doar să aibă un nume identic (Open VSX și piețele similare afișează identitatea editorului — verificați-o, nu vă bazați doar pe pictogramă și titlu); iar dacă organizația voastră rulează TeamCity on-premises, confirmați chiar astăzi că folosește versiunea 2025.11.7, 2026.1.3 sau că are aplicat pluginul de patch, nu așteptați următoarea fereastră de mentenanță — avertismentul CISA înseamnă că vulnerabilitatea este exploatată activ, nu că este doar teoretică.

Pentru toți ceilalți, schimbarea utilă este pur și simplu conștientizarea: când citiți despre o breșă a unei companii care duce înapoi la „un instrument de dezvoltare compromis” sau la „un sistem de build”, aceasta nu este o notă tehnică de nișă. Este aceeași categorie de eveniment ca breșele de parole și escrocheriile de phishing despre care acest newsletter vorbește mai des — doar că a început cu un nivel mai sus în amonte, înainte ca produsul să ajungă vreodată la voi.