CVE-2026-41940: Vulnerabilitate Critică cPanel/WHM — Ghid Complet de Remediere

info9778868
6 mai
13 min de citit

Actualizată în: acum 7 ore

Pe 28 aprilie 2026, cPanel a publicat în liniște un patch de urgență. A doua zi, watchTowr Labs a publicat exploit-ul. Între cele două momente, peste două milioane de servere de hosting au stat literalmente cu ușa larg deschisă către internet.

Dacă administrezi un server cPanel/WHM — sau ai un site găzduit pe unul — următoarele 14 minute de citire pot face diferența între un weekend liniștit și o notificare GDPR de 72 de ore.

Rezumat executiv

O vulnerabilitate critică de tip authentication bypass afectează toate versiunile suportate de cPanel & WHM. Cu o singură cerere HTTP atent construită — fără utilizator, fără parolă, fără token, fără interacțiune din partea cuiva — un atacator de pe internet poate obține o sesiune administrativă cu privilegii complete.

Identificator: CVE-2026-41940
Severitate: CVSS 9.8 (Critical) — exploatare confirmată în mediu real
Cauza: injecție CRLF (\r\n) în fluxul de creare a fișierelor de sesiune
Acțiune imediată: aplică patch-ul oficial sau blochează porturile 2083 și 2087
Clienți ZebraByte: infrastructura noastră de hosting administrat nu este afectată (rulăm ZebraByte panel, nu pe cPanel)

Ce găsești în acest articol

Anatomia vulnerabilității — ce înseamnă, în limbaj simplu
Cum funcționează exploitarea — povestea unui \r\n
Cronologia incidentului — de la zero-day la PoC public în 24h
Cine este afectat și cine nu
Impactul real — de ce este o catastrofă pentru un host
Cum aplici patch-ul — pas cu pas
Mitigări temporare dacă nu poți face update imediat
Indicatori de compromis (IOC) — cum verifici dacă ai fost atacat
Lecții pentru proprietarii de business online
Cum te ajută ZebraByte
Întrebări frecvente

1. Anatomia vulnerabilității

Pentru cei care nu administrează zilnic servere de hosting: cPanel și WHM (WebHost Manager) sunt panourile de control web folosite pentru a administra majoritatea serverelor de hosting partajat din lume. cPanel este interfața clientului — locul de unde îți gestionezi e-mailurile, bazele de date, site-urile, certificatele SSL. WHM este interfața administratorului — practic, cheile întregului regat.

Conform watchTowr Labs și estimărilor publicate de Eye Security, vorbim despre peste 70 de milioane de domenii și peste 2 milioane de instanțe cPanel expuse direct pe internet. Este una dintre cele mai mari suprafețe de atac din întregul ecosistem de hosting.

Pe 28 aprilie 2026, cPanel a lansat o actualizare de securitate de urgență descrisă lapidar drept „o problemă cu încărcarea și salvarea sesiunilor”. A doua zi, vulnerabilitatea a primit identificatorul oficial CVE-2026-41940, scor CVSS 9.8, și a fost reclasificată drept ceea ce este de fapt: un bypass complet de autentificare.

Ce înseamnă „bypass de autentificare” în acest context: atacatorul nu trebuie să ghicească parole. Nu trebuie să intercepteze sesiuni. Nu trebuie să convingă pe nimeni să apese un link. Nu trebuie nici măcar un cont valid pe server. Trimite o cerere HTTP normală, formulată într-un anume fel, și serverul îi întoarce o sesiune cu drepturi de root. Atât.

De unde vine, structural

cPanel a evoluat timp de două decenii. În acest interval, în jurul fluxului de login s-au adăugat treptat multiple căi auxiliare de autentificare: HTTP Basic Auth, fluxuri de fallback, integrări API, recuperare de sesiune după restart de serviciu. Fiecare cale a fost adăugată cu o intenție validă — dar cu un set ușor diferit de presupuneri despre ce înseamnă „cerere autentificată”.

Vulnerabilitatea apare exact la cusătura dintre aceste fluxuri. Atunci când serviciul cpsrvd (cPanel Service Daemon) primește o cerere de login, scrie pe disc un fișier de sesiune chiar înainte de a confirma identitatea utilizatorului. Logica e: scriem fișierul, generăm token-ul, validăm credențialele, apoi suprascriem fișierul dacă e cazul. O optimizare de performanță rezonabilă pe hârtie.

