Wiki-ul ține credențiale de identitate

Un scaner automat care se uită la CVE-2026-21589 raportează o citire arbitrară de fișier. Neautentificată, da, dar o citire: fără scriere, fără execuție, fără persistență. Într-un flux obișnuit de gestionare a vulnerabilităților, aceasta este o divulgare de informații cu severitate medie, programată în ciclul următor.

Atlassian i-a dat CVSS 9.3. Cercetătorii de la watchTowr, care au găsit cauza, au arătat de ce, iar demonstrația are trei pași:

1. Citești WEB-INF/classes/crowd.properties de pe o instanță afectată, fără autentificare
2. Folosești credențialele din acel fișier ca să te autentifici în Atlassian Crowd, produsul de identitate care stă în fața autentificărilor pentru Jira, Confluence și restul
3. Creezi un utilizator și îl adaugi în grupul jira-administrators

Clasa de vulnerabilitate nu s-a schimbat niciodată. S-a schimbat ce putea atinge fișierul.

Unde greșesc inventarele de active

Cele mai multe inventare clasifică după ce este un lucru. Un server, o bază de date, o aplicație. Apoi criticitatea se atribuie după ce face acel lucru pentru business: producție sau non-producție, expus clienților sau intern, generator de venit sau de suport.

În schema asta, Confluence, Jira și Bitbucket ajung într-un loc previzibil. Sunt unelte de productivitate. Software de colaborare. Wiki-ul. Se actualizează pe ciclul general, nu pe cel urgent, sunt frecvent în afara scopului testelor de penetrare care se concentrează pe „producție" și sunt adesea excluse din scanarea externă pe motiv că sunt interne — exact până când verifică cineva și găsește instanța de Confluence pe care o echipă de proiect a publicat-o în 2022 ca să poată ajunge la ea un colaborator extern.

Cazul Atlassian sparge curat schema. Wiki-ul nu a fost niciodată ținta. A fost o cale de citire către sistemul de identitate, iar sistemul de identitate este cel în care au încredere toate celelalte.

Clasifică după ce poate atinge

Întrebarea mai utilă nu este „ce este sistemul acesta", ci „ce ține sau ce atinge sistemul acesta și în ce are încredere altceva?"

Pune întrebarea pe un parc tipic de sisteme și notele de criticitate se mișcă incomod:

• Wiki-ul ține diagrame de arhitectură, proceduri de operare și — în practică, orice ar spune politica — credențiale lipite în pagini de oameni grăbiți
• Sistemul de ticketing ține istoricul fiecărei constatări de securitate pe care ai ridicat-o și nu ai rezolvat-o încă, cu destule detalii ca să fie reprodusă
• Platforma de CI/CD ține credențiale de deployment pentru producție și poate împinge cod în ea
• Serverul de monitorizare, prin construcție, ajunge în fiecare segment de rețea pe care îl monitorizează
• Consola de backup poate șterge fiecare copie a datelor tale, exact de aceea operatorii de ransomware merg acolo primii
• Platforma de identitate este cea în care se autentifică toate cele de mai sus

Niciunul nu este „producție" în sensul pe care îl au în vedere majoritatea inventarelor. Toate ajung în producție.

Ce așteaptă de fapt NIS 2

Articolul 21 din NIS 2, transpus în România prin OUG nr. 155/2024, cere politici de analiză a riscului și de securitate a sistemelor informatice, iar gestionarea activelor este locul de unde începe asta în orice implementare serioasă. Directiva nu îți dă o schemă de clasificare. Cere ca măsurile să fie proporționale cu riscul — ceea ce este o instrucțiune să înțelegi mai întâi riscul.

Un inventar care atribuie criticitatea după eticheta de business, nu după ce poate atinge fiecare sistem, nu este proporțional cu nimic. Este proporțional cu organigrama.

Două consecințe practice pentru o evaluare:

• Termenele de patching ar trebui determinate de ce atinge sistemul, nu de categoria lui. Un server de monitorizare sau o platformă de identitate merită aceeași urgență ca o aplicație expusă clienților, pentru că prin compromiterea lor ajungi oricum la aplicația expusă clienților.
• Scopul testării ar trebui să urmeze aceeași logică. Dacă ultimul test de penetrare a acoperit site-ul public și fluxul de plată, dar nu serverul Git găzduit intern sau wiki-ul, scopul a fost stabilit după ce este organizația mândră, nu după ce ar alege un atacator.

