Înapoi la Noutăți
Amenințări

Caută în jurnale „Username too long"

Avertizarea Check Point include ceva ce majoritatea avertizărilor nu au: un șir de text care apare în jurnalul de audit când cineva încearcă atacul. Căutarea nu costă nimic, iar asta e a cincea vulnerabilitate de acest fel din iulie încoace.

Caută în jurnale „Username too long"

Majoritatea avertizărilor critice îți spun ce să patchuiești. Asta îți spune și cum să afli dacă a încercat deja cineva.

CVE-2026-91843 e o depășire de stivă pe calea de autentificare neautentificată a serverelor Check Point de management și de jurnale, cotată 9.8, care oferă execuție de cod la distanță cu drepturi de root, fără credențiale. Se declanșează printr-o cerere de autentificare cu un nume de utilizator supradimensionat — iar o încercare eșuată lasă urmă.

Jurnale SmartConsole Audit si Admin login:

"Administrator failed to log in: Username too long"

Caută șirul ăsta. Un singur rezultat contează, rezultate repetate contează mai mult, iar cele venite de la adrese sursă neașteptate sau expuse în internet contează cel mai mult. Depășirea e accesibilă înainte de orice verificare de credențiale, deci linia asta e ce lasă o încercare, indiferent dacă a reușit sau nu.

Nu există exploatare confirmată. CISA consemnează exploatarea ca inexistentă, vulnerabilitatea nu e în catalogul de breșe exploatate activ, iar Censys nu raporta niciun cod public de demonstrație la 16 septembrie. Check Point spune că nu a primit raportări de atacuri.

Asta e starea actuală, nu o prognoză. O vulnerabilitate care dă root fără autentificare în infrastructura de administrare a securității de rețea nu rămâne, de obicei, teoretică mult timp după ce circulă un declanșator funcțional.

Ce e afectat și o corecție care merită făcută

Produsele afectate sunt Security Management Server, Multi-Domain Security Management Server, Log Server și Multi-Domain Log Server. Sunt vulnerabile și instalările standalone, care rulează managementul și gateway-ul pe același sistem.

R82.20 toate versiunile R82.10 Jumbo Hotfix Take 44 sau mai mic R82 Jumbo Hotfix Take 126 sau mai mic R81.20 Jumbo Hotfix Take 166 sau mai mic R81.10 Jumbo Hotfix Take 190 sau mai mic (iesit din suport) R81, R80.40, R80.30, R80.20, R80.10, R80 (iesite din suport)

Unele relatări au listat R82 ca afectat la „Take 22 sau mai mic". Cifra e 126. Dacă ți-ai verificat serverele R82 față de numărul mai mic și ai tras concluzia că ești acoperit, verifică din nou.

Smart-1 Cloud, serviciul de management găzduit de Check Point, nu e afectat — remedierea a fost aplicată acolo înainte de comunicarea publică.

Remedierea nu e un Jumbo Hotfix

Asta e partea care produce cel mai probabil o senzație falsă de acoperire.

Check Point o livrează prin canalul de urgență LivePatch, nu ca un Jumbo Hotfix Take obișnuit. Faptul că ești la zi cu Jumbo Takes nu e protecție. Pachetele offline sunt urgent security update Take 29 pentru R82.20 și Take 28 pentru R82.10, R82 și R81.20.

Dacă actualizările automate sunt activate — setarea din SmartConsole, la Global Properties, Data Access Control — Check Point spune că ești deja protejat.

Confirmă asta, nu o presupune.

Există un motiv pentru insistență. Când Check Point a împins remedieri pentru două vulnerabilități de certificate VPN în săptămâna precedentă, mai mulți clienți din propria comunitate au raportat că pachetul automat nu ajunsese la sistemele lor în ziua anunțului, iar un administrator al comunității a răspuns că se distribuie, probabil, în etape. Clienții au mai descoperit că linkurile de descărcare apăreau doar după autentificarea în User Center.

Verificarea ține de o singură comandă. În modul Expert, pe fiecare server de management și de jurnale:

cplp list

Ar trebui să vezi o linie cu fwm:fwm în stare armed, în mod livepatch, cu un comentariu care face referire la CVE-2026-91843. Dacă nu e acolo, serverul nu e protejat, indiferent ce spune setarea de actualizare.