În practică, această ordine creează o fereastră în care fișierul de sesiune există pe disc înainte ca autentificarea propriu-zisă să se fi întâmplat. Și acolo intervine partea genială (și pentru hosting providers, terifiantă) a exploitului.

2. Cum funcționează exploitarea

Tehnic, CVE-2026-41940 este o CRLF injection — injecție de caractere Carriage Return și Line Feed (\r\n) într-un context în care intrarea utilizatorului este scrisă fără sanitizare într-un fișier structurat pe linii.

Iată povestea exploitului, simplificată. Când trimiți o cerere de login către WHM, serverul răspunde cu un cookie de sesiune, indiferent dacă login-ul reușește sau nu:

POST /login/?login_only=1 HTTP/1.1
Host: target:2087
Content-Type: application/x-www-form-urlencoded
Content-Length: 20

user=root&pass=wrong

Răspunsul serverului:

HTTP/1.1 401 Access Denied
Set-Cookie: whostmgrsession=:Wg_mjzgt1hyfXefK,1bd3d4bf...; HttpOnly; secure
Content-Type: text/plain

{"status":0,"message":"see_login_log"}

Observație critică: cookie-ul de sesiune este emis chiar și pe un login eșuat. cPanel îl emite ca să poată corela log-urile de autentificare. Cookie-ul are forma nume_sesiune,hash, unde nume_sesiune este controlat de server, iar hash-ul este derivat din intrarea utilizatorului prin criptare.

Aici e capcana: dacă atacatorul omite intenționat partea cu hash-ul din cookie și folosește în schimb un antet Authorization: Basic cu un payload special, cPanel sare peste rutina de criptare normală și scrie direct conținutul brut al credențialelor Basic Auth în fișierul de sesiune.

Iar credențialele Basic Auth pot conține \r\n după decodare base64. Iar fișierul de sesiune este un format text structurat pe linii (cheie=valoare, un atribut pe linie).

Concluzia logică: atacatorul codează în Basic Auth o secvență de tipul orice\r\nuser=root\r\nprivs=admin. cPanel o decodează, o scrie în fișierul de sesiune fără să o sanitizeze, iar la următoarea cerere — cu același nume de sesiune — serverul citește fișierul, vede atributul user=root înscris de însuși atacatorul, și emite o sesiune complet privilegiată. Fără să se fi întâmplat vreodată o autentificare reală.

Asta nu este o vulnerabilitate de execuție de cod, criptografie spartă, sau buffer overflow exotic. Este o vulnerabilitate de logică — exact tipul de greșeală care reușește să se strecoare în producție atunci când mai multe căi de autentificare evoluează independent una de alta și cineva uită să verifice ce se întâmplă la intersecție.

Ironic, e una dintre cele mai vechi clase de vulnerabilități cunoscute. CRLF injection apare în literatura de securitate web încă din anii 2000. Faptul că reușește să-și facă apariția în 2026 într-un produs care administrează 70 de milioane de domenii este, în sine, o lecție.

3. Cronologia incidentului

28 Aprilie 2026, dimineață — cPanel publică actualizarea de securitate. Bulletin-ul oficial menționează discret „o problemă cu încărcarea și salvarea sesiunilor”. Patch-uri pentru toate ramurile suportate. KnownHost confirmă ulterior că vulnerabilitatea era deja folosită ca zero-day împotriva clienților lor.

29 Aprilie 2026, dimineață — se atribuie CVE-2026-41940 (CVSS 9.8). National Vulnerability Database publică intrarea oficială. Namecheap implementează blocare temporară a porturilor 2083 și 2087 la nivel de firewall pentru toți clienții, până la aplicarea patch-ului.

29 Aprilie 2026, după-amiază — watchTowr Labs publică exploit-ul. Cercetătorul Sina Kheirkhah publică analiza tehnică completă cu proof-of-concept funcțional. Eye Security identifică peste 2 milioane de instanțe cPanel expuse direct pe internet la momentul divulgării.

29–30 Aprilie 2026 — adoptare publică a exploit-ului. Furnizori de telemetrie observă scanări masive pe porturile 2083/2087 din spații IP rezidențiale și cloud-uri abuzate. Rapid7, GreyNoise și Field Effect publică propriile alerte. Centrul belgian CCB clasifică incidentul drept „warning critical”.

