CVE-2026-29204 WHMCS: vulnerabilitate IDOR critică în Client Area

Pe 12 mai 2026, WHMCS a publicat versiunile 9.0.4 și 8.13.3 împreună cu un advisory pentru CVE-2026-29204, o vulnerabilitate critică (scor CVSS 10.0) descoperită în Client Area. Defectul se încadrează în clasa IDOR (Insecure Direct Object Reference) și permite unui client autentificat să acționeze asupra serviciilor altor clienți doar prin modificarea unui identificator din cererea HTTP.

WHMCS este platforma de billing și client management folosită de mii de furnizori din întreaga lume, inclusiv mulți furnizori de hosting din România. Dacă rulezi o instalare pe ramura 7.x mai nouă decât 7.4.0, pe 8.x înainte de 8.13.3 sau pe 9.x înainte de 9.0.4, ești expus până la patch. Personalizările tematice sau modulele third-party nu contează — vulnerabilitatea este în core, deci doar update-ul oficial o închide.

Ce este un IDOR și de ce contează atât de mult

Termenul IDOR (sau, mai formal, CWE-639: Authorization Bypass Through User-Controlled Key) descrie o categorie întreagă de vulnerabilități în care aplicația te lasă să accesezi un obiect — factură, comandă, serviciu, contact — doar pentru că poți schimba un ID din URL sau dintr-un formular. Faptul că ești autentificat creează o falsă siguranță: serverul îți verifică login-ul, dar uită să verifice că obiectul cerut îți aparține. Rezultatul e că oricine își poate plimba liber un parametru numeric și poate ajunge la datele altcuiva.

În cazul WHMCS, endpoint-ul afectat este clientarea.php, iar parametrul vulnerabil este addonId, citit direct din $_REQUEST. Aplicația prelua valoarea trimisă de utilizator și opera cu ea fără să verifice că addon-ul aparține contului logat. În scenariul cel mai blând, un client putea să vadă date de facturare sau detalii de servicii ale altora. Pe instalările cu module Single Sign-On activate către cPanel, Plesk sau alte panouri, atacatorul putea ajunge chiar până la accesul direct pe contul de hosting al altui client.

Versiuni afectate și versiuni patched

• WHMCS 7.x — orice build după 7.4.0. Ramura 7.x nu mai are suport activ și nu există patch. Singura cale corectă este migrarea la 8.x sau 9.x.
• WHMCS 8.x — toate versiunile anterioare lui 8.13.3.
• WHMCS 9.x — toate versiunile anterioare lui 9.0.4.

Conform advisory-ului oficial WHMCS, fix-ul a fost livrat pe 12 mai 2026 prin 8.13.3 și 9.0.4. Pentru instalările rămase pe ramura 7.x, soluția nu mai e tehnică — e organizațională: planifică imediat un upgrade la o versiune suportată, pentru că orice fereastră în care rulezi cu acest defect deschis e o invitație clară pentru scaner-ele automate care indexează deja instalări WHMCS publice.

Ce să faci în următoarele ore dacă administrezi o instalare WHMCS

1. Verifică versiunea WHMCS instalată (Setup → System Settings → General Settings sau footer admin). Dacă nu e 8.13.3 sau 9.0.4, ești în zona de risc.
2. Fă backup complet — baza de date, fișierele și configuration.php — înainte de orice update. Pe un sistem critic de billing, backup-ul nu se negociază.
3. Aplică patch-ul oficial din panoul administrativ sau prin upload manual descărcat din contul tău WHMCS.
4. După update, parcurge Activity Log-ul pe ultimele luni și caută cereri Single Sign-On sau accesări de servicii unde utilizatorul inițiator nu se potrivește cu proprietarul contului.
5. Anunță-ți echipa de support: dacă reapar tichete cu „am văzut serviciul altcuiva în panou", acum ai contextul ca să tratezi cazul ca incident, nu ca eroare random.

Workaround temporar dacă nu poți actualiza imediat

Pentru situațiile în care update-ul ad-hoc nu e posibil — servere production cu integrări custom, ferestre de mentenanță programate peste o săptămână, dependențe externe care trebuie validate — WHMCS sugerează o modificare temporară în configuration.php care prinde orice cerere ce conține addonId și o oprește imediat. Conceptual, vorbim despre câteva linii de PHP plasate înainte de orice altă logică:

if (isset($_REQUEST['addonId'])) {
    die('This has been disabled.');
}

Această schimbare blochează complet funcționalitatea de management addon-uri din Client Area, deci unii clienți vor primi mesajul «This has been disabled» când încearcă upgrade sau gestionare addon. Tratează patch-ul ad-hoc strict ca soluție temporară, până când programezi update-ul propriu-zis.

Cum verifici dacă ai fost deja exploatat

Pentru că vulnerabilitatea cere doar un login obișnuit de client, semnalele pe care le cauți nu vin din scaner-e externe ci din comportament normal de aplicație care nu mai are sens când îl analizezi atent:

• Activity Log → Login activity: caută sesiuni unde, după login, același utilizator accesează clientarea.php cu valori diferite de addonId care nu corespund cu serviciile pe care le deține în mod normal.
• Cereri Single Sign-On (dacă ai modul SSO activ): redirecturi inițiate de utilizatorul B către panoul de hosting al contului A.
• Tichete vechi de la clienți care au raportat „am văzut date care nu sunt ale mele". Chiar și dacă răspunsul de atunci a fost că e o eroare de UI, merită reanalizat acum cu noul context.
• Loguri web (nginx/Apache): cereri GET sau POST către clientarea.php cu parametrul addonId care nu provin din linkuri legitime ale aplicației — cu user-agent generic, cu Referer absent sau cu rate anormal de mare.

CVE-2026-29204 nu cere cunoștințe avansate ca să fie exploatată — orice client autentificat poate ajunge la datele altuia prin schimbarea unui ID. Tocmai de asta ferestrele de risc se închid mult mai bine dacă acționezi azi, înainte ca scaner-ele automate să termine de inventariat instalările publice. Dacă ești furnizor de hosting care folosește WHMCS pentru reselleri sau clienți finali, asigură-te că informezi și echipa de support, nu doar pe cea de DevOps — istoricul de tichete este, de multe ori, primul loc unde se vede dacă cineva a profitat deja de defect.