Legea 123/2026: Cum poți ajunge infractor cibernetic de bună-credință 7/07/2026

Înainte de a începe, vreau să subliniez că orice cadru legal care protejează cercetătorii în securitate cibernetică de bună-credință este necesar și binevenit, iar acest articol nu este un atac împotriva Legii 123/2026. Ce m-a motivat să scriu despre acest subiect este modul în care legea este promovată public, creând falsa impresie că orice persoană cu abilități în cybersecurity, fie ele reduse sau avansate, este automat protejată atunci când identifică sau raportează o vulnerabilitate din infrastructura românească. În realitate, dacă nu acorzi o atenție extrem de mare modificărilor reale aduse de această lege, care avantajează foarte puțin procesul de validare tehnică a unei vulnerabilități, riști să ajungi exact în zona paradoxală despre care vorbesc în acest articol: un infractor cibernetic de bună-credință.

Legea nouă nu transformă infrastructura IT din România într-un program național de bug bounty, nu înlocuiește o autorizație pentru audit de securitate și, sincer, nici nu ar trebui să facă asta, pentru că ar putea fi abuzată de cei cu intenții rele. Dacă ești un entuziast aflat la început de drum, student, junior, adolescent sau autodidact, și vrei să ajuți ori să-ți construiești un portofoliu, oprește-te înainte de primul test și înțelege exact ce ai voie, ce nu ai voie și cât de repede se poate transforma o intenție de bună-credință într-o problemă penală. De aceea, îți recomand să citești acest articol până la final. În următoarele paragrafe voi explica, pe înțelesul tuturor, riscurile create de această împachetare publică mult prea pompoasă a legii.

Analiza Legii 123/2026: ce introduce art. 365¹ în Codul penal

Art. 365¹: Cauză de înlăturare a caracterului penal

Faptele prevăzute la art. 360 alin. (1) și (3), art. 361 și art. 364 nu constituie infracțiune atunci când sunt săvârșite de o persoană fizică sau juridică, dacă sunt îndeplinite cumulativ condițiile privind cercetarea și raportarea vulnerabilităților unor produse sau servicii ale tehnologiei informațiilor și comunicațiilor prevăzute la art. 36 alin. (5) și (6) din Ordonanța de urgență a Guvernului nr. 155/2024.

În primul rând, art. 365¹ nu rescrie legislația informatică și nu creează o protecție generală pentru „hackerii etici”. El face ceva mult mai limitat: spune că anumite fapte nu constituie infracțiune doar dacă sunt îndeplinite cumulativ condițiile din OUG 155/2024. Mai exact, art. 365¹ trimite strict la art. 360 alin. (1) și (3), art. 361 și art. 364 din Codul penal, iar protecția este condiționată de art. 36 alin. (5) și (6) din OUG 155/2024.

1. Art. 360 alin. (1): accesul, fără drept, la un sistem informatic.
2. Art. 360 alin. (3): accesul, fără drept, la un sistem informatic unde accesul este restricționat sau interzis pentru anumite categorii de utilizatori.
3. Art. 361: interceptarea, fără drept, a unei transmisii de date informatice care nu este publică.
4. Art. 364: transferul neautorizat de date dintr-un sistem informatic sau dintr-un mijloc de stocare a datelor informatice.
5. Art. 36 alin. (5) OUG 155/2024: condițiile pe care trebuie să le respecte persoana care cercetează și raportează vulnerabilitatea.
6. Art. 36 alin. (6) OUG 155/2024: obligația ca raportarea să fie făcută în cel mult 48 de ore de la identificarea vulnerabilității.

Asta înseamnă că art. 365¹ nu acoperă întregul capitol al infracțiunilor informatice. Din protecția lui rămân în afară art. 360 alin. (2), art. 362, art. 363 și art. 365. În plus, tentativa, prevăzută la art. 366, nu este menționată expres. Diferența este esențială, pentru că exact în aceste zone pot apărea multe dintre scenariile reale de validare tehnică a unei vulnerabilități.

1. Art. 360 alin. (2): accesul, fără drept, la un sistem informatic, atunci când fapta este făcută în scopul obținerii de date informatice.
2. Art. 362: modificarea, ștergerea sau deteriorarea datelor informatice, ori restricționarea accesului la aceste date, fără drept.
3. Art. 363: perturbarea gravă, fără drept, a funcționării unui sistem informatic, prin introducerea, transmiterea, modificarea, ștergerea sau deteriorarea datelor informatice ori prin restricționarea accesului la aceste date.
4. Art. 365: producerea, vânzarea, importul, distribuirea sau punerea la dispoziție, fără drept, a unor dispozitive, programe informatice, parole, coduri de acces sau date informatice destinate să permită accesul la un sistem informatic ori săvârșirea unor infracțiuni informatice.
5. Art. 366: tentativa la infracțiunile informatice din acest capitol; acest articol nu este menționat expres în noul art. 365¹.