30 Aprilie 2026, astăzi — fereastra de patch este deschisă, dar se închide rapid. Estimările conservatoare sugerează că zeci de mii de servere expuse sunt încă vulnerabile. Auto-update-ul cPanel este soluția cea mai sigură pentru cei care nu au reacționat în primele 48 de ore.

4. Cine este afectat (și cine nu)

Vulnerabilitatea afectează toate versiunile curent suportate de cPanel & WHM, plus produsul WP Squared. Tabelul de mai jos cuprinde liniile de versiune și revizia minimă patch-uită:

Linie de versiune	Stare anterioară (vulnerabilă)	Versiune patch-uită
cPanel & WHM 110.0.x	≤ 11.110.0.96	11.110.0.97
cPanel & WHM 118.0.x	≤ 11.118.0.61	11.118.0.63
cPanel & WHM 126.0.x	≤ 11.126.0.53	11.126.0.54
cPanel & WHM 132.0.x	≤ 11.132.0.27	11.132.0.29
cPanel & WHM 134.0.x	≤ 11.134.0.19	11.134.0.20
cPanel & WHM 136.0.x	≤ 11.136.0.4	11.136.0.5
WP Squared	≤ 136.1.6	136.1.7

Dacă rulezi orice versiune anterioară celor de mai sus, sau o versiune nesuportată (orice anterior 11.40), serverul tău este vulnerabil până aplici patch-ul.

Și clienții ZebraByte?

Infrastructura ZebraByte nu este afectată. Serviciile noastre de hosting administrat — WordPress, Odoo, hosting partajat — rulează pe panoul ZebraByte in house și pe stack-uri proprietare protejate de Cloudflare Enterprise WAF. Nu folosim cPanel/WHM pe linia de hosting administrat. Niciun cont de hosting ZebraByte nu este expus la CVE-2026-41940.

Dacă administrezi însă un VPS sau server dedicat propriu pe care ai instalat cPanel/WHM (chiar și prin furnizori terți), ești responsabil pentru aplicarea patch-ului. Echipa ZebraByte poate prelua remedierea contra cost — vezi secțiunea finală.

5. Impactul real

Atunci când spunem „CVSS 9.8”, e ușor să te dezobișnuiești de cifre. Dar într-un context de hosting partajat, această vulnerabilitate înseamnă concret:

Compromiterea totală a serverului. Atacatorul are sesiune root WHM. Asta înseamnă acces la fiecare site găzduit, fiecare bază de date MySQL, fiecare căsuță de e-mail, fiecare cont FTP/SSH, fiecare cheie SSL privată stocată local.
Escaladare către execuție de cod (RCE). Sesiunea WHM permite instalarea de pachete, scripturi cron, modificări de configurare PHP — ceea ce duce direct la control de OS asupra mașinii.
Pivotare în rețeaua clientului. Dacă serverul cPanel are conexiuni VPN sau acces la rețele interne (frecvent în setup-uri SMB), atacatorul intră direct în infrastructura clientului dincolo de hosting.
Backdoor-uri persistente. Conturi WHM nou-create, chei SSH adăugate în ~/.ssh/authorized_keys, cron-uri programate, malware injectat în temele WordPress ale tuturor clienților găzduiți.
Furt de credențiale și escaladare laterală. Bazele de date conțin parole hash-uite, dar și API key-uri, token-uri de plată, integrări terțe. Atacatorii moderni nu se opresc la serverul compromis.
Implicații GDPR severe. Pentru hosturi cu clienți EU/UK, un compromis de această natură declanșează obligații de raportare către ANSPDCP / ICO în 72 de ore (Art. 33 GDPR), plus notificare individuală a persoanelor vizate dacă riscul este ridicat (Art. 34).

„Imaginează-ți cheile de la regat. Iar regatul este internetul, iar apartamentele sunt site-urile tuturor.”— watchTowr Labs, despre WHM

6. Cum aplici patch-ul

Patch-ul oficial cPanel este distribuit prin canalul standard de actualizare. Dacă ai auto-update activat, e foarte probabil să fi fost deja aplicat în noaptea de 28 spre 29 aprilie. Dar nu presupune nimic — verifică explicit.

Pasul 1 — Verifică versiunea curentă

# Conectat ca root prin SSH
/usr/local/cpanel/cpanel -V

# Output exemplu — caută versiunile patch-uite din tabel
11.134.0.20 (build 1)

Pasul 2 — Forțează actualizarea

