Breșa de autorizare din Drupal Commerce Core este exploatată activ

Magazinele online construite pe Drupal Commerce sunt vizate printr-o vulnerabilitate de autorizare de nivel „highly critical” în modulul Commerce Core. Echipa de securitate Drupal a confirmat că problema este deja exploatată, iar versiunile corectate sunt disponibile pentru ambele ramuri suportate.

Ce s-a întâmplat

Vulnerabilitatea, identificată ca CVE-2026-118539, este o lipsă de autorizare în Commerce Core, modulul care oferă unui site Drupal coșul de cumpărături, fluxul de checkout și API-urile folosite de magazinele decuplate (headless). Anumite rute și câmpuri de entitate nu sunt protejate corespunzător, astfel că o cerere care ar trebui respinsă poate trece. Rezultatul practic este o ocolire a controlului de acces care poate lovi direct comerciantul la buzunar.

Versiuni afectate:

• Commerce Core 2.x (ramura 8.x-2.x), până la 2.41 inclusiv
• Commerce Core 3.x, înainte de 3.3.13

Nu a fost atribuit încă un scor CVSS, dar echipa de mentenanță a evaluat problema drept „highly critical”, nivelul maxim pe scara de severitate Drupal. Exploatarea în mediul real a fost confirmată. Nu există detalii publice despre cine se află în spatele atacurilor, câte magazine sunt afectate sau ce fac atacatorii odată intrați.

De ce contează

Modulele de comerț stau exact pe traseul banilor. O breșă de autorizare în acest strat nu este un risc abstract: în funcție de rutele și câmpurile expuse, un atacator ar putea citi sau modifica comenzi, altera prețuri și promoții sau accesa date ale clienților care în mod normal cer un cont autentificat.

Acest tip de atac este și tăcut. Nu există malware de detectat și nicio cădere de serviciu care să atragă atenția, doar cereri HTTP care arată ca traficul obișnuit al magazinului. Dacă detecția se bazează pe anomalii în comportamentul serverului, o ocolire de acces poate rula săptămâni întregi neobservată.

Actualizările de securitate Drupal sunt analizate invers foarte rapid. Odată ce corecția este publică, diferențele din cod le arată atacatorilor exact unde să caute, motiv pentru care intervalul dintre „aviz publicat” și „exploatare în masă” se scurtează constant.

Între timp, PHP2Shell este în continuare testat

Avizul Drupal vine în timp ce două vulnerabilități critice din PHP, CVE-2026-109618 și CVE-2026-109619 (ambele cu CVSS 9.2, cunoscute împreună ca PHP2Shell), continuă să atragă tentative de exploatare.

La 25 octombrie, aproximativ 52% dintre organizațiile monitorizate erau încă considerate semnificativ expuse, o cifră în scădere, dar departe de zero. Se remarcă două tipuri de activitate: tentative care reproduc lanțul public de proof-of-concept și unelte „marca PHP2Shell” care se bazează de fapt pe otrăvirea sesiunilor și pe o vulnerabilitate separată de tip local file inclusion, nu pe bug-urile din PHP.

Vestea bună, deocamdată, ține de fiabilitate. Epuizarea memoriei singură nu finalizează lanțul, iar diferențele dintre build-urile PHP, limitele de memorie și comportamentul proceselor worker strică adesea etapele ulterioare. Vestea proastă este că atacatorii oportuniști lucrează activ să transforme PoC-urile publice în unelte de încredere, iar istoria arată că de obicei reușesc.

Ce este de făcut

1. Actualizați Commerce Core astăzi. Treceți site-urile 3.x la 3.3.13 și pe cele 2.x la 8.x-2.41. Tratați schimbarea ca pe o urgență, nu ca pe o lucrare planificată.
2. Dacă nu puteți actualiza imediat, restricționați accesul la rutele Commerce la nivel de reverse proxy sau WAF, verificați permisiunile rolurilor anonim și autentificat și luați în calcul suspendarea checkout-ului pentru cele câteva ore necesare unui deploy.
3. Căutați urme de abuz. Verificați jurnalele web pentru cereri neautentificate sau cu privilegii reduse către rutele de comenzi, plăți, promoții și produse și urmăriți modificările neașteptate de prețuri, reduceri, comenzi sau date de clienți.
4. Închideți și breșa din PHP. Confirmați că runtime-ul PHP de pe fiecare server web este la o versiune care corectează PHP2Shell și căutați eventuale probleme de local file inclusion în propriul cod, pentru că pe ele se sprijină o parte din uneltele folosite în atacuri reale.
5. Cunoașteți fiecare instanță Drupal pe care o dețineți. Site-urile de staging, demo și cele de marketing uitate rulează adesea același modul Commerce, fără niciuna dintre protecțiile din producție.

Vulnerabilități precum CVE-2026-118539 sunt exact ceea ce serviciul nostru de scanare de vulnerabilități este construit să scoată la iveală: identifică versiunile învechite de Drupal și de module contribuite pe toate host-urile publice, astfel încât un checkout vulnerabil este semnalat înainte să îl găsească altcineva.