Știri
Știri din categoria Securitate cibernetică
O vulnerabilitate critică din pluginul Kirki pentru WordPress este exploatată activ pentru preluarea conturilor de administrator, iar riscul operațional pentru site-urile afectate este imediat, în condițiile în care atacul poate fi lansat fără autentificare, potrivit BleepingComputer.
Pluginul vizat, „Kirki - Freeform Page Builder, Website Builder & Customizer”, este activ pe peste 500.000 de site-uri. Problema este o escaladare de privilegii (CVE-2026-8206) care permite atacatorilor să preia orice cont de utilizator, inclusiv conturi de administratori.
Atacurile au fost detectate de firma de securitate Defiant, iar firewall-ul Wordfence a blocat peste 222 de încercări în ultimele 24 de ore, conform informațiilor din articol. Odată obținut acces de administrator, un atacator poate instala pluginuri malițioase, modifica conținutul site-ului, implementa „web shell”-uri (instrumente de control la distanță pe server) sau „backdoor”-uri persistente și poate accesa baze de date private.
Wordfence indică faptul că vulnerabilitatea a fost introdusă într-un „major release”, versiunea 6.0.0, și afectează versiunile până la 6.0.6. Aceste versiuni ar fi folosite de aproape 40% din baza de utilizatori a pluginului, potrivit statisticilor de descărcare de pe WordPress.org citate în material.
CVE-2026-8206 este cauzată de expunerea unui endpoint (punct de acces) din API-ul REST personalizat pentru resetarea parolei, prin funcția „handle_forgot_password()”. Vulnerabilitatea apare deoarece pluginul acceptă o adresă de e-mail arbitrară în cererile de resetare.
În practică, atunci când este furnizat un nume de utilizator, pluginul generează un link valid de resetare pentru contul asociat, dar îl trimite la adresa de e-mail introdusă de atacator, nu la e-mailul înregistrat al proprietarului contului. Astfel, atacatorii neautentificați pot obține linkuri de resetare pentru orice utilizator înregistrat și pot prelua contul.
Vulnerabilitatea a fost descoperită de cercetătorul CHOIGYENGMIN, raportată către Wordfence pe 4 mai 2026. Compania a notificat furnizorul pe 16 mai, iar remedierea a fost livrată în versiunea 6.0.7, pe 18 mai 2026.
În contextul exploatării active și al cerințelor reduse pentru atac, recomandarea este actualizarea imediată la versiunea 6.0.7 sau dezactivarea pluginului, conform articolului.
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. [...]
CodeRabbit își extinde analiza de securitate dincolo de modificările punctuale dintr-un pull request , folosind GPT‑6.1 Sol pentru a corela comportamente între fișiere și componente în baze de cod complexe, potrivit OpenAI . Miza operațională este reducerea „unghiurilor moarte” din revizuirea codului, acolo unde o schimbare aparent minoră poate afecta biblioteci comune, dependențe și mecanisme de protecție din alte zone ale aplicației. Modelul GPT‑6.1 Sol este folosit ca model principal în „agentul de securitate” al CodeRabbit, cu rolul de a extinde revizuirea dincolo de diferențele (diff) dintr-un singur set de modificări. Conform descrierii, Sol ajută la conectarea efectelor unei schimbări între fișiere și componente, pentru a scoate la iveală potențiale probleme de securitate care altfel ar putea trece neobservate. Un element important pentru echipele de inginerie și securitate este poziționarea produsului față de instrumentele existente: revizuirea CodeRabbit este „independentă de agentul care a scris codul” și „completează scanerele consacrate”, iar sistemul mai folosește și alte modele avansate și instrumente de securitate. OpenAI nu oferă însă în material detalii despre rate de detecție, comparații cantitative sau metodologii de evaluare. Cum este folosit Sol în fluxul de lucru Integrarea este descrisă pe mai multe niveluri, în funcție de profunzimea investigației: Pull-request review : Sol analizează schimbările pe măsură ce dezvoltatorii lucrează, în timpul revizuirii unui pull request. Deep Scan : suportă investigații mai ample la nivel de depozit (repository), inclusiv dependențe și interacțiuni între componente. CodeRabbit Secure : extinde investigația către depozite conectate (de exemplu, o bibliotecă de autentificare partajată), pentru a evalua cum o slăbiciune poate afecta un sistem mai larg. De la identificare la remediere, cu „omul în control” OpenAI notează că CodeRabbit folosește GPT‑6.1 Sol pentru a semnala probleme legate de securitate în „mii de depozite și organizații”, iar constatările sunt introduse în fluxurile de pull request pe care dezvoltatorii le folosesc deja pentru revizuire și îmbunătățire. Componenta „Secure” leagă investigația de remediere: pentru constatările selectate de utilizator, sistemul poate încerca verificarea exploatării într-un „sandbox” izolat, fără a testa sisteme de producție. Pentru anumite tipuri de probleme, poate și redacta un pull request cu o propunere de fix, care rămâne de revizuit și aprobat de o persoană. Materialul insistă că responsabilitatea finală rămâne la oameni: revizorii umani decid ce schimbări sunt livrate în producție. Linkuri menționate în sursă Detalii despre GPT‑6.1 Sol: https://openai.com/index/introducing-gpt-6-1-sol/ Detalii despre CodeRabbit Secure: https://www.coderabbit.ai/security [...]
Pentagonul a trecut Institutele Confucius pe lista amenințărilor la securitatea națională , o decizie care poate accelera restricțiile asupra colaborărilor universitare și a accesului la resurse în campusuri, potrivit Agerpres . Departamentul american al Apărării a desemnat centrele culturale finanțate de China din campusurile universitare, cunoscute ca Institutele Confucius, drept o amenințare la adresa securității naționale a SUA. Anunțul a fost făcut vineri de secretarul apărării Pete Hegseth , într-o informație relatată de Reuters și preluată de Agerpres. Ce invocă Pentagonul și ce măsuri spune că a luat Într-un videoclip postat pe rețelele sociale, Hegseth a susținut că Institutele Confucius ar funcționa „sub acoperire” în universitățile americane și că Pentagonul le-a adăugat pe lista instituțiilor considerate o amenințare la securitatea națională. „Se pare că au apărut 80 de noi celule de propagandă în 30 de universități, folosind nume și statute diferite, dar cu aceeași misiune: să fure proprietate intelectuală și să infiltreze mințile studenților americani.” Tot el a afirmat că, în ultimele două luni, Departamentul Apărării a „demontat sistematic” fiecare dintre aceste organizații, fără ca materialul citat de Agerpres să ofere detalii despre mecanismul concret al acestor acțiuni sau despre instituțiile vizate. Context și reacții Washingtonul acuză de mai mult timp Institutele Confucius că ar fi instrumente de propagandă chineză și a luat măsuri pentru a le limita, notează aceeași sursă. Ambasada Chinei la Washington nu a răspuns imediat unei solicitări de comentariu din partea Reuters, conform informațiilor preluate de Agerpres. [...]
Un atac de tip DDoS a provocat probabil întreruperi de internet în Coreea de Nord , blocând timp de circa 32 de ore accesul la zeci de site-uri oficiale, potrivit informațiilor publicate de HotNews , care citează o analiză a companiei americane de monitorizare a rețelelor Kentik . Analiza Kentik indică mai multe valuri de trafic care au venit simultan din două țări și au coincis cu momentul în care site-urile nord-coreene au început să cadă. Doug Madory, director de analiză a internetului la Kentik, a declarat pentru Reuters că vârfurile de trafic au început marți, în jurul orei 11:00 (ora locală), și că „este cu siguranță un atac DDoS (Distributed Denial-of-Service)”, adică o supraîncărcare intenționată a serverelor printr-un volum foarte mare de cereri. Totuși, datele analizate nu indică identitatea autorilor, iar Kentik a evaluat doar o parte din traficul direcționat către Coreea de Nord, ceea ce limitează concluziile privind originea exactă și amploarea atacului. Ce a fost afectat Întreruperile au vizat peste 40 de site-uri oficiale care folosesc domeniul național „.kp”, inclusiv paginile Ministerului Afacerilor Externe și ale agenției de presă de stat KCNA, potrivit presei sud-coreene citate în material. Ipoteze alternative și ce nu pare să fie cauza Presa sud-coreeană a menționat și o posibilă explicație non-cibernetică: experți în securitate au indicat că o alimentare instabilă cu energie electrică ar fi putut contribui la problemele de funcționare. În același timp, căderile din Coreea de Nord „nu par” să fie legate de problemele globale apărute ulterior în săptămână, generate de dezvăluirea unor vulnerabilități în limbajul de programare PHP, potrivit informațiilor din analiză. Context: nu este un incident izolat Rețeaua de internet a Coreei de Nord, strict controlată, a mai fost paralizată și în trecut. Un exemplu menționat este finalul anului 2014, când țara a avut o întrerupere completă de câteva ore, pe fondul tensiunilor legate de o comedie a Sony Pictures despre asasinarea fictivă a liderului Kim Jong Un. [...]
Pentagonul își extinde capabilitățile de „război în umbră” în zona cibernetică , după ce a înființat în secret, în aprilie, o structură dedicată sabotajului tehnologic și perturbării proiectelor din străinătate, potrivit Antena 3 , care citează Politico. Miza, conform materialului, este accelerarea operațiunilor „agresive” în afara SUA, inclusiv potențiale atacuri cibernetice, într-un cadru despre care sursa notează că a fost ținut departe de supravegherea publică. Noua entitate se numește „ Biroul de Sprijin Tehnologic ” (Technology Support Office – TSO) și, până acum, nu a fost menționată public nici de secretarul Apărării, Pete Hegseth, nici de alți oficiali de rang înalt. Informațiile despre TSO ar fi greu de găsit pe site-urile Pentagonului, iar agenția apare doar în câteva documente ale Departamentului Apărării. Ce ar face TSO și de ce contează operațional Potrivit articolului, TSO ar fi fost creat pentru a intensifica activități clandestine care vizează sabotarea sau perturbarea proiectelor tehnologice externe considerate amenințări la adresa superiorității militare a SUA. În această logică, agenția ar urma să acopere o plajă mai largă de acțiuni, de la zona cibernetică până la operațiuni de dezinformare și perturbarea lanțurilor logistice. Publicația menționează că TSO nu ar avea autoritatea legală de a desfășura direct operațiuni clandestine, însă ar colabora cu ofițeri superiori militari și de informații pentru a dezvolta instrumente și strategii care să limiteze accesul adversarilor la tehnologii critice de apărare sau să le submineze „de la distanță”. Cum ar fi fost construită agenția și cine a coordonat înființarea Politico afirmă că a discutat, sub anonimat, cu 12 foști și actuali oficiali americani din securitatea națională, inclusiv persoane implicate în înființarea agenției sau care au lucrat îndeaproape cu aceasta. Conform relatării, inițiativa ar fi fost condusă de secretarul adjunct al Apărării, Steve Feinberg , iar un alt oficial implicat ar fi Tom Rakusan, fost agent CIA și consilier principal al lui Feinberg la Pentagon. TSO ar fi rezultat în mare parte din reorganizarea a două departamente secrete care derulau eforturi similare, la scară mai mică, încă din 2023. Instrumente, ținte și buget estimat TSO ar fi format din ingineri, operatori speciali și ofițeri de informații, iar activitatea ar include: dezvoltarea de instrumente și sisteme de hacking personalizate; planificarea de operațiuni de înșelăciune și diversiune; inducerea în eroare a adversarilor pentru a-i determina să instaleze componente concepute de TSO în platforme-cheie și programe ale sistemelor de armament străine. Un fost oficial al serviciului de informații al Pentagonului a estimat pentru Politico un buget de cel puțin 1,5 miliarde de dolari (aprox. 6,9 miliarde lei) pentru TSO. Întrebările de supraveghere și reacția Casei Albe În material sunt menționate și temeri că administrația Trump ar fi evitat deliberat să vorbească public despre TSO pentru a limita supravegherea unor programe care ar putea afecta civili sau ar putea tensiona relațiile cu state cu care SUA nu sunt în război, precum China. Un fost oficial de rang înalt din Pentagon, citat sub anonimat, a ridicat explicit problema controlului și a responsabilității: „Întrebările sunt: Cine aprobă și controlează (o astfel de agenție), cine supraveghează (activitățile sale), cine este informat, pentru ca cetățenii americani să aibă încredere că ceea ce faci tu este în conformitate cu valorile noastre.” Casa Albă, potrivit articolului, a refuzat să comenteze existența agenției și nu a răspuns unei cereri de comentariu privind subiectul. [...]
Exploatarea activă a două vulnerabilități critice din PHP crește riscul de compromitere a NAS-urilor expuse la internet , iar pentru o parte dintre producători nu există încă remedieri complete, potrivit AppleInsider . Miza este operațională: NAS-urile sunt folosite frecvent ca depozit principal pentru fișiere și copii de siguranță, iar un atac reușit poate duce la acces neautorizat și executare de cod de la distanță. Vulnerabilitățile, denumite „PHP2Shell” și urmărite ca CVE-2026-109618 și CVE-2026-109619, pot permite atacatorilor să ruleze cod pe servere afectate fără autentificare. Echipa PHP a publicat actualizări de securitate pe 21 octombrie pentru versiunile 8.2–8.5, însă urgența este amplificată de faptul că Amazon a detectat o tentativă de exploatare pe 17 octombrie, înainte de divulgarea publică. Cine are patch-uri și cine încă lucrează la remedieri Synology a publicat pachete PHP actualizate care adresează problemele. În avizul său de securitate, compania indică drept afectate versiunile PHP 7.3–8.4 și menționează, între altele, Mail Station și Synology Calendar. Actualizările pentru PHP 8.2 și PHP 8.4 sunt disponibile prin Package Center și arhiva de descărcări, însă producătorul recomandă verificarea stării fiecărui pachet afectat, nu presupunerea că totul a fost remediat. Synology face și o distincție importantă pentru administrare: pachetele PHP instalate separat nu sunt același lucru cu componentele PHP integrate în DiskStation Manager, iar compania susține că PHP-ul „încorporat” nu este expus la suprafețe de atac externe, ceea ce ar face exploatarea prin acel component „puțin probabilă”. QNAP a confirmat o plajă mai largă de produse afectate într-un aviz din 22 octombrie, inclusiv QTS 5.2.11 și versiuni anterioare, QTS 6.1.0, mai multe versiuni de QuTS hero și QuTScloud, plus aplicații precum Note Station 3. Compania spune că lucrează la remedieri, dar nu a indicat un termen de livrare. QNAP afirmă că nu are rapoarte de atacuri care să-i vizeze produsele, deși există documentare privind încercări de exploatare a serverelor PHP vulnerabile. Până la apariția patch-urilor, QNAP recomandă reducerea expunerii directe la internet prin: dezactivarea redirecționărilor de porturi neesențiale; dezactivarea UPnP (configurarea automată a porturilor în router); dezactivarea serviciilor de acces la distanță care nu sunt necesare; folosirea unei conexiuni VPN și restricționarea accesului de administrare la rețele de încredere. Publicația notează și că dezactivarea serverului web integrat poate reduce expunerea dacă nu este necesar, dar QNAP avertizează că această măsură nu protejează interfața de administrare a NAS-ului; rămân necesare restricțiile de rețea cât timp software-ul afectat nu este actualizat. Producători unde situația rămâne neclară Pentru TerraMaster , AppleInsider menționează o discuție pe Reddit în care compania a recunoscut problema după ce un utilizator a raportat PHP 7.4.33 în interfața de administrare a unui model F2-425. Într-un răspuns din 22 octombrie, TerraMaster a spus că investighează și testează și lucrează la o soluție, însă nu există încă un patch, iar publicația precizează că nu a confirmat independent dacă acea configurație este exploatabilă. În cazul Ugreen , AppleInsider spune că nu a putut confirma dacă există o actualizare de securitate PHP2Shell pentru UGOS Pro; politica de raportare a vulnerabilităților descrie procesul, dar nu stabilește dacă software-ul NAS este afectat. Pentru Asustor , publicația afirmă că nu a putut confirma existența unui patch PHP2Shell sau o listă definitivă de dispozitive afectate; compania are o pagină de avize de securitate, iar statusul vulnerabilității este indicat ca „în desfășurare”. Riscul operațional ignorat frecvent: containerele Docker Un NAS „la zi” ca sistem de operare poate rula în continuare PHP vulnerabil în aplicații din containere Docker. Acestea pot include propriile instalări PHP, care nu sunt actualizate automat odată cu firmware-ul sau pachetele producătorului. Recomandarea este ca utilizatorii care rulează servicii bazate pe PHP în Docker să verifice imaginile de container pentru versiuni afectate și să instaleze imagini actualizate când devin disponibile; în practică, actualizarea presupune de regulă recrearea containerului pentru a rula software-ul remediat. QNAP avertizează explicit că instalările PHP din Container Station și aplicațiile terțe nu sunt acoperite de actualizările sistemului de operare. Ce urmează și unde e riscul cel mai mare Cea mai mare problemă pe termen lung, potrivit AppleInsider, este la NAS-urile vechi, ieșite din suport , care nu mai primesc actualizări de securitate și pot rămâne vulnerabile pe termen nedefinit. În acest caz, recomandarea este să nu fie expuse la internet interfața de administrare sau alte servicii, chiar dacă dispozitivul poate rămâne util pentru stocare locală. Pentru acces de la distanță, publicația indică folosirea unui VPN în locul expunerii porturilor de administrare și verificarea jurnalelor pentru activitate suspectă, deoarece actualizările nu „repară” un compromis deja produs. [...]