# Rulează update-ul oficial cPanel forțat
/usr/local/cpanel/scripts/upcp --force

# Apoi restartează serviciul de daemon
/scripts/restartsrv_cpsrvd

# Verifică că noua versiune rulează
/usr/local/cpanel/cpanel -V

Pasul 3 — Activează auto-update-ul (dacă nu e deja)

Conectează-te în WHM ca root și navighează la WHM → Server Configuration → Update Preferences. Asigură-te că:

Daily Updates: setat pe Automatic (RECOMMENDED)
cPanel Release Tier: RELEASE sau STABLE — niciodată EDGE pe servere de producție decât dacă ai un motiv bun
Operating System Package Updates: setat pe Automatic

Pasul 4 — Restartează cu disciplină

Patch-ul atinge cpsrvd și fluxul de sesiuni. După update, asigură-te că daemon-ul a fost într-adevăr restartat:

ps -ef | grep cpsrvd
# Caută PID-ul recent — uptime-ul procesului trebuie să fie post-update

# Verifică și serviciile aferente
/scripts/restartsrv_cpdavd
/scripts/restartsrv_dovecot
/scripts/restartsrv_exim

7. Mitigări temporare

Dacă din motive operaționale nu poți aplica patch-ul în acest moment (ex: mentenanță planificată, backup în desfășurare, dependență de un release manager terț), trebuie să blochezi atacul la nivel de rețea până când poți face update.

Mitigarea de bază — blocare de port

Cea mai eficientă măsură temporară este restricționarea accesului la porturile cPanel/WHM doar la IP-uri de încredere:

# iptables — permite doar IP-ul tău administrativ
iptables -I INPUT -p tcp --dport 2083 -j DROP
iptables -I INPUT -p tcp --dport 2087 -j DROP
iptables -I INPUT -p tcp -s "YOUR.ADMIN.IP/32" --dport 2083 -j ACCEPT
iptables -I INPUT -p tcp -s "YOUR.ADMIN.IP/32" --dport 2087 -j ACCEPT

# Salvează regulile
iptables-save > /etc/iptables/rules.v4

# Opțional, poți bloca și 2095 (Webmail) și 2096 (Webmail SSL)
# dacă serviciile respective nu sunt critice pentru clienții tăi

Mitigare la edge — Cloudflare WAF

Dacă serverul tău este în spatele Cloudflare (recomandat în 2026), poți crea o regulă personalizată care să blocheze cereri suspecte la endpoint-ul /login/:

(http.request.uri.path eq "/login/") and 
(http.request.method eq "POST") and 
(http.request.headers["authorization"][0] contains "Basic ") and
(not ip.src in {YOUR.ADMIN.IP})

Important: mitigarea ≠ remediere. Blocarea porturilor și regulile WAF îți cumpără timp — cel mult câteva zile. Patch-ul oficial rămâne singura soluție permanentă. Nu lăsa serverul în „mod paranoia” săptămâni întregi sperând că va fi suficient. Update-ul este obligatoriu.

8. Indicatori de compromis (IOC)

Dacă serverul tău a fost expus pe internet în ultimele zile, presupune compromis până dovedești contrariul. Patch-ul închide ușa pentru viitor — dar nu remediază nimic dacă atacatorul a intrat deja înainte de luni dimineață.

Ce să cauți în log-uri

# 1. Cereri POST către endpoint-ul de login cu Basic Auth — punctul de injecție
grep -E "POST /login/.*login_only=1" /usr/local/cpanel/logs/access_log
grep "Authorization: Basic" /usr/local/cpanel/logs/access_log

# 2. Caractere CR/LF anormale în log-ul de login
grep -P "[\r\n]" /usr/local/cpanel/logs/login_log