Cu alte cuvinte, dacă în procesul de „verificare” ajungi să obții, chiar și involuntar, date care nu îți aparțin, să modifici ceva, să afectezi funcționarea sistemului, să folosești agenți AI, tool-uri automatizate sau payload-uri sensibile, poți ieși foarte repede din zona protejată de noua lege. Înțeleg de ce aceste articole au fost lăsate în afară: sunt zone sensibile, cu risc real de abuz. Totuși, tocmai de aceea erau necesare clarificări suplimentare pentru situațiile în care buna-credință atinge limitele legii în timpul validării tehnice a unei vulnerabilități.

Exemple reale: cum poți ajunge să comiți o infracțiune fără să-ți dai seama

Pentru ca exemplele următoare să scoată în evidență riscurile reale, am ales scenarii care îndeplinesc câteva criterii simple:

- Sunt vulnerabilități de actualitate, des întâlnite în aplicații, servere sau infrastructuri configurate greșit.
- Nu necesită cunoștințe avansate, deci pot fi identificate și de un adolescent, student, junior sau autodidact aflat la început de drum.
- Pot fi descoperite manual, prin tool-uri automate folosite în audituri de securitate sau prin sugestii generate de AI.
- Devin periculoase în etapa de validare, atunci când încerci să demonstrezi că problema este reală și nu doar un fals-pozitiv.
- Depășesc simpla observație: accesarea unor date, descărcarea unor fișiere, rularea unor payload-uri sau modificarea accidentală a unui sistem.

1. Vulnerabilitate de tip: Old Backup and Unreferenced Files

Această vulnerabilitate apare în etapa de culegere a informațiilor, când prin enumerare identifici fișiere sau directoare uitate pe server, neindexate ori expuse accidental prin erori de configurare. În urma scanării, descoperi un director neindexat la adresa example.ro/BugsBunny, unde se află două arhive ZIP cu nume complet aleatorii, fără niciun indiciu despre conținutul lor.

Tentația este să descarci acele arhive, pentru că într-un audit de securitate sau într-un program de bug bounty ai vrea să verifici dacă este o vulnerabilitate cu impact critic sau doar una informațională. Riscul apare dacă acestea conțin backup-uri de baze de date, cod sursă, credențiale, token-uri, chei API sau date despre utilizatori. În acel moment, simpla descărcare poate intra în zona art. 360 alin. (2), acces în scopul obținerii de date informatice, și/sau art. 364, transfer neautorizat de date informatice. În plus, poți pierde protecția din art. 36 alin. (5) lit. b) OUG 155/2024, care cere ca activitatea de cercetare să se desfășoare fără accesarea sau copierea neautorizată a conținutului fișierelor.

Dacă sunt doar poze cu Bugs Bunny, este o descoperire informațională. Dacă sunt date sensibile, ești deja în afara zonei protejate de lege și te poți expune unei încadrări penale care ajunge până la 5 ani de închisoare: art. 360 alin. (2), de la 6 luni la 5 ani, și/sau art. 364, de la 1 la 5 ani.

2. Vulnerabilitate de tip: IDOR - Insecure Direct Object Reference

Această vulnerabilitate apare atunci când aplicația folosește un identificator direct pentru o resursă, cum ar fi o factură, comandă, document, profil sau fișier, dar serverul nu verifică dacă utilizatorul autentificat are dreptul să o acceseze. Identificatorul poate fi într-un URL, parametru, cookie sau request HTTP. În unele cazuri, nici nu ai nevoie de cunoștințe tehnice: poți modifica o valoare, primi accidental un link de la alt utilizator sau accesa o adresă care nu îți aparține. Dacă serverul îți returnează acea resursă, vulnerabilitatea este confirmată, dar accesul la datele altcuiva este deja consumat.

Să presupunem că ești pe website-ul unui furnizor de utilități, energie, gaze, internet sau orice serviciu unde utilizatorii își pot vedea facturile online. Ai propria factură la adresa example.ro/invoice/1234. Dacă modifici manual 1234 în 1235, iar aplicația este vulnerabilă la IDOR, poți ajunge să vezi factura altui client. La fel, dacă primești accidental de la un prieten linkul example.ro/invoice/2555 și îl poți accesa din contul tău, vulnerabilitatea este deja confirmată.

