Awarely Monitor
AwarelyMonitor
Toate articolele
Vulnerabilități exploatate8 min

KEV 16 septembrie: Cisco ISE, Acronis Backup și Pixel

Pe 16 septembrie 2026, CISA a adăugat trei vulnerabilități în catalogul Known Exploited Vulnerabilities, prin două alerte separate. Toate trei au aceeași dată limită pentru agențiile federale americane, 19 septembrie, și toate trei sunt marcate cu cerință de triaj forensic, ceea ce înseamnă că nu este suficient să aplici patch-ul și să treci mai departe.

Ce le leagă dincolo de dată este locul unde stau în organizație. Un appliance de control al accesului la rețea, un plugin de backup pe un panou de hosting și flota de telefoane. Niciunul dintre aceste trei lucruri nu se află de obicei în conducta principală de patch-uri, iar asta este exact problema.

Cisco ISE: chiar mecanismul care decide cine intră în rețea

CVE-2026-76460 este o ocolire de autentificare în Cisco Identity Services Engine. Conform advisory-ului cisco-sa-ISE-ABP-VNSW7Tn5, publicat pe 16 septembrie, un control de autentificare insuficient pe un endpoint de API permite unui atacator neautentificat și de la distanță să trimită o cerere creată special și să obțină acces neautorizat la dispozitiv, ocolind interfața web de management. Cisco a evaluat problema cu CVSS 3.1 de 10.0, pe vectorul AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H. Sunt afectate atât ISE, cât și ISE Passive Identity Connector, indiferent de configurația dispozitivului.

Miza este ce face produsul. ISE este mecanismul care decide ce dispozitive și ce utilizatori primesc acces la rețea și în ce segment ajung. Un dispozitiv care ocolește autentificarea pe exact acest sistem nu este o breșă într-o aplicație oarecare, ci în arbitrul politicii de acces. Cisco precizează de asemenea că exploatarea reușită poate duce la execuție de comenzi cu privilegii root.

Cisco spune direct că PSIRT are cunoștință de exploatare activă, iar vulnerabilitatea a fost descoperită în timpul rezolvării unui caz de suport TAC. Merită reținut ce afirmă furnizorul și ce nu: Cisco spune unde a fost găsit defectul, nu numește nicio victimă și nu publică amploarea exploatării. Unele publicații au dedus din originea în TAC că un client era deja compromis. Este o deducție rezonabilă, dar rămâne o deducție, nu o afirmație a furnizorului.

Ce aplici, ce verifici și ce nu ține loc de patch la ISE

  • ▸Versiunile corectate sunt 3.1 Patch 12, 3.2 Patch 11, 3.3 Patch 12, 3.4 Patch 7 și 3.5 Patch 4, fiecare pe ramura corespunzătoare. Nu ramura contează, ci nivelul de patch.
  • ▸ISE 3.0 a ajuns la End of Software Maintenance. Pentru acele instanțe nu există patch pe ramura curentă; Cisco recomandă migrarea către o versiune suportată care include corecția. Dacă ai ISE 3.0 în producție, aceasta este o decizie de migrare, nu o sarcină de actualizare.
  • ▸Nu există workaround. Există o singură măsură de reducere a expunerii recunoscută de Cisco: liste de control al accesului la infrastructură care permit doar traficul necesar de management și plan de control către dispozitiv. Este o măsură temporară, nu o remediere, și trebuie documentată ca atare.
  • ▸Într-o instalare distribuită, fiecare nod este un activ separat. Inventariază-le individual, cu rol, versiune, nivel de patch și momentul verificării.
  • ▸Avizul face parte dintr-un pachet publicat de Cisco pe 16 septembrie, anunțat în Cisco Advance Notification for Publication of September 16, 2026. Verifică lista completă pentru celelalte produse din estate, plus nota separată privind Cisco ISE Security Hardening Release pentru septembrie 2026.

Căutarea de indicatori în ISE, cu limitele ei declarate

Cisco recomandă analizarea access.log pentru nume de utilizator suspecte și oferă un exemplu explicit neexhaustiv: comanda show logging application ise-kong/access.log filtrată după un nume de utilizator de test. Verificarea trebuie făcută pe fiecare nod din instalare. Pentru loguri suplimentare, advisory-ul indică o colectare de support bundle cu debug logs incluse, criptare cu cheie partajată, iar apoi decriptare și căutare în arhivele de access log din directorul de apigateway.

Limita este declarată chiar de furnizor și este aceeași ca la alte compromiteri cu privilegii root: la acest nivel de acces, dovezile și indicatorii pot fi șterse sau ascunse de atacator. De aceea Cisco recomandă corelarea cu logurile de rețea și de firewall din afara dispozitivului, căutând încărcări neașteptate inițiate de aparat către adrese externe sau descărcări de la adrese malițioase. Un access.log curat este o informație utilă, nu o dovadă.

Un punct pe care merită să nu îl treci cu vederea: dacă suspectezi activitate malițioasă, recomandarea Cisco nu este să actualizezi și să continui. Advisory-ul spune că este recomandat insistent să reinstalezi de la zero nodurile afectate și să restaurezi din backup de configurație dacă este necesar. Aceasta schimbă complet planificarea, pentru că reinstalarea unui nod ISE într-o instalare distribuită are consecințe asupra serviciului de autentificare al rețelei.

Acronis Backup: escaladare locală, nu poartă de intrare