Pasul la care se oprește un scaner

Aceasta este diferența care merită înțeleasă și nu este un argument de marketing — este o descriere a ce poate stabili fiecare dintre cele două activități.

O scanare automată identifică citirea de fișier. Poate confirma că instanța este vulnerabilă și, într-o configurație bună, îți va spune versiunea afectată și corecția. Ce nu poate face este să știe că crowd.properties există pe deployment-ul tău anume, că acele credențiale sunt valide, că serverul Crowd este accesibil din locul unde se află acum atacatorul și că acel cont poate fi escaladat în jira-administrators.

Lanțul are patru pași condiționali, fiecare depinzând de configurația ta specifică. Un scaner raportează pasul unu ca severitate medie și se oprește, corect, pentru că nu poate încerca restul în siguranță.

Un tester încearcă restul, iar așa o severitate medie devine o constatare care spune „un utilizator neautentificat din internet poate obține acces administrativ la sistemul care ține istoricul vostru de inginerie". Este aceeași vulnerabilitate cu consecințe diferite atașate, iar doar una dintre ele ajunge să fie prioritizată corect.

Merită notat și controlul care reiese din același lanț: restricționarea pe adrese IP în Crowd îl rupe. Dacă serverul Crowd acceptă conexiuni de aplicație doar de la adrese cunoscute, credențialele furate nu funcționează din poziția atacatorului. Este un control la care nimeni nu s-ar gândi să îl verifice pornind doar de la descrierea vulnerabilității.

Ce faci luna aceasta

Este un exercițiu de documentare înainte să fie unul tehnic.

• Ia inventarul de active și adaugă o coloană: ce credențiale ține sistemul acesta și în ce se autentifică? Completeaz-o pentru cele douăzeci de sisteme care contează cel mai mult.
• Găsește sistemele în care au încredere alte sisteme — platforma de identitate, serverul de monitorizare, platforma de CI/CD, consola de backup, seiful de secrete — și verifică dacă nota lor de criticitate reflectă asta.
• Verifică dacă vreunul dintre ele este accesibil din internet. Nu dacă ar trebui să fie. Dacă răspunde.
• Compară scopul ultimului test de penetrare cu lista aceea și notează ce a fost exclus și de ce.
• Pentru cazul Atlassian în particular: actualizează la versiunile corectate, iar dacă crowd.properties ar fi putut fi citit, rotește credențialele de aplicație pentru Crowd și verifică eventualele conturi create sau promovate de la începutul lui octombrie.

Unde problema este chiar inventarul — unde nimeni nu este sigur ce publică organizația — o evaluare a suprafeței externe de atac construiește lista din exterior, cu aceeași metodă și din același punct de plecare ca un atacator. Un test de penetrare intern răspunde direct la întrebarea despre ce se poate atinge: pornind de la o stație compromisă sau de la un cont de serviciu cu prea multe drepturi, unde se ajunge efectiv. Iar unde decalajul este între ce spune politica și ce acceptă un evaluator drept dovadă, un audit de conformitate sub NIS 2 acoperă terenul.

Lecția de dedesubt este mai veche decât acest CVE. Atacatorii nu navighează organigrama. Urmăresc relațiile de încredere, iar relațiile de încredere rareori se potrivesc cu etichetele din inventar.

Surse: Avertizarea de securitate Atlassian pentru CVE-2026-21589 · Analiza rapidă watchTowr · The Hacker News, 7 octombrie 2026

Lanțul de escaladare descris mai sus este demonstrația watchTowr, relatată prin presa de securitate; nu l-am reprodus. Necesită un deployment integrat cu Crowd și acces de rețea la serverul Crowd, iar restricționarea pe adrese IP în Crowd îl anulează. Atlassian a descoperit singură vulnerabilitatea și nu a confirmat exploatarea instanțelor Data Center.

Acest articol conține informații cu caracter general, nu consultanță juridică sau de reglementare.