Vulnerabilitate critică cPanel (CVE-2026-41940), aprilie 2026: patch-uri și pași de urmat

Update: după patch-ul CVE-2026-41940, verifică și strategia de backup!

Într-un incident de securitate, backup-ul nu mai este o funcție administrativă obișnuită. Devine parte din planul de recuperare.

Dacă un atacator a avut acces la server înainte de aplicarea patch-ului, există câteva scenarii concrete de luat în calcul:

• fișierele site-ului pot fi modificate;

• baze de date pot fi alterate sau exportate;

• conturi, sesiuni sau parole pot fi compromise;

• backup-urile stocate pe același server pot fi șterse sau afectate;

• restaurarea poate eșua dacă backup-ul nu a fost testat.

Rapid7 notează că exploatarea vulnerabilității poate duce la control asupra configurațiilor, bazelor de date și site-urilor administrate de server.

Întrebarea corectă după actualizare nu este doar „am instalat patch-ul?”, ci și: „dacă serverul a fost compromis ieri, pot restaura date curate astăzi?”

Sunt suficiente backup-urile providerului?

cyber_Folks oferă tuturor clienților de găzduire web, găzduire NVMe și găzduire pentru e-commerce back-up-uri zilnice. Backup-urile oferite de provider acoperă multe scenarii operaționale. Totuși, pentru date critice, nu ar trebui să fie singura copie pe care te bazezi.

Dacă singurul backup există în același cont cPanel, pe același server sau în aceeași infrastructură compromisă, poate deveni inutil exact când ai cea mai mare nevoie de el.

Recomandarea practică:

• păstrează o copie în afara serverului;

• limitează accesul la backup-uri;

• folosește credențiale separate pentru sistemul de backup;

• verifică periodic că fișierele există, sunt complete și pot fi restaurate;

• testează restaurarea într-un mediu separat, fără să suprascrii producția.

NIST recomandă ca backup-urile să fie create, menținute și testate pentru reducerea impactului incidentelor — ransomware, defecte hardware sau ștergeri intenționate.

Regula practică: 3 copii, 2 medii, 1 copie izolată

Pentru site-uri, magazine online sau aplicații business, o abordare realistă este regula 3-2-1:

• 3 copii ale datelor: producție și minimum două backup-uri;

• 2 tipuri diferite de stocare: de exemplu storage extern și copie locală sau offline;

• 1 copie izolată: offline, immutable sau separată de contul principal.

CISA recomandă menținerea backup-urilor offline și testarea regulată a procedurilor, pentru că multe variante de ransomware caută backup-urile accesibile pentru a le șterge sau cripta.

Pentru hosting, asta se traduce concret:

• nu ține singura copie de backup în același cont cPanel;

• nu considera snapshot-ul serverului un înlocuitor complet pentru dump-ul bazei de date;

• nu salva toate copiile cu aceleași date de autentificare;

• nu păstra toate copiile în același loc;

• nu presupune că „backup existent” înseamnă automat „restore funcțional”.

Cât de des trebuie făcute backup-urile?

Frecvența backup-urilor depinde de RPO — Recovery Point Objective. Mai simplu: câte date îți permiți să pierzi dacă trebuie să restaurezi?
Pentru un site de prezentare actualizat rar, un backup zilnic poate fi suficient. Pentru un magazin online, o platformă de rezervări sau o aplicație cu tranzacții frecvente, backup-ul zilnic poate însemna pierderi prea mari.

Documentația MySQL tratează backup-ul ca un ansamblu de metode — logical, physical, full, incremental, point-in-time recovery, scheduling, compresie și criptare — nu ca o soluție unică valabilă pentru orice situație.

Backup complet sau incremental?

Backup-urile incrementale nu sunt greșite în sine. În infrastructuri bine administrate pot fi eficiente. MariaDB documentează explicit backup-uri full și incremental, iar MySQL include recuperare point-in-time din date incrementale.

Problema apare când există un lanț incremental pe care nimeni nu l-a testat cap-coadă.

Un backup incremental devine riscant dacă:

• nu există un backup complet recent;

• lipsește o verigă din lanț;

• fișierele incrementale sunt corupte;

• procesul de restore nu este documentat;

• restaurarea nu a fost testată.

Pentru site-uri și conturi de hosting, o combinație mai ușor de controlat:

• backup complet periodic al fișierelor;

• dump separat pentru baza de date;

• copie offsite;

• retenție pe mai multe zile sau săptămâni;

• test de restaurare regulat.

Pentru infrastructuri mai mari, backup-ul incremental poate rămâne parte din strategie, dar numai dacă restaurarea este verificată, documentată și repetabilă.

Cum verifici dacă backup-ul este bun?

Un backup nu se verifică doar ca existență. Faptul că există un fișier .zip, .tar.gz sau un dump SQL nu garantează că restaurarea va funcționa.

Un proces minim de verificare:

• confirmă că backup-ul a fost generat la ora așteptată;

• verifică dimensiunea și integritatea arhivei;

• confirmă existența dump-ului SQL separat;

• fă un import de test pentru baza de date, acolo unde e posibil;

• restaurează într-un mediu separat;

• validează funcționarea site-ului după restore;

• notează data ultimului restore reușit.

Cel mai important test este restaurarea. Nu în producție, nu în grabă, nu în timpul incidentului. Într-un mediu separat, unde poți confirma că fișierele, baza de date, configurările și permisiunile sunt complete.

Checklist după aplicarea patch-ului CVE-2026-41940

• Confirmă că serverul rulează o versiune patch-uită de cPanel & WHM.

• Verifică versiunea instalată și repornește serviciul cpsrvd, conform instrucțiunilor oficiale cPanel.

• Dacă serverul nu poate fi actualizat imediat, aplică mitigările recomandate de cPanel — inclusiv blocarea porturilor 2083, 2087, 2095 și 2096 sau oprirea serviciilor relevante, până la update.

• Rulează verificările pentru indicatori de compromitere, folosind scriptul de detecție pus la dispoziție de cPanel.

• Confirmă că ai cel puțin o copie de backup în afara serverului.

• Verifică integritatea backup-urilor recente.

• Testează restaurarea într-un mediu separat.

• Schimbă parolele conturilor relevante dacă există suspiciuni de acces neautorizat.

• Verifică utilizatori, sesiuni, fișiere modificate recent și cron job-uri suspecte.

• Notează data ultimului restore testat cu succes.

Dacă afacerea ta deja este la un nivel avansat în ceea ce privește datele, îți recomandăm să te informezi și despre serviciul de disaster recovery. Colegul nostru Ciprian Șandru explică pe larg beneficiile serviciului în acest clip:

Ce e CVE-2026-41940 și de ce contează

Vulnerabilitatea, identificată oficial drept CVE-2026-41940 și încadrată cu severitate CVSS 9.8 din 10, este de tipul authentication bypass. În termeni simpli: atacatorul trimite o cerere care păcălește serverul cPanel să-l recunoască drept administrator, fără parolă. Rezultatul: acces root la WHM.

Două lucruri o fac problematică pentru întreaga industrie de hosting:

Era exploatată activ înainte de patch – conform analizei Rapid7, atacatorii o foloseau anterior anunțului din 28 aprilie. Este, prin definiție, un zero-day rezolvat prin patch coordonat.

Afectează toate edițiile suportate cPanel & WHM neactualizate. Conform comunicatului oficial cPanel, orice provider de hosting care folosea cPanel & WHM și nu a aplicat patch-ul după 28 aprilie 2026 avea servere vulnerabile.

Ce am făcut la cyber_Folks

Echipa noastră tehnică, cu 21 de ani de experiență în administrarea infrastructurii pentru peste 200.000 de domenii și 45.000 de clienți activi, a procedat în trei pași:

Hosting shared: patch-ul a fost aplicat pe toate serverele administrate de noi în mai puțin de 12 ore de la publicare.

VPS și Server Dedicat cu cPanel administrat de noi: aplicăm patch-ul progresiv, treptat spre versiunile stabile. În paralel, verificăm log-urile WHM pentru indicatori de compromitere conform recomandărilor cPanel.

Igienă post-incident: pe o categorie de servere rotim preventiv parolele de root. Procesul continuă în următoarele zile, în paralel cu verificări de integritate.

La momentul publicării acestui articol, nu avem indicatori care să sugereze că serverele shared hosting cyber_Folks au fost compromise în fereastra dintre apariția vulnerabilității și aplicarea patch-ului. Verificările continuă.

Ce trebuie să faci tu

Dacă ai hosting shared la noi: nimic. Patch-ul e instalat.

Dacă ai VPS sau Server Dedicat cu cPanel administrat de noi și parola de root nu mai funcționează: deschide un tichet la suport[at]cyberfolks.ro. Verificăm situația și te ajutăm să te reconectezi în siguranță.

Dacă ai VPS sau Dedicat cu cPanel administrat de către tine: aplică patch-ul cPanel cât mai curând. Verifică log-urile WHM pentru indicatori de compromitere conform ghidului oficial cPanel.

În cazul în care sesizezi probleme sau ai orice fel de întrebări, îți stăm la dispoziție prin canalele obișnuite de suport. Suntem aici pentru orice fel de întrebare.

Adrian Chiruță

Adrian Chiruță este co-CEO al cyber_Folks România, specialist în web hosting, servere performante, securitate online și optimizare site-uri. Cu o experiență de peste 15 ani în domeniul IT, Adrian oferă informații practice și soluții profesionale pentru antreprenorii care vor o prezență online sigură, stabilă și rapidă. Este dedicat excelenței și crede că experiența clientului trebuie să depășească întotdeauna așteptările.

Vezi toate articolele →