CVE-2026-87886 afectează pluginul Acronis Backup pentru cPanel și WHM și extensia pentru Plesk, pe Linux. Advisory-ul SEC-10986 îl descrie ca escaladare locală de privilegii din cauza unor permisiuni de fișier nesigure, clasificat CWE-276, cu scor CVSS 7.8. Vectorul merită citit cu atenție: AV:L și PR:L înseamnă acces local și privilegii reduse deja obținute. Nu este un punct de intrare din internet. Este pasul următor după ce cineva are deja un cont limitat pe mașină, adică exact modelul de amenințare al unui server de hosting partajat.

Acronis confirmă exploatarea: potrivit advisory-ului, exploatarea a fost detectată în sălbăticie în atacuri limitate și țintite împotriva instalărilor pluginului pentru cPanel și WHM. Formularea este precisă și merită păstrată ca atare. Este limitată și țintită, iar exploatarea observată este numită pentru pluginul cPanel și WHM, nu pentru extensia Plesk, deși ambele sunt afectate de vulnerabilitate.

Versiunile de verificat sunt build-uri, nu numere de versiune rotunde: pluginul pentru cPanel și WHM înainte de build 1.9.3.1021 și extensia pentru Plesk înainte de build 1.8.11.638. Actualizările publicate sunt versiunea 1.9.3 HF3 a pluginului și versiunea 1.8.11 a extensiei.

Pentru un audit intern, acesta este momentul să pui o întrebare mai largă decât CVE-ul: cine deține uneltele de backup, sub ce cont rulează, cu ce permisiuni sunt scrise fișierele lor și cine are cont pe mașina care le găzduiește. Un instrument de backup compromis nu este doar încă un activ; este calea de recuperare pe care te bazezi când altceva merge prost.

Google Pixel: nivelul de patch, nu versiunea de Android

CVE-2026-58704 este o problemă de autorizare incorectă în modemul celular al dispozitivelor Pixel. Conform catalogului KEV, o eroare de logică poate permite ocolirea verificărilor de permisiuni și escaladarea privilegiilor. Buletinul Pixel pentru 2026-09-01, publicat pe 15 septembrie, o clasifică drept High și o atribuie componentei Modem.

Formularea Google despre exploatare este prudentă și trebuie citată ca atare: există indicii că CVE-2026-58704 ar putea fi sub exploatare limitată și țintită. Sunt indicii, nu confirmare, și este limitată și țintită, nu masivă. Diferența contează dacă cineva din organizație trebuie să decidă între o actualizare de urgență a flotei și ciclul normal.

Verificarea corectă nu este versiunea de Android, ci nivelul de patch de securitate al dispozitivului, care trebuie să fie 2026-09-05 sau ulterior. Este o distincție practică importantă: două telefoane pot raporta aceeași versiune majoră de sistem și niveluri de patch diferite, iar doar cel din urmă spune dacă remedierea este prezentă.

Dacă ai o flotă gestionată, aceasta este o interogare de MDM, nu un e-mail către utilizatori. Dacă nu ai, întrebarea utilă este cine răspunde de telefoanele care accesează date ale organizației și cum ai afla dacă sunt actualizate.

Ce înseamnă KEV aici și dovada minimă pentru închidere

Termenul de 19 septembrie obligă agențiile federale civile din Statele Unite, sub Binding Operational Directive 26-04. Pentru organizațiile private și pentru cele din Europa nu este o obligație legală, ci un semnal despre cât de repede consideră autoritatea că trebuie acționat. Toate trei intrările înregistrează utilizarea în campanii ransomware ca fiind necunoscută, ceea ce înseamnă necunoscut, nu absent. Toate trei sunt marcate cu cerință de triaj forensic, adică așteptarea este să verifici dacă sistemul a fost compromis înainte de aplicarea corecției, nu doar să corectezi.

  • ▸Inventarul nodurilor ISE, cu rol în instalarea distribuită, versiune și nivel de patch observate, expunerea de management și momentul verificării.
  • ▸Decizia pentru instanțele ISE 3.0: plan de migrare cu termen și responsabil, nu o linie de excepție fără dată.
  • ▸Orice restricționare prin liste de control al accesului la infrastructură, marcată explicit ca măsură temporară de reducere a expunerii.
  • ▸Build-urile observate pentru pluginul și extensia Acronis, actualizarea aplicată și cine deține instrumentul de backup pe fiecare mașină.
  • ▸Nivelurile de patch ale flotei de dispozitive, cu numărul celor sub 2026-09-05 și planul pentru ele.
  • ▸Domeniul căutării de indicatori pentru ISE, nodurile acoperite, retenția disponibilă, logurile externe consultate și limitele explicite ale investigației.
  • ▸Pentru orice suspiciune la ISE: dovezile păstrate înainte de reinstalare, decizia de recuperare și rezultatul verificărilor funcționale după revenirea în serviciu.

Trei locuri pe care conducta de patch le sare

Dacă privești cele trei împreună, nu ai o temă de atacator comun și nici o campanie. Ai trei categorii de active care scapă din procesul obișnuit. Appliance-ul de securitate este administrat de echipa de rețea și actualizat în ferestre rare. Pluginul de backup a fost instalat odată, de cineva, pe un panou de hosting, și de atunci funcționează. Telefoanele aparțin oamenilor și sunt actualizate când se actualizează.

Întrebarea utilă după această zi nu este dacă ai corectat cele trei CVE-uri, ci dacă ai știut în cât timp dacă te privesc. Dacă răspunsul a cerut trei conversații cu trei echipe diferite, aceea este constatarea de reținut, nu CVE-ul.

Începe de la cine deține activul

Folosește contextul CVE și KEV din Awarely Monitor pentru prioritate și responsabil, apoi verifică în mediul tău nivelurile de patch, build-urile și logurile fiecărui nod.