Ramurile ieșite din suport: sursele se contrazic

Censys afirmă că R81.10, R81 și ramurile R80.x nu primesc nicio remediere și că singura soluție e trecerea pe o ramură suportată.

Check Point a declarat pentru The Hacker News altceva — că există o remediere pentru versiunile ieșite din suport și că cei care au nevoie de ea ar trebui să deschidă un tichet la suport.

Dacă ești pe una dintre acele ramuri, deschide tichetul. Nu presupune că una dintre versiuni e cea operantă și nu aștepta ca situația să se clarifice singură, cât timp un server de management nepatchuit e accesibil.

Măsura de atenuare și de ce sună cunoscut

Îndrumarea Check Point e să restricționezi Trusted Clients din SmartConsole la adrese IP sau subrețele aprobate, la Manage & Settings, Permissions & Administrators, Trusted Clients. Tipul de client nu trebuie setat pe „Any". Accesul la management nu trebuie să fie accesibil direct din internet.

Potrivit Check Point, calea vulnerabilă trece exclusiv prin setarea Trusted Clients — ceea ce face din asta o măsură cu efect real, nu o sugestie generică de întărire.

E, totodată, cuvânt cu cuvânt, prima măsură recomandată de Check Point în iulie.

Cinci în două luni

După numărătoarea The Hacker News pe fișele CVE ale Check Point, asta e a cincea vulnerabilitate critică din 22 iulie încoace pe care un atacator o putea atinge pe Security Management Server fără să se autentifice.

DataCVENotă
22 iulieCVE-2026-16232Ocolire de autentificare în SmartConsole. Exploatată. Adăugată în catalogul CISA KEV în aceeași zi
22 iulieCVE-2026-62144A doua ocolire de management, neraportată ca exploatată
3 augustCVE-2026-18574Ocolire de autentificare care permitea execuția de comenzi pe serverul de management
9 septembrieCVE-2026-85103Depășire de heap la decodarea certificatelor VPN, care atinge și Quantum Security Management
16 septembrieCVE-2026-91843Aceasta

Prima dintre ele a fost efectiv exploatată. Check Point scria atunci că a afectat un număr mic de clienți, într-o singură configurație — atunci când managementul era expus direct în internet, fără restricții de IP.

Cinci ocazii distincte, în două luni, de a învăța că expunerea, nu eroarea individuală, e lucrul aflat sub controlul tău.

Am făcut aceeași observație acum o săptămână, scriind despre echipamentul de management al firewall-urilor Cisco, unde un afiliat de ransomware a intrat printr-o vulnerabilitate cotată 5.3, pentru că stătea pe planul de administrare a securității. Lecția se repetă pentru că e aceeași clasă de activ: consola care îți administrează firewall-urile îți știe topologia, deține credențiale către echipamentele pe care le administrează și e integrată cu directorul tău. Orice vulnerabilitate de pe planul ăla merită tratată cu o treaptă peste scorul ei.

Ce ai de făcut

  1. Caută în jurnalele de audit „Administrator failed to log in: Username too long", pe toată perioada de retenție. E gratuit și e singura cale de a ști dacă ai fost sondat.
  2. Aplică LivePatch-ul de urgență pe fiecare Security Management Server, server Multi-Domain și Log Server. Nu doar pe cele principale.
  3. Verifică pe fiecare cu cplp list. Armed, livepatch, CVE-ul menționat.
  4. Verifică Trusted Clients pe fiecare server de management. Adrese anume, niciodată „Any". E măsura cu efect real și e, totodată, remedierea pentru următoarea vulnerabilitate.
  5. Confirmă că managementul nu e accesibil din internet. Censys observă 3.836 de gazde în lume care prezintă identitatea implicită atribuită de Check Point acestor servere — o numărătoare de prezență, nu de sisteme vulnerabile, dar fiecare e un plan de administrare care răspunde în internetul deschis.
  6. Dacă ești pe o ramură ieșită din suport, deschide azi un tichet la suport și planifică oricum trecerea pe o versiune suportată.

4Tify analizează expunerea și configurația infrastructurii de administrare a securității — consolele care dețin cheile către tot restul. Dacă rulezi management Check Point și nu poți confirma setările de Trusted Clients, scrie-ne.

DISTRIBUIE