Un singur request poate părea accidental sau poate fi confundat în log-uri cu accesul clientului legitim de pe un alt IP. Dar când automatizezi testul cu un tool precum Burp Suite și generezi sute sau mii de request-uri către facturi care nu îți aparțin, comportamentul nu mai arată ca o greșeală, ci ca o enumerare intenționată de date.

Dacă acele request-uri returnează facturi, date personale sau documente ale altor utilizatori, poți intra în zona art. 360 alin. (2), acces în scopul obținerii de date informatice, și/sau art. 364, transfer neautorizat de date informatice.

3. Vulnerabilitate de tip: Stored XSS

Această vulnerabilitate poate fi extrem de riscantă pentru începători, mai ales după ce au citit câteva tutoriale, au urmărit video-uri de bug bounty pe YouTube sau au descărcat liste cu vectori de testare pentru XSS persistent. Fără să înțeleagă exact ce face acel cod și fără să aibă încă suficientă experiență pentru a anticipa un astfel de scenariu, tentația este simplă: copy/paste în orice câmp care acceptă input de la utilizator.

Să presupunem că ești pe portalul unei instituții publice, la adresa example.ro/cerere-formular/, unde există mai multe câmpuri pentru completarea și trimiterea unei cereri. Câmpul title este vulnerabil, iar valoarea introdusă de tine este salvată și afișată ulterior în backend, acolo unde angajații instituției văd lista tuturor cererilor primite.

Dacă acel input nu este sanitizat corect, un simplu test copiat dintr-un tutorial poate altera pagina din backend. În loc ca angajatul să vadă normal lista de cereri, pagina poate deveni greu de folosit sau complet nenavigabilă până când cineva din departamentul IT identifică și șterge conținutul problematic. În practică, asta poate însemna indisponibilitatea acelui serviciu pentru ore întregi.

Aici apare riscul: nu mai vorbim doar despre „am vrut să verific dacă există XSS”. Vorbim despre conținut introdus și salvat într-un sistem real, care poate afecta interfața folosită de angajați și disponibilitatea unui serviciu. Într-un astfel de scenariu, poți intra în zona art. 362, modificarea datelor informatice, și chiar art. 363, perturbarea funcționării sistemelor informatice. Aceste articole nu sunt acoperite de art. 365¹.

Dacă testezi într-un mediu autorizat sau într-un program de bug bounty cu scope clar, este o verificare normală. Dacă faci copy/paste într-un portal real, fără autorizație, iar pagina din backend devine inutilizabilă pentru angajați, te poți expune unei încadrări penale care ajunge până la 7 ani de închisoare: art. 362, de la 1 la 5 ani, și/sau art. 363, de la 2 la 7 ani.

4. Vulnerabilitate de tip: Arbitrary / Unrestricted File Upload

Această vulnerabilitate apare atunci când o aplicație permite încărcarea de fișiere fără validări corecte privind extensia, tipul real al fișierului și modul în care fișierul poate fi accesat sau executat ulterior. Este întâlnită în formulare unde utilizatorii pot încărca imagini, PDF-uri, arhive, documente sau atașamente.

Pentru un începător, primul test pare simplu: verifică dacă poate face bypass la restricțiile de extensie. Dacă formularul ar trebui să accepte doar imagini sau PDF-uri, tentația este să încerce încărcarea unui fișier SVG sau PHP, pentru a demonstra existența unei vulnerabilități de tip Arbitrary File Upload. Problema apare când vrea să vadă dacă vulnerabilitatea are impact critic și ajunge să testeze scenarii de Remote Code Execution sau XXE, verificări întâlnite în multe metodologii publice de penetration testing. Diferența este că, fără autorizație, aceleași verificări pot ieși foarte repede din zona protejată de lege.

De exemplu, poți reuși să urci un fișier PHP într-un director accesibil public, dar asta nu înseamnă automat că ai RCE. Următorul pas, văzut des în tutoriale publice, este să verifici dacă serverul interpretează fișierul și dacă funcții precum system, exec, eval sau altele similare sunt permise.

Dacă fișierul urcat conține, de exemplu, o linie de tipul <?php system($_GET['tralala']); ?>, iar serverul îl interpretează ca PHP, comanda poate fi transmisă prin URL. În loc de un test banal, un începător poate încerca rapid comenzi de tipul cat /etc/passwd sau cat ../config.php, exact cum vede în tutoriale publice.

