Știri
Știri din categoria Securitate cibernetică
Închiderea preventivă a unor platforme publice din Europa arată cât de rapid poate AI să transforme vulnerabilități vechi în risc operațional imediat, forțând instituții și organizații să oprească servicii online până la aplicarea actualizărilor, potrivit Mediafax.
Măsurile au fost luate după identificarea, cu ajutorul instrumentelor bazate pe inteligență artificială, a două vulnerabilități critice în PHP, limbaj de programare folosit pe scară largă pentru site-uri și aplicații web. Experții avertizează că atacatorii încearcă deja să exploateze problemele, iar impactul s-a văzut în întreruperi care au atins inclusiv spitale și servicii publice.
În Olanda, autoritățile au suspendat preventiv accesul la mai multe platforme, inclusiv Overheid.nl (portalul serviciilor guvernamentale) și MijnOverheid.nl (comunicarea dintre cetățeni și administrație). Au fost menționate ca afectate și organizații precum Portul Rotterdam, federația națională de fotbal, partide politice și spitale.
În alte state, reacția a fost similară: Franța a închis temporar site-urile prefecturilor până la actualizări, Finlanda a suspendat servicii online guvernamentale, iar Germania a dezactivat mai multe site-uri federale. Belgia (Ministerul de Externe) și Cehia au raportat măsuri comparabile.
În afara administrației publice, Fundația Wikimedia a anunțat suspendarea preventivă a unor sisteme până la instalarea remedierilor, iar Internet Archive a fost indisponibil temporar. Autoritățile au precizat că oprirea preventivă nu înseamnă automat că site-urile au fost compromise.
Problemele au fost identificate independent de cercetători ai companiilor Calif și Wiz, care au folosit instrumente bazate pe inteligență artificială, inclusiv modele dezvoltate de Google și OpenAI. Potrivit Wiz, vulnerabilitățile existau în codul PHP de mai bine de un deceniu, dar ar fi fost foarte greu de exploatat prin metode tradiționale.
Cele două vulnerabilități, evaluate la 9,2 din 10 ca gravitate, pot permite executarea de cod malițios de la distanță, fără autentificare, pe serverele vulnerabile. Cloudflare a raportat apariția unor tentative de atac, iar Amazon a anunțat că a detectat o încercare de exploatare încă din 17 octombrie, înainte de dezvăluirea publică.
Dezvoltatorii PHP au publicat miercuri remedierile și au recomandat instalarea imediată. CERT-EU (echipa de răspuns la incidente cibernetice a instituțiilor UE) recomandă suspendarea temporară a sistemelor vulnerabile atunci când actualizarea nu poate fi aplicată rapid.
Potrivit companiei Censys, aproximativ 1,5 milioane dintre cele 2,6 milioane de servere identificate ca utilizând PHP raportau versiuni pentru care nu exista o remediere disponibilă. În acest context, specialiștii avertizează că publicarea detaliilor tehnice și folosirea AI pot accelera dezvoltarea atacurilor împotriva serverelor care rămân neactualizate.
Recomandate
Două vulnerabilități critice din PHP pot permite preluarea serverelor fără autentificare , iar remedierea nu ține de „ai PHP 8.3 în panou”, ci de versiunea exactă instalată și folosită efectiv de site, potrivit Mobilissimo . Actualizările de urgență au fost publicate de echipa PHP după ce mai multe site-uri guvernamentale europene au fost oprite preventiv, conform Reuters. Servicii publice din Franța, Olanda, Finlanda și Danemarca au fost afectate, iar unele instituții au ales să își scoată temporar paginile de pe internet până la instalarea corecțiilor. Miza operațională este directă: breșele permit rularea de cod de la distanță fără cont, parolă sau acces anterior la server. Versiunile PHP care trebuie instalate pentru remediere Nu este suficient să apară în interfață „PHP 8.2/8.3/8.4/8.5”. Contează „ultima cifră” a versiunii, iar prima versiune remediată diferă pe fiecare ramură: Ramura PHP Versiuni vulnerabile Prima versiune remediată PHP 8.5 sub 8.5.12 8.5.12 PHP 8.4 sub 8.4.27 8.4.27 PHP 8.3 sub 8.3.36 8.3.36 PHP 8.2 sub 8.2.35 8.2.35 PHP 8.1 sau mai vechi ramuri ieșite din suport upgrade sau corecție confirmată de furnizor Echipa PHP a publicat detaliile actualizărilor aici: php.net . Pentru ramurile vechi (PHP 8.1, 8.0, 7.4) sunt menționate corecții minimale, în special pentru cei care compilează PHP din sursă, însă recomandarea rămâne migrarea către o ramură suportată. Un detaliu important pentru companii: unele distribuții Linux și servicii cu suport pe termen lung (LTS) pot livra corecții prin „backport” (integrarea patch-ului fără schimbarea versiunii afișate ca număr). În acest caz, furnizorul trebuie să confirme explicit că a remediat CVE-2026-109618 și CVE-2026-109619 . De ce riscul este greu de „acoperit” din aplicație Cele două vulnerabilități au scor 9,2 din 10 și pot ajunge la executarea de comenzi pe server. Prima exploatează felul în care PHP gestionează lipsa memoriei în timpul procesării unei cereri (inclusiv scenarii cu upload), iar a doua poate expune date interne vechi către o cerere ulterioară. Sunt expuse instalările care servesc pagini web prin: PHP-FPM Apache cu mod_php php-cgi FrankenPHP LiteSpeed Configurațiile mod_php sunt descrise ca fiind cele mai riscante. PHP avertizează că atacul demonstrat poate fi declanșat înainte ca aplicația să înceapă să ruleze, ceea ce înseamnă că un plugin de securitate WordPress sau un firewall la nivel de aplicație poate să nu apuce să intervină. Ce ar trebui să verifice firmele cu site-uri WordPress Actualizarea WordPress, a temei și a pluginurilor nu repară PHP, pentru că PHP rulează la nivelul serverului. Pe WordPress, versiunea activă poate fi verificată din: Unelte → Sănătate site → Informații → Server → Versiune PHP Documentația WordPress despre ecranul „Sănătate site” este aici: wordpress.org . Publicația atrage atenția că nu trebuie folosită doar versiunea selectată în panoul de hosting: serverul poate avea mai multe versiuni PHP instalate, iar site-ul să ruleze pe un pool PHP-FPM mai vechi. Pentru găzduire shared sau managed, pașii recomandați sunt: verificarea versiunii utilizate efectiv de site, nu doar a celei „disponibile” în panou; confirmarea de la furnizor că patch-urile pentru cele două CVE-uri au fost instalate; verificarea dacă este necesară selectarea manuală a noii versiuni; backup complet înainte de schimbare; testarea formularelor, uploadurilor, comenzilor și panoului de administrare după actualizare. Dacă nu poți actualiza imediat: izolarea, nu „măsuri cosmetice” PHP indică faptul că nu există o metodă completă de protecție în afara update-ului. Limitarea uploadurilor, dezactivarea session.upload_progress și filtrarea cererilor mari pot reduce anumite căi de atac, dar nu securizează serverul și pot afecta funcționarea site-ului. Dacă actualizarea nu poate fi făcută imediat, CERT-EU recomandă izolarea aplicației de internet sau oprirea temporară; recomandarea este publicată în acest buletin: CERT-EU . După instalarea patch-ului, ar trebui verificate logurile, fișierele modificate recent, conturile administrative nou-create și procesele necunoscute; dacă există semne de compromitere, simplul update nu elimină codul malițios deja instalat. AI-ul scurtează fereastra dintre patch și atac Breșele au fost raportate după o cercetare realizată de Calif împreună cu OpenAI, folosind GPT-5.6 Sol, iar Wiz a identificat independent vulnerabilitățile cu sistemul Atlas și alte modele AI. Odată publicate patch-urile, aceeași automatizare poate accelera compararea codului și construirea rapidă a unui exploit, reducând timpul în care organizațiile mai pot reacționa înainte să apară atacuri la scară. În practică, întrebarea utilă pentru furnizorul de hosting nu este „am PHP 8.3?”, ci dacă site-ul rulează PHP 8.3.36 (sau pachetul echivalent cu patch) și dacă sunt remediate explicit CVE-2026-109618 și CVE-2026-109619 . Dacă furnizorul nu poate confirma, serverul trebuie tratat ca vulnerabil. [...]
Cloudflare vrea să facă certificatele TLS „rezistente la cuantic” disponibile în masă, fără costuri suplimentare și fără penalizări de performanță , printr-o schimbare de arhitectură care ar putea rescrie modul în care web-ul își validează identitatea site-urilor, potrivit Ars Technica . Compania spune că plănuiește să emită certificate TLS „quantum-proof” (concepute să reziste atacurilor posibile cu ajutorul calculatoarelor cuantice), devenind una dintre primele autorități care fac acest pas. Abordarea se bazează pe o platformă open-source care emite atât certificate TLS clasice, cât și o variantă post-cuantică numită „Merkle Tree Certificates”. Cloudflare afirmă că aceste certificate hibride vor fi gratuite atât pentru clienții plătitori, cât și pentru cei neplătitori. De ce contează: schimbarea nu e „un algoritm nou”, ci o reconstrucție a WebPKI Miza este protejarea WebPKI (infrastructura de chei publice a web-ului, care stă la baza autentificării site-urilor și a HTTPS) într-o lume în care semnăturile criptografice clasice ar putea deveni vulnerabile. Cloudflare descrie tranziția ca pe un efort de durată, care implică un număr foarte mare de ingineri și organizații din ecosistem: sisteme de operare, browsere, autorități de certificare și furnizori de infrastructură Internet. Un obstacol major: semnăturile „quantum-proof” ar fi greu de transportat în cererile web și de înregistrat în jurnalele de transparență (mecanisme publice care ajută la detectarea certificatelor false). În plus, articolul notează că o versiune „post-cuantică” a certificatelor X.509 de azi ar crește de aproximativ 40 de ori volumul de date necesar pentru un „TLS handshake” (negocierea inițială a conexiunii securizate), ceea ce ar adăuga costuri de calcul și trafic care „ar strica Internetul așa cum îl știm”. Cum încearcă Cloudflare să evite costul de performanță: Merkle Trees și certificate hibride Soluția prezentată se bazează pe „Merkle Trees” (structuri ierarhice care folosesc funcții hash pentru a verifica volume mari de informații cu o cantitate mică de date). În februarie, Google a anunțat această direcție, iar Google și Cloudflare au testat-o în programe pilot limitate, potrivit materialului. În loc să înlocuiască lanțurile actuale de semnături (considerate vulnerabile la cuantic) cu unele rezistente, dar „prea grele”, modelul folosește dovezi compacte bazate pe Merkle Trees. Ideea este că o autoritate de certificare semnează un singur „tree head” care poate reprezenta milioane de certificate, iar browserul verifică un „landmark” – o dovadă „ușoară” că certificatul se află undeva în arbore. Cloudflare susține că, astfel, volumul de date din handshake ar coborî la circa 40 kilobytes, „aproximativ cât se procesează acum”. Pașii operaționali: achiziția unui root de încredere și integrarea cu logurile de transparență Pentru a accelera adoptarea, Cloudflare spune că va achiziționa un „certificate root” deja de încredere de la CA GlobalSign. Ținta declarată este ca „milioane de site-uri” să poată activa certificate post-cuantice „la o apăsare de buton”, fără costuri suplimentare de performanță. Un alt element important este legarea mai strânsă a emiterii de certificate de „certificate transparency logs” – registre publice append-only (în care se pot adăuga înregistrări, dar nu se pot modifica retroactiv) folosite pentru a detecta certificate emise abuziv. În modelul Merkle Tree Certificates, „logarea” devine parte centrală a emiterii, nu un proces separat. Cloudflare o citează pe inginerul Mari Galicer: „Prin cuplarea emiterii și logării, transparența devine o cerință de funcționare, nu un adaos.” Contextul acestor loguri vine din incidente precum compromiterea DigiNotar din 2011, când au fost create 500 de certificate contrafăcute pentru Google și alte site-uri, unele folosite pentru spionarea utilizatorilor web din Iran, notează articolul. Calendar: când ar putea începe emiterea Cloudflare precizează că nu emite încă aceste certificate și că va mai dura până va începe efectiv, dar își asumă public proiectul și promite actualizări pe măsură ce atinge etape intermediare. Compania se așteaptă să înceapă emiterea în primul trimestru din 2027. În paralel, planul include și utilizarea ACME (Automated Certificate Management Environment), un mecanism open-source pentru emiterea și reînnoirea automată a certificatelor înainte de expirare, precum și un mecanism prin care semnăturile ar putea fi livrate „out-of-band” (pe o cale separată, de exemplu printr-un update de browser) dacă apar probleme tehnice care împiedică obținerea actualizărilor necesare. [...]
Amenințările Iranului privind cablurile submarine din Strâmtoarea Hormuz ridică un risc operațional direct pentru conectivitatea de date și pentru fluxurile comerciale digitale din regiune, într-un context de escaladare militară început în februarie, potrivit Tom's Hardware . Generalul Hossein Mohebbi, purtător de cuvânt al Corpului Gardienilor Revoluției Islamice (IRGC), a declarat la un eveniment din această săptămână că mai multe cabluri submarine de fibră optică din zonă ar fi „ținte noi legitime” pentru atacuri viitoare, relatează The Telegraph . În aceeași relatare, Mohebbi susține că „șapte cabluri mari” trec pe sub Strâmtoarea Hormuz și că „toate datele de internet și comerciale” ar trece prin acestea. De ce contează pentru companii: un punct de vulnerabilitate pentru date și operațiuni Dincolo de dimensiunea militară, mesajul IRGC indică o posibilă extindere a conflictului către infrastructura critică de comunicații. În termeni practici, cablurile submarine sunt coloana vertebrală a traficului internațional de date, iar o întrerupere în Strâmtoarea Hormuz ar putea afecta conectivitatea și continuitatea operațiunilor pentru companii care depind de transferuri de date transfrontaliere (servicii digitale, plăți, logistică, comunicații corporative). Sursa nu oferă detalii tehnice sau un calendar privind un atac, iar afirmațiile despre volumul de trafic („toate datele”) nu sunt însoțite de date independente în textul citat. Ce semnal transmite IRGC: represalii dacă infrastructura Iranului este lovită Separat, un alt general IRGC, Yadollah Javani, adjunct politic al organizației, ar fi sugerat că, dacă infrastructura iraniană este atacată, Iranul ar răspunde prin atacarea cablurilor, potrivit unor comentarii relatate de Iran International . În acest stadiu, informația rămâne la nivel de amenințare și condiționare, însă include explicit infrastructura de telecomunicații ca posibilă țintă, ceea ce crește riscul perceput pentru operatori și pentru companiile cu expunere operațională în regiune. [...]
Google va condiționa reclamele financiare din SUA și Canada de o verificare suplimentară a autorizării , într-o mișcare care ridică pragul de conformare pentru bănci și alți furnizori legitimi, dar urmărește să reducă impersonarea de brand și fraudele din publicitate, potrivit Google Blog . Măsura extinde programul „ Financial Services Verification ” (verificare pentru servicii financiare) în două piețe nord-americane, pe baza unui mecanism existent de verificare a identității advertiserilor. Google spune că, în SUA și Canada, peste 97% dintre reclamele văzute pe Google provin deja de la advertiseri cu identitatea verificată. Ce se schimbă pentru advertiserii din servicii financiare Pe lângă verificarea identității, noul strat de control introduce o verificare specializată a acreditărilor: advertiserii vor trebui să demonstreze că sunt autorizați de autorități de reglementare relevante sau de registre recunoscute înainte de a putea rula anumite reclame financiare. Obiectivul declarat este să limiteze: impersonarea unor instituții financiare (brand impersonation); accesul actorilor rău intenționați la utilizatori prin reclame. Google indică faptul că programul, în forma sa actuală, protejează aproximativ 2 miliarde de utilizatori de internet în 42 de țări, fiind „cel mai amplu program de acest tip”. Implementare etapizată și rolul registrelor bancare Google afirmă că va adapta implementarea în funcție de particularitățile fiecărei țări, invocând diferențe de reglementare și o introducere în etape („phased implementation”). În SUA, compania spune că lucrează cu American Bankers Association pentru a folosi registrul dedicat al acesteia, astfel încât băncile autorizate să fie verificate înainte ca reclamele să poată rula. În Canada, Google menționează colaborarea cu Canadian Bankers Association în pregătirea lansării. Calendar: țintă de lansare la începutul lui 2027 Google indică un „planned rollout” la începutul lui 2027. Înainte de lansare, compania promite informații specifice pe țări pentru advertiseri, inclusiv: registre acceptate, acreditări necesare, instrucțiuni de înrolare (onboarding). După deschiderea verificării, advertiserii vor fi notificați dacă și când trebuie să parcurgă procesul, iar ghidajul ar urma să fie oferit înainte de începerea aplicării (enforcement) politicii. Context: automatizare și colaborare anti-fraudă Google leagă verificarea „upfront” de sistemele sale de siguranță, menționând că în 2025 Gemini a ajutat la identificarea a peste 99% dintre reclamele care încălcau politicile, înainte ca acestea să fie difuzate. Inițiativa este prezentată și ca parte a unor eforturi mai largi de schimb de informații între tehnologie, finanțe și autorități, inclusiv prin Global Signal Exchange. [...]
Aproximativ 421.000 de e-mailuri atribuite AfD ar fi ajuns online după un atac cibernetic , un incident care ridică riscuri operaționale pentru organizații ce își externalizează infrastructura de găzduire și gestionează volume mari de corespondență internă, potrivit G4Media . Atacul ar fi vizat infrastructura de găzduire a partidului german Alternativa pentru Germania (AfD) și ar fi dus la copierea ilegală a unor mesaje din mai multe conturi de e-mail. Publicația germană Bild susține că aproximativ 421.000 de e-mailuri au apărut online, însă autenticitatea datelor nu a fost confirmată. Un purtător de cuvânt al AfD a confirmat pentru Die Zeit că partidul a fost ținta unui atac cibernetic în septembrie 2026 și că persoane necunoscute au copiat ilegal părți din câteva conturi de e-mail. Acesta a mai spus că majoritatea conturilor vizate nu mai fuseseră folosite de ani de zile și că adresele de e-mail actuale ale conducerii federale nu au fost afectate. Ce se știe despre scurgerea de date și ce rămâne neconfirmat Potrivit informațiilor publicate de Bild, autorii presupusei scurgeri de date afirmă că mesajele provin din zece conturi de e-mail. Printre conturile vizate s-ar afla unul asociat cu Alexander Gauland , fost lider al AfD, precum și un alt cont pe care partidul l-ar fi indicat anterior drept punct de contact pentru sediul său federal. În acest stadiu, nu este clar dacă toate mesajele publicate sunt autentice și nici dacă volumul de date prezentat de autori corespunde realității. Răspunsul AfD și pașii următori Purtătorul de cuvânt al partidului a declarat că atacul a fost detectat și oprit într-un interval scurt de timp, iar ulterior persoanele ale căror conturi au fost vizate au fost informate. Investigația este în curs, iar circumstanțele exacte ale atacului și amploarea scurgerii de date nu au fost stabilite definitiv. Până la clarificarea incidentului, autenticitatea și proveniența tuturor datelor publicate rămân incerte. [...]
Google Play Services ar asocia automat numărul de telefon cu toate conturile Google autentificate pe același dispozitiv, fără notificare , ceea ce poate crea o legătură directă între identități pe care utilizatorii încearcă să le țină separate (personal, serviciu, cont „anonim”), potrivit Android Police . Informația pornește de la o sesizare a unui utilizator pe Reddit, preluată de publicație, potrivit căreia Google Play Services ar „verifica” numerele de telefon de pe telefon și le-ar atașa tuturor conturilor Google conectate pe acel dispozitiv ( Android Police notează că subiectul a fost semnalat și „via Android Authority”). Publicația subliniază că nu ar exista un avertisment sau o solicitare explicită de acord. Miza nu este neapărat că datele „se amestecă” între conturi, ci că același identificator (numărul de telefon) devine comun mai multor conturi. Chiar dacă utilizatorul nu vede conținutul unui cont în altul, această asociere poate funcționa ca un „fir” care leagă conturile între ele și de persoana reală din spatele lor — exact opusul separării pe care o urmăresc mulți utilizatori când folosesc mai multe conturi pe același telefon. Ce poți face dacă vrei să reduci asocierea dintre conturi Android Police descrie câțiva pași care ar putea limita sau corecta situația, deși menționează că procesul „ia ceva timp”: Dezactivarea sincronizării/validării automate a numărului de telefon : în aplicația Setări → Google → Toate serviciile → zona Confidențialitate și securitate → opțiunea Verificarea numărului de telefon (denumirile pot varia ușor în funcție de versiunea Android). Verificarea numerelor salvate în cont : în contul Google → secțiunea Informații personale → Telefon , unde pot apărea numere stocate ce pot fi șterse. Repetarea verificărilor pentru fiecare cont Google folosit pe telefon, dacă obiectivul este separarea lor. Context: semnalări inclusiv pe GrapheneOS Autorul notează că utilizatorul de pe Reddit ar fi întâlnit același comportament și pe un dispozitiv cu GrapheneOS (un sistem orientat spre confidențialitate). Publicația tratează situația ca pe un exemplu de practică „deloc surprinzătoare” în ecosistemul marilor platforme, dar accentul rămâne pe consecința practică: utilizatorii care folosesc mai multe conturi pentru separare ar putea descoperi că acestea sunt totuși conectate prin numărul de telefon. Android Police recomandă, în esență, ca cei interesați să verifice rapid ce numere sunt asociate conturilor lor și să ajusteze setările dacă nu doresc această legare automată. [...]
