Social Login WooCommerce: oricine intră ca administrator
Corecția există din 27 iulie. Alerta publică a venit pe 1 august. Iar pe multe magazine n-a ajuns nici acum, pentru că e un plugin cumpărat de pe un magazin de extensii — iar alea nu apar în actualizările automate ale WordPress.
Ce s-a întâmplat. Pluginul „Social Login" pentru WordPress și WooCommerce, în toate versiunile până la 2.8.7 inclusiv, acceptă un document de identitate digitală de la Apple fără să-i verifice semnătura. Cine știe adresa de e-mail a unui administrator poate intra în locul lui. Gravitate: 9,8 din 10.
Pentru cine nu e articolul. Dacă site-ul tău nu e WordPress sau n-ai instalat niciodată un plugin de autentificare cu conturi sociale, nu te privește. Cinci minute de verificare ți-o confirmă.
De ce merită cititul. Pentru că partea grea nu e vulnerabilitatea, ci livrarea corecției. Ea există de zece zile și stă acolo, pe un site de unde nimeni n-o cere.
- Cum se numește exact pluginul și unde te uiți ca să știi dacă îl ai.
- De ce WordPress-ul tău se actualizează singur, iar piesa asta nu.
- Ce verifici dacă pluginul era acolo: actualizarea nu închide subiectul.
- Ce spune registrul public WordPress.org despre alternativele gratuite, interogat azi.
Sunt povești de securitate care încep cu o descoperire. Asta nu. Aici totul e deja rezolvat: cineva a găsit problema, autorul a reparat-o, versiunea corectată a ieșit pe 27 iulie. Singurul lucru care lipsește e drumul dintre corecție și magazinul tău.
Pluginul se numește Social Login, e al autorului WPWeb, se cumpără cu 39 de dolari și în rapoartele de securitate apare ca WooCommerce – Social Login. Falla are codul CVE-2026-8457 și o gravitate de 9,8 din 10, adică practic maximul.
Ne ocupăm de găzduire administrată și de dezvoltare de site-uri și aplicații, deci citim anunțurile astea din meserie. Am mai scris unul asemănător pe 22 iulie, când alarma wp2shell a trezit jumătate din lumea WordPress. Ăsta e mai tăcut și, într-un fel, mai neplăcut.
Cronologia: corecția pe 27 iulie, alerta pe 1 august
Datele spun o poveste pe care buletinele n-o arată, pentru că în buletine apare doar data publicării.
| Data | Ce s-a întâmplat | Unde se citește |
|---|---|---|
| 27 iulie 2026 | Apare versiunea 2.8.8. În jurnalul de modificări scrie: „Fix: Fixed & Improved validation and verification of Apple Sign-In ID tokens" | Fișa produsului pe magazinul de extensii |
| 1 august 2026 | Vulnerabilitatea devine publică sub codul CVE-2026-8457, gravitate 9,8 | Buletin de securitate |
| 2 august 2026 | Avizul intră în baza publică de vulnerabilități, cu descrierea tehnică completă | GitHub Advisory Database |
| 3 august 2026 | Știrea ajunge în presa de specialitate | Search Engine Journal, articol de Roger Montti |
| 7 august 2026 | Fișa produsului arată în continuare 2.8.8 ca ultimă versiune, cu 3.564 de vânzări și prețul de 39 de dolari | Verificat de noi în aceeași zi |
Primele patru rânduri vin din documentele legate. Ultimul e o verificare directă a fișei publice a produsului, făcută pe 7 august 2026: se poate schimba de la o zi la alta.
Cinci zile între corecție și alertă sunt o veste bună: autorul a reparat înainte ca problema să devină publică. Așa ar trebui să funcționeze.
Partea incomodă vine după. 3.564 de vânzări e cifra de pe fișă. Nu sunt 3.564 de site-uri — unele achiziții n-au fost instalate niciodată, altele au ajuns pe mai multe site-uri, iar dintr-un plugin de 39 de dolari circulă și copii luate din altă parte, care prin definiție nu primesc actualizări. Numărul adevărat nu-l știe nimeni, dar direcția erorii e una singură: site-urile expuse sunt mai multe decât vânzările, nu mai puține.
Ce e CVE-2026-8457
Definiție. CVE-2026-8457 este o ocolire a autentificării în pluginul Social Login de la WPWeb pentru WordPress și WooCommerce, prezentă în toate versiunile până la 2.8.7 inclusiv, care permite unui vizitator neînregistrat să obțină o sesiune de administrator știind doar o adresă de e-mail.
Clasificarea tehnică e CWE-289, „ocolirea autentificării prin nume alternativ". Vectorul de gravitate publicat e CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H: atacabil din rețea, complexitate mică, fără privilegii necesare, fără interacțiunea utilizatorului, impact mare pe tot. Fiecare parametru în parte e în căsuța cea mai proastă.
Pe românește: nu trebuie să fii client al magazinului, nu trebuie să ghicești nimic, nu trebuie ca cineva să dea clic pe ceva. Îți trebuie o adresă de e-mail care există deja pe site.
Ce se întâmplă de fapt: ajunge o adresă de e-mail
Când cineva se autentifică prin Apple, Apple emite un document semnat care spune, în esență: „persoana asta chiar e [email protected], garantez eu". E un token, adică un tichet digital cu o semnătură pe el.
Treaba site-ului care primește tichetul e una singură: să verifice semnătura. Apple își publică cheile exact pentru asta. Un tichet fără semnătură validă nu valorează nimic.
Pluginul, în versiunile până la 2.8.7, deschidea tichetul și citea adresa dinăuntru fără să verifice semnătura, și fără să verifice cine l-a emis, pentru cine era valabil și dacă expirase. Apoi căuta adresa aia printre utilizatorii site-ului și deschidea sesiunea. Fără să excludă rolurile — deci și dacă adresa aparținea unui administrator.
E ca un om de la ușă care verifică numele pe listă, dar nu se uită la buletin. Dacă știi cum îl cheamă pe unul de pe listă, intri în locul lui.
Aici e ce face vulnerabilitatea gravă cu adevărat. Adresele administratorilor nu sunt informații confidențiale: stau pe pagina de contact, în răspunsurile la recenzii, în datele publice ale domeniului, în semnătura fiecărui e-mail pe care îl trimite magazinul. Pe multe site-uri WordPress, numele de utilizator al autorului articolelor e public prin construcție.
O apărare care se sprijină pe o informație tipărită pe cărțile de vizită nu e o apărare.
De ce WordPress se actualizează singur și pluginul ăsta nu
Asta e partea care merită articolul, și tot ea e partea pe care aproape nimeni nu i-o explică omului care deține magazinul în loc să-l administreze.
WordPress are un mecanism de actualizare automată care funcționează bine. Dar funcționează pentru piesele care stau în registrul public WordPress.org. Site-ul verifică periodic registrul acela, vede că există o versiune mai nouă și fie o instalează, fie ți-o semnalează.
Un plugin cumpărat de pe un magazin de extensii nu stă în registrul ăla. Site-ul n-are unde să întrebe dacă a apărut ceva nou.
Am verificat, n-am presupus. Pe 7 august am interogat API-ul public al registrului WordPress.org cu sigla pluginului. Răspunsul: {"error":"Plugin not found."}. Acolo nu există.
| Piesa din site | Se actualizează singură? | Ce trebuie să fie adevărat |
|---|---|---|
| Nucleul WordPress | Da, din start | Nimic. Actualizările de securitate pornesc singure, dacă nu le-a oprit cineva |
| Pluginuri din registrul WordPress.org | Da, dacă activezi opțiunea | Un comutator per plugin în ecranul Pluginuri, sau panoul de la găzduire |
| Pluginuri cumpărate de pe un magazin de extensii | Aproape niciodată | Un actualizator livrat de autor plus codul de cumpărare introdus în site — altfel îl descarci și îl încarci de mână |
| Teme și pluginuri făcute pe comandă | Nu | Cine le-a scris. Dacă nu mai există, nimeni |
Rândul evidențiat e cel de care ține vulnerabilitatea asta. E valabil și când actualizatorul există: dacă abonamentul la actualizări a expirat, dacă codul de cumpărare stă în contul unui furnizor cu care nu mai lucrezi sau dacă pluginul a fost instalat încărcând un fișier, versiunea nouă nu ajunge niciodată.
De-aia panoul site-ului tău poate arăta zero actualizări în așteptare în timp ce ai în casă o versiune cu o vulnerabilitate de 9,8. Nu e nimic stricat. Doar că nimeni nu i-a spus unde să se uite.
Panoul de actualizări arată ce știe. Lucrurile pe care nu le știe sunt exact cele pe care nu le verifică nimeni.
Ce spune registrul WordPress.org, verificat azi
Întrebarea care vine imediat e „bine, și atunci ce pun în loc?". Înainte să răspundem din memorie ne-am uitat la starea reală a registrului public: pe 7 august 2026 am interogat API-ul WordPress.org pentru cele mai frecvente sigle de pluginuri de autentificare socială.
| Plugin | Stare în registru | Ultima versiune |
|---|---|---|
| WooCommerce – Social Login (WPWeb) | Nu există: e cu plată, pe magazin de extensii | 2.8.8, din 27 iulie 2026 |
| Nextend Social Login and Register | Activ | 3.1.26, actualizat pe 28 iulie 2026 |
| miniOrange Social Login and Register | Activ | 7.8.1, actualizat pe 22 iulie 2026 |
| Social Login (oa-social-login) | Activ, dar oprit în loc | 5.10.0, actualizat pe 2 decembrie 2024 |
| Super Socializer | Închis pe 18 iunie 2026, „închidere temporară, în așteptarea unei revizuiri complete" | — |
| Wp social (facebook, google, twitter) | Închis pe 25 septembrie 2019, motiv: încălcare de licență sau de marcă | — |
| social-login | Închis pe 6 iunie 2018, motiv: nefolosit | — |
Sursa: API-ul public api.wordpress.org/plugins/info/1.0/<siglă>.json, interogat de pe serverul nostru pe 7 august 2026. Motivele de închidere sunt citate din răspunsul API-ului, traduse. Nu spunem că pluginurile închise ar fi fost nesigure: registrul nu declară asta, iar închiderile se întâmplă și din motive administrative.
Două lucruri sar în ochi. Primul: piața autentificării cu conturi sociale e mult mai subțire decât pare din afară — trei dintre siglele istorice sunt închise. Al doilea e rândul lui oa-social-login: figurează ca activ, dar ultima versiune e din decembrie 2024 și e declarat compatibil doar până la WordPress 6.7.6, când nucleul e la 7.0.3. Cincisprezece ani de meserie se strâng într-o regulă: uită-te la data ultimei actualizări înainte să te uiți la stele.
A treia variantă, cea mai puțin la modă, e să scoți complet autentificarea cu conturi sociale. Pe un magazin mic aduce foarte puțin și adaugă o dependență de trei companii diferite pentru lucrul cel mai delicat de pe site. Nu e o regulă: e o întrebare care merită pusă când te uiți câți clienți o folosesc de fapt.
Ai pluginul? Cum verifici
Trebuie puțin, dar trebuie precis. Sunt zeci de pluginuri care adaugă butoane sociale la autentificare, și doar unul e ăsta.
- Acces la panoul WordPress cu un utilizator administrator.
- Două minute în ecranul Module › Module instalate.
- Numele și autorul, nu doar numele: cauți Social Login cu autorul WPWeb. Numele singur aparține și altor pluginuri, diferite și neimplicate.
- Numărul de versiune, scris sub descriere. De la 2.8.7 în jos ești expus; 2.8.8 sau mai sus e corectat.
- Dacă ai acces la fișiere, dosarul se numește de obicei
woocommerce-social-loginînwp-content/plugins/.
Dacă administrezi mai multe site-uri și ai WP-CLI, răspunsul vine într-o linie pe site:
# listează pluginurile al căror nume conține "social", cu versiune și stare
wp plugin list --format=table --fields=name,status,version | grep -i social
# sau direct: ce versiune am din ăsta?
wp plugin get woocommerce-social-login --field=versionO notă despre pluginul dezactivat, dar rămas instalat. Un plugin dezactivat nu-și execută codul, deci pentru vulnerabilitatea asta nu e exploatabil. Dar rămâne pe disc, și ajunge un clic distrat ca să fie reactivat. Dacă nu-l folosești, se șterge: e cea mai ieftină întreținere care există.
Ce faci diseară, în zece minute
- Vezi dacă îl ai, după nume și autor, ca mai sus. De nouă ori din zece se termină aici și te duci la masă.
- Fă o copie de siguranță înainte să atingi ceva. Dacă găzduirea face copii automate, verifică să existe una de azi.
- Du pluginul la 2.8.8 sau mai sus. Dacă actualizatorul există, un clic. Dacă nu, descarci pachetul din contul tău de pe magazinul de extensii și îl încarci.
- Dacă nu poți actualiza acum — cod de cumpărare pierdut, furnizor de negăsit, site blocat înainte de o lansare — dezactivează pluginul. Magazinul pierde butoanele sociale de la autentificare; clienții intră cu e-mail și parolă, ca întotdeauna.
- Citește lista utilizatorilor administratori. Unul singur pe care nu-l recunoști e destul cât să te oprești și să suni pe cineva.
- Închide toate sesiunile deschise și schimbă parolele administratorilor. Dacă intrase cineva, sesiunea lui moare aici.
- Notează data undeva. Peste șase luni o să vrei să știi când ai verificat.
Pasul 6, pentru cine lucrează din linia de comandă, arată așa — iar a doua comandă e cea care invalidează cu adevărat sesiunile deschise, pentru că schimbă cheile cu care sunt semnate cookie-urile de autentificare:
# listează administratorii: cine există, cu ce e-mail, de când
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered
# închide toate sesiunile tuturor utilizatorilor
wp user session destroy --all --all-users
# regenerează cheile de semnătură: invalidează orice cookie de autentificare existent
wp config shuffle-salts
Cum îți dai seama dacă a intrat deja cineva
Întrebare corectă, iar răspunsul cinstit e că, cu uneltele din dotare, nu poți ști cu certitudine. Poți însă căuta semnele, și sunt mereu aceleași:
- Utilizatori administratori pe care nu-i recunoști, sau utilizatori obișnuiți deveniți administratori. Uită-te la data înregistrării: dacă e veche și rolul e nou, e mai rău, nu mai bine.
- Pluginuri pe care nu le-ai instalat tu, deseori cu nume care sună tehnic și inofensiv.
- Fișiere modificate recent în dosarele WordPress, mai ales în
wp-content/uploads/, unde n-ar trebui să existe nimic executabil. - Autentificări reușite în jurnale, la ore la care nu lucra nimeni. Dacă ai un plugin de securitate cu registru de autentificări, răspunsul e acolo.
- E-mailuri trimise despre care nu știe nimeni, sau domeniul ajuns pe vreo listă neagră de spam.
Dacă găsești fie și un singur semn, calea corectă nu e să cureți și să speri. E să izolezi site-ul, să păstrezi jurnalele și să reconstruiești dintr-o copie anterioară sănătoasă, actualizând înainte să-l repui online. Cine a avut acces de administrator a avut și timp să lase o a doua ușă.
Ce nu repară actualizarea
| Ce face actualizarea | Ce nu face |
|---|---|
| Închide ușa | Nu-l dă afară pe cine e deja înăuntru. Sesiunile deschise rămân valabile până le închizi tu. |
| Repară verificarea semnăturii | Nu șterge utilizatori, pluginuri sau fișiere lăsate de un acces anterior. |
| Te pune la zi azi | Nu schimbă faptul că următoarea actualizare a acelui plugin tot tu va trebui să te duci s-o iei. |
| E valabilă pentru pluginul ăsta | Nu spune nimic despre celelalte piese cumpărate în afara registrului, care au exact aceeași problemă de livrare. |
Ultimul rând merită o după-amiază, o singură dată: fă inventarul pieselor care nu se actualizează singure. Numele, de unde a fost cumpărată, în ce cont stă licența, când expiră. Pe un magazin obișnuit sunt între trei și zece. În ziua în care apare o alertă, lista aia e diferența dintre zece minute și o după-amiază de telefoane.
În aceeași săptămână: WordPress 7.0.3
Pe 6 august a ieșit WordPress 7.0.3, o versiune de securitate care corectează douăsprezece vulnerabilități. Principala e evaluată la 8,9 din 10 și e descrisă așa în buletin: „WordPress is vulnerable to a pre-auth reflected XSS vulnerability on the login screen", cu posibilitatea, în condiții speciale, de a ajunge la execuție de cod. Corecția a fost dusă înapoi până la versiunea 4.7.
Punem cele două știri una lângă alta pentru că împreună spun un singur lucru.
| WordPress 7.0.3 | Social Login 2.8.8 | |
|---|---|---|
| Gravitate | 8,9 | 9,8 |
| Ieșită pe | 6 august 2026 | 27 iulie 2026 |
| Cum ajunge la site-ul tău | Singură, în câteva ore | Doar dacă te duci s-o iei |
| Ce trebuie să faci | Să verifici că a ajuns | Tot |
Surse: anunțul oficial WordPress 7.0.3 și relatarea Search Engine Journal din 6 august 2026, plus avizul CVE-2026-8457 citat mai sus.
Vulnerabilitatea mai gravă dintre cele două e fix cea pe care site-ul tău n-o repară singur. Nu e o coincidență, e regula. Nucleul WordPress are o mașinărie de distribuit actualizări construită în cincisprezece ani. Un plugin de 39 de dolari te are pe tine.
Cuvintele, într-un tabel
| Termen | Ce înseamnă |
|---|---|
| CVE | Codul universal al unei vulnerabilități. Există ca toți să vorbească despre același lucru. |
| CVSS | Punctajul de gravitate de la 0 la 10. Peste 9 înseamnă că se exploatează de la distanță și fără condiții. |
| Ocolirea autentificării | Să intri fără să ai credențialele, nu ghicindu-le. |
| Token (de identitate) | Tichetul semnat cu care un furnizor ca Apple garantează cine ești. |
| Semnătură digitală | Partea din tichet care dovedește că l-a emis chiar cine spune. Trebuie verificată, altfel nu servește la nimic. |
| Sesiune | Faptul de a fi „intrat". Trăiește într-un cookie și rămâne validă până o închizi sau până expiră. |
| Salt / chei de semnătură | Șirurile secrete ale site-ului cu care sunt semnate cookie-urile de autentificare. Schimbarea lor dă pe toți afară. |
Unde te afli, în trei praguri
Dacă nu ai pluginul ăsta, ai terminat în cinci minute și ai câștigat o întrebare utilă: ce alte piese din site-ul meu nu se actualizează singure? Pune-o diseară, cât ești cu gândul acolo.
Dacă îl ai în versiunea 2.8.8 sau mai nouă, ești în regulă pe vulnerabilitatea asta. Merită totuși turul prin utilizatorii administratori: dacă pluginul a stat o vreme pe o versiune veche, nu știi cine a trecut pe acolo.
Dacă îl ai în orice versiune până la 2.8.7, ăsta e cel mai important lucru din seara ta. Actualizezi sau dezactivezi, apoi verifici administratorii, apoi închizi toate sesiunile. În ordinea asta, pentru că închiderea sesiunilor cu ușa încă deschisă nu ajută la nimic.
Iar dacă te întrebi dacă magazinul tău mai are piese în aceeași situație, răspunsul e aproape sigur da. Inventarul ăla e prima zi din orice site pe care îl luăm în găzduire administrată: nu e munca cea mai entuziasmantă din meserie, dar e cea care evită seri ca asta.
Întrebări
Întrebări pe care nu ni le-a pus nimeni
Avizul e de acum câteva zile, deci nu, nu ni le-a pus nimeni încă. Sunt întrebările care îi vin cuiva cu un magazin online și care citește o știre de genul ăsta seara, de pe telefon.
Cum știu în două minute dacă sunt în pericol?
Intri în panoul WordPress, mergi la Module, cauți „social". Dacă apare un plugin numit Social Login cu autorul WPWeb, te uiți la versiune: 2.8.7 sau mai mică înseamnă expus, 2.8.8 sau mai mare înseamnă corectat.
Dacă pluginul ăla nu e acolo, vulnerabilitatea asta nu te privește. Există altele cu nume asemănătoare, de la alți autori: nu sunt implicate.
Am pluginul, dar nu folosesc „Intră cu Apple". Sunt în siguranță?
Nu te baza pe asta. Descrierea publică a vulnerabilității vorbește despre componenta de autentificare Apple din plugin, nu despre o setare bifată în panou. Cod prezent și activ e cod la care se poate ajunge.
Tratează-l ca expus: actualizează sau dezactivează pluginul până poți.
Găzduirea nu mă anunță. Înseamnă că e bine?
Înseamnă că găzduirea n-are vizibilitate pe pluginul ăla, și e normal: nu stă în registrul public, deci uneltele care compară versiunile instalate cu registrul nu-l văd trecând.
Unele servicii de securitate cu plată au baze proprii de vulnerabilități și îl prind. Majoritatea panourilor de găzduire partajată, nu.
Site-ul mi l-a făcut altcineva acum trei ani. Cine răspunde acum?
Din punct de vedere practic, tu — pentru că site-ul e al tău și pierderea e a ta. Din punct de vedere contractual depinde ce ați semnat, iar în majoritatea cazurilor din România nu s-a semnat nimic despre întreținere.
Întrebarea utilă nu e cine e vinovat, ci cine are accesul: cere codul de cumpărare al pluginurilor și accesul de administrator pe cont propriu. Fără ele, ești dependent de disponibilitatea altcuiva exact în seara în care nu răspunde nimeni.
Actualizarea poate strica magazinul?
E o actualizare de întreținere, deci riscul e mic, dar risc zero nu există pe niciun site cu personalizări. Faci o copie înainte, actualizezi, apoi verifici imediat cele două lucruri care contează: că se poate intra în cont și că se poate finaliza o comandă.
Dacă ai un mediu de test, acolo îl încerci. Dacă nu, alegi o oră cu trafic mic — pentru un magazin din România, dimineața devreme.
Am pierdut codul de cumpărare al pluginului. Ce fac?
Codul stă în contul de pe magazinul de extensii al celui care l-a cumpărat: deseori nu tu, ci agenția sau programatorul care a construit site-ul. Cere-i-l, și cere să fie mutat pe un cont al tău.
Dacă drumul ăsta e închis, singura variantă onestă e să dezactivezi pluginul și să-l înlocuiești cu unul întreținut. Recumpărarea la 39 de dolari e oricum mai ieftină decât un site compromis.
Un firewall în față m-ar fi protejat?
Poate, și nu e un răspuns satisfăcător. Unele servicii publică reguli specifice imediat după anunțul unei vulnerabilități cunoscute, iar atunci cererea e oprită înainte să ajungă la site. Dar protecția vine când vulnerabilitatea e deja publică, adică după fereastra cea mai periculoasă.
Un firewall e o a doua ușă bună. Nu e un înlocuitor pentru actualizare, și e util și dintr-un motiv diferit: ce decizi la ușa din față are efecte și asupra celor pe care vrei să-i lași să intre.
Mai merită autentificarea cu conturi sociale, pe un magazin mic?
Depinde câți o folosesc de fapt, iar cifra aia o ai: uită-te câți dintre clienții tăi înregistrați au venit printr-un furnizor social. Dacă sunt o mână de oameni, întreții trei dependențe externe pentru foarte puțin.
Pe un magazin cu mulți clienți care revin, în schimb, reduce frecarea în mod măsurabil. Răspunsul nu e ideologic, e în cifrele tale.
Cât timp am până încearcă cineva cu adevărat?
Pentru vulnerabilitățile cu profilul ăsta — exploatabile din rețea, fără credențiale, pe o platformă răspândită — scanările automate pornesc în zilele de după anunțul public. Nu e nevoie să se fi decis cineva să ți-o facă ție: roboții încearcă toate adresele pe care le găsesc.
Deci răspunsul practic e că fereastra liniștită s-a închis pe 1 august. Nu e un motiv de panică, e un motiv să faci verificarea diseară și nu în weekend.
Cum nu mai ajung aici peste șase luni?
O listă, refăcută o dată pe an: fiecare plugin și temă cumpărate în afara registrului WordPress.org, unde stă licența, în ce cont, când expiră. Douăzeci de minute prima dată.
Apoi o întâlnire lunară de zece minute în care verifici de mână actualizările pentru piesele alea puține. E plictisitor și funcționează.
Ultima actualizare: 7 august 2026. Descrierea tehnică și punctajul de gravitate vin din avizul CVE-2026-8457 publicat pe 2 august 2026 în GitHub Advisory Database, citit în aceeași zi; relatarea de presă e articolul lui Roger Montti din Search Engine Journal, 3 august. Versiunea, data lansării, jurnalul de modificări, numărul de vânzări și prețul pluginului au fost verificate de noi pe fișa publică a produsului pe 7 august 2026. Starea pluginurilor alternative vine din API-ul public WordPress.org, interogat de pe serverul nostru în aceeași zi. Actualizăm pagina dacă apare o versiune ulterioară lui 2.8.8 sau dacă avizul e modificat.