În acel moment, nu mai demonstrezi doar un upload greșit sau posibilitatea de RCE. Poți ajunge să citești fișiere locale, date de configurare, parole, token-uri sau alte informații confidențiale, iar fișierul urcat poate fi interpretat ca backdoor, adică mecanism de acces ulterior la server. În log-uri sau într-o analiză forensic, comportamentul nu mai arată ca o verificare de securitate, ci ca o tentativă de compromitere.

Dacă faci un astfel de test pe un portal real, fără autorizație, și ajungi să încarci un fișier PHP executabil sau un webshell, nu mai vorbim despre o simplă verificare de securitate. Poți ieși complet din zona protejată de art. 365¹ și te poți expune la încadrări precum art. 360 alin. (2), art. 362, art. 363, art. 364 și art. 365.

5. Public Exploits, Pentesting Tools & AI

Aș putea continua cu zeci de exemple de vulnerabilități, dar scopul acestui articol nu este să devină un roman tehnic. De aceea, restul scenariilor pot fi grupate în trei categorii mari, foarte ușor de întâlnit în practică: exploit-uri publice, tool-uri de pentesting și AI.

Exploit-urile publice sunt la un click distanță. Le găsești pe GitHub, bloguri, forumuri sau baze de date publice, iar unele PoC-uri (Proof of Concept) nu se limitează la a confirma vulnerabilitatea. Pot returna direct fișiere, date de configurare, token-uri, chei API sau alte informații sensibile. Un începător poate rula un astfel de script cu impresia că doar verifică, dar ajunge rapid în zona accesării sau transferului neautorizat de date.

Același risc apare și în cazul tool-urilor de pentesting. Ele pot include verificări, payload-uri, template-uri sau reguli automate care nu ridică nicio problemă atunci când ai o scrisoare de autorizare sau un contract de auditare semnat în prealabil. Pe un sistem real, fără autorizație, aceleași acțiuni pot genera request-uri agresive, pot extrage date sau pot produce efecte care depășesc simpla observație.

La fel se întâmplă și cu AI-ul, fie că vorbim despre un chatbot, un LLM local sau un agent care automatizează pași întregi de testare. Fiind antrenat pe practici standard din securitate, poate sugera sau executa verificări normale într-un audit, dar problematice pe un sistem real. AI-ul nu știe dacă ai autorizație și nu înțelege că, în contextul greșit, poate comite în locul tău o acțiune cu implicații penale.

Toate aceste situații sunt ușor de întâlnit în viața reală, mai ales la persoane fără experiență. Nu tool-ul, scriptul sau AI-ul fac diferența, ci contextul în care sunt folosite și efectul produs asupra sistemului testat.

Concluzii

1. Modul în care a fost promovată această lege este neadecvat. Nu poți transmite public, mai ales către tineri de 13-20 de ani, că „hackerii etici” sunt protejați, când legea aduce doar un mic plus față de ce exista înainte. Există o probabilitate mare ca un copil care a urmărit câteva video-uri pe YouTube și a citit postarea de pe Facebook să creadă că are undă verde și este protejat dacă pune în practică ce tocmai crede că a învățat.

2. Dacă doar OBSERVI o posibilă vulnerabilitate și o raportezi către DNSC, rămâi în zona protejată. Însă dacă vrei să fii sigur că este o vulnerabilitate reală și nu doar o bănuială, în încercarea de a demonstra că nu este un fals-pozitiv, există o șansă mare să nu mai ai legea de partea ta.

3. Chiar și cei cu experiență sunt limitați. În multe cazuri, nu vor putea demonstra clar impactul unei vulnerabilități fără să riște depășirea zonei protejate de lege. Astfel, DNSC poate primi multe raportări slabe, incomplete sau false, iar problemele reale se pot pierde printre ele.

4. Dacă identifici o vulnerabilitate într-o instituție publică și depășești limita din greșeală sau din lipsă de experiență, sunt sigur că buna-credință va fi luată în calcul de DNSC și că incidentul va fi tratat cu indulgență.

5. Dacă identifici o vulnerabilitate pe site-ul unei companii sau al unei persoane private și treci peste ce permite noua lege, proprietarul are legea de partea lui. Dacă poate demonstra că ai încălcat un articol neacoperit de art. 365¹, vei avea probleme.

6. Legea 123/2026 nu transformă infrastructura din România într-un program național de bug bounty, cu autorizație, perimetru definit și reguli clare, adică protecția necesară oferită de un astfel de cadru. Fără aceste lucruri, poți ajunge foarte ușor un infractor cibernetic de bună-credință. 

7. Până atunci, documentează-te înainte de a întreprinde orice tip de acțiune și nu uita că tot o scrisoare de autorizare sau un contract te protejează cu adevărat.