# 3. Sesiuni create fără login_log corespunzător
ls -la /var/cpanel/sessions/raw/*/
# Compară timestamp-urile fișierelor de sesiune cu intrările din login_log

# 4. Conturi WHM noi sau privilegii modificate recent
grep -i "createacct" /usr/local/cpanel/logs/access_log | tail -50
cat /var/cpanel/users/* | grep -i "OWNER\|RESELLER"

# 5. Chei SSH adăugate recent
find /root /home -name authorized_keys -mtime -7 -ls

# 6. Job-uri cron suspecte create recent
find /var/spool/cron /etc/cron.d -mtime -7 -type f -ls

# 7. Fișiere cu setuid scrise recent (frecvent pentru backdoor-uri)
find / -perm -4000 -mtime -7 -type f 2>/dev/null

# 8. Procese rulate de utilizatori neașteptați
ps -eo user,pid,cmd | grep -vE "^(root|nobody|mysql|named|mail|cpanel)"

Indicatori de rețea

Conexiuni outbound către domenii sau IP-uri necunoscute, în special pe porturi neobișnuite (4444, 8080, 1337, 31337)
Trafic crescut DNS către resolveri externi din spațiul .dyndns, .duckdns, *.no-ip
Cereri ICMP/UDP outbound regulate către aceeași destinație (semn de C2 beacon)

Dacă găsești IOC pozitivi: nu încerca să „cureți” serverul. Reinstalează de la zero, restaurează datele dintr-un backup pre-incident, rotește toate credențialele (SSH, MySQL, WHM, e-mail-uri client), notifică ANSPDCP/ICO în 72 de ore conform GDPR Art. 33, și contactează un specialist în răspuns la incidente. ZebraByte poate prelua acest proces — vezi secțiunea finală.

9. Lecții pentru proprietarii de business online

Chiar dacă nu administrezi tu serverul cPanel — chiar dacă tot ce faci este să ai un site care e găzduit undeva — această poveste ar trebui să-ți spună ceva.

Furnizorul de hosting este parte din lanțul tău de securitate

Mulți proprietari de afaceri tratează hosting-ul ca pe electricitatea — o resursă invizibilă care „pur și simplu funcționează”. Dar furnizorul tău are acces la fiecare e-mail al clienților tăi, fiecare bază de date, fiecare formular de plată. Întreabă-l: ce versiune de panou rulați? Ce SLA aveți pentru patch-uri critice? Aveți audituri de securitate publice?

Auto-update nu este opțional în 2026

Fereastra dintre divulgare și exploatare în masă a scăzut sub 24 de ore. Argumentul „prefer să verific manual fiecare patch” a expirat în jurul lui 2018. Dacă nu ai auto-update, ai un ceas care ticăie.

Apărarea în adâncime contează

O singură vulnerabilitate critică nu ar trebui să compromită întreg business-ul. Stack-ul tău trebuie să aibă straturi: WAF la edge (Cloudflare), izolație la nivel de cont (PHP-FPM separat per user, OS-level confinement), backup-uri imutabile (snapshot-uri în alt furnizor), monitorizare comportamentală, și un plan de răspuns la incident pe care l-ai testat.

Backup-urile trebuie testate, nu doar create

Cele mai dureroase pierderi de date din anii recenți nu sunt cele unde nu existau backup-uri. Sunt cele unde backup-urile existau, dar erau corupte, încriptate de același atac, sau pur și simplu nu se restaurau. Testează restaurarea cel puțin trimestrial.

Comunicarea în criză este la fel de importantă ca tehnica

Dacă ai un incident, clienții tăi vor afla. Întrebarea e: vor afla de la tine, sau de la o terță parte? Pregătește-ți pagina de status (status.example.com), șabloanele de comunicare către clienți, și relația cu un specialist legal pentru notificările GDPR înainte de incident, nu în mijlocul lui.

10. Cum te ajută ZebraByte

Dacă administrezi un VPS sau server dedicat cu cPanel/WHM și nu ești sigur de starea lui, echipa noastră de incident response poate face evaluare, patch și hardening complet în interval de ore, nu zile. Lucrăm pe stack-uri terțe — Hetzner, Contabo, OVH, infrastructură proprie — fără să schimbi furnizorul.

Pentru clienții ZebraByte existenți, această evaluare este oferită fără cost suplimentar dacă ai abonament Managed Security. Pentru noi clienți, intervenția este o factură unică, scop fix, fără surprize.

Contactează-ne:

Sub atac (24/7): zebrabyte.ro/underattack
Deschide ticket: help.zebrabyte.ro
Email: legal@zebrabyte.co.uk
Telefon: +44 330 533 0334

11. Întrebări frecvente

Dacă serverul meu cPanel nu este expus pe internet (e doar în rețea internă), sunt în siguranță?

Mai puțin expus, dar nu imun. Atacatorul are nevoie doar de acces de rețea la portul WHM. Asta înseamnă că oricine cu acces la VPN-ul tău, oricine pe segmentul intern, sau orice altă mașină compromisă din rețea poate ataca serverul cPanel. Patch-ul rămâne obligatoriu. Single-tenant, izolație de rețea și zero-trust internal nu sunt scuze pentru a sări peste un patch CVSS 9.8.

Pot detecta dacă serverul meu a fost atacat retroactiv, prin intermediul unui scaner comercial?

Da, parțial. Furnizori precum Rapid7 (Nexpose / InsightVM), Tenable (Nessus) și GreyNoise au publicat semnături autentificate pentru CVE-2026-41940 începând cu 30 aprilie 2026. Acestea îți spun dacă ești vulnerabil. Pentru detectarea unui compromis activ ai nevoie de log analysis (vezi secțiunea IOC) și ideal de un EDR (Endpoint Detection & Response) precum Wazuh, CrowdStrike sau SentinelOne.

Furnizorul meu de hosting (Namecheap, Bluehost, etc.) a aplicat deja patch-ul?

Marii furnizori de hosting partajat (Namecheap, HostGator, GoDaddy, Bluehost, A2 Hosting) au aplicat patch-uri în primele 24-48 de ore după divulgare, unii cu blocaj temporar de port în paralel. Dacă ești client de hosting partajat la unul dintre aceștia, nu trebuie să faci nimic — dar e o ocazie bună să-ți rotești parolele cPanel proactiv. Verifică pagina lor de status pentru confirmare.

Folosesc Plesk în loc de cPanel — sunt afectat?

Nu. CVE-2026-41940 este specifică implementării cpsrvd din cPanel & WHM. Plesk, DirectAdmin, ISPConfig, CWP, HestiaCP — toate folosesc fluxuri de autentificare diferite și nu sunt afectate de această vulnerabilitate. Asta nu înseamnă că nu ai propriile patch-uri de făcut — verifică ciclul de update al panoului tău.

Atacatorul ar putea decripta datele mele dacă serverul a fost compromis?

Da, dacă cheile criptografice erau stocate pe server. WHM cu privilegii root are acces la cheile SSL/TLS private ale tuturor site-urilor găzduite, parolele MySQL în plaintext în /etc/my.cnf, parolele e-mail în baza Dovecot, și — dacă ai stocat ceva fără criptare la nivel de aplicație — toate datele clienților tăi. Acesta este motivul pentru care un compromis WHM este de obicei tratat drept full breach, nu doar incident parțial.

Trebuie să raportez la ANSPDCP / ICO dacă am fost compromis?

Aproape sigur, da. GDPR Art. 33 obligă operatorul de date să notifice autoritatea de supraveghere în 72 de ore de la momentul în care a aflat de incident, dacă există risc pentru drepturile persoanelor vizate. Un compromis cPanel/WHM cu acces complet la baza de date a clienților tăi atinge aproape întotdeauna acest prag. Pentru ZebraByte (UK), notificarea merge la ICO; pentru entități cu sediul principal în România, la ANSPDCP. Consultă un specialist legal — sau echipa GPR ZebraByte (gpr@zebrabyte.co.uk).

Cât costă un audit de securitate pentru un server cPanel/WHM?

La ZebraByte, un audit standard cPanel/WHM (evaluare versiune, configurare WHM, hardening SSH, audit conturi, scan IOC, recomandări de mitigare) este o intervenție unică începând de la o factură fixă, livrată în 48 de ore împreună cu un raport brand-uit. Pentru o ofertă personalizată, scrie-ne la legal@zebrabyte.co.uk sau sună la +44 330 533 0334.

Surse oficiale și referințe

cPanel Security Bulletin — Security Update 04/28/2026: support.cpanel.net
NVD — CVE-2026-41940: nvd.nist.gov
watchTowr Labs — analiză tehnică completă cu PoC: labs.watchtowr.com
Rapid7 — ETR pentru CVE-2026-41940: rapid7.com
BleepingComputer — cPanel emergency update: bleepingcomputer.com
The Hacker News — Critical cPanel Authentication Vulnerability: thehackernews.com
Centre for Cybersecurity Belgium (CCB) — Warning: ccb.belgium.be

Acest articol este publicat în scop informativ. Informațiile reflectă starea cunoștințelor publice la data publicării (30 aprilie 2026). Pentru evaluarea concretă a propriei infrastructuri, consultă un specialist în securitate. ZebraByte® și logo-ul ZebraByte sunt mărci înregistrate ale ZEBRABYTE LIMITED (UK Reg. 15194067, ICO Ref ZB748706).