Pe scurt: Vulnerabilitatea actuală din Magento se numește PHP2Shell și nu se află în Magento, ci în PHP. Un patch Magento nu o închide. După actualizarea PHP, cu repornire, ar trebui să verificați app/etc/env.php, baza de date pentru skimmere și lista conturilor de administrator.
Ce înseamnă PHP2Shell pentru magazinele Magento
Magento Open Source și Adobe Commerce sunt aplicații PHP mari, care rulează de obicei cu PHP-FPM. Potrivit echipei PHP, vulnerabilitățile CVE-2026-109618 și CVE-2026-109619 permit execuția de cod malițios fără autentificare. Faptul că magazinul însuși este actualizat nu joacă niciun rol în acest caz.
Magazinele Magento sunt de ani de zile o țintă preferată pentru skimming-ul de carduri, în care datele introduse la checkout sunt citite pe ascuns. PHP2Shell deschide o cale suplimentară pentru aceasta. Palo Alto Networks a numărat peste 22,6 milioane de instanțe PHP expuse, potențial vulnerabile; ce magazine se află printre ele nu se știe.
Vulnerabilitatea Magento: stabilirea corectă a versiunii PHP
Magento nu afișează versiunea PHP într-un loc vizibil în administrare. Verificați, de aceea, starea în panoul de hosting pentru domeniu sau cereți furnizorului de hosting să o confirme. php -v în linia de comandă arată doar PHP-ul CLI, cu care rulează bin/magento și cronjob-urile. PHP-ul web prin FPM poate fi o altă versiune, iar ambele trebuie să aibă patchul aplicat.
Versiunile upstream remediate sunt 8.5.12, 8.4.27, 8.3.36 și 8.2.35; backporturile distribuțiilor pot purta numere mai vechi. Ce versiuni PHP sunt acceptate de versiunea dumneavoastră de Magento verificați conform cerințelor de sistem din documentația Adobe (experienceleague.adobe.com). La Adobe Commerce pe infrastructura Adobe, întrebați Adobe sau operatorul dumneavoastră despre stare. O instrucțiune pas cu pas oferă Verificarea corectă a versiunii PHP și a stării patchului.
Unde se află codul malițios în Magento
| Loc | Conținut | Punct de verificare |
|---|---|---|
app/etc/env.php |
Baza de date, cheia de criptare, calea de administrare | Data modificării, reînnoiți valorile în caz de suspiciune |
pub/ |
Rădăcina documentelor, pub/media, pub/static |
Fișiere PHP în directoarele media și static |
app/code/ |
Module proprii | Module necunoscute, fișiere modificate |
vendor/ |
Pachete Composer, inclusiv extensii | Abateri față de lockfile |
generated/, var/ |
Cod generat, cache, jurnale | Salvați jurnalele, regenerați codul |
| Baza de date | Configurație, blocuri CMS, utilizatori administrator | Scripturi străine, administratori noi |
La Magento, skimmerele se află adesea în baza de date, de exemplu în setările pentru scripturi suplimentare din antetul sau subsolul paginii și în blocurile CMS. O simplă scanare de fișiere le ratează. Accesările de citire inofensive ajută la o primă privire (prefixul tabelelor diferă în funcție de instalare):
bin/magento info:adminuri
bin/magento module:status
SELECT username, email, created FROM admin_user;
SELECT path, value FROM core_config_data WHERE path LIKE 'design/%' AND value LIKE '%<script%';
Un checkout curățat nu înseamnă că nu s-au scurs date. Salvați jurnalele începând cu 20.10.2026 și copii ale bazei de date înainte de a elimina scripturi. Doar așa se poate stabili ulterior de când și ce comenzi au fost afectate.
Zona de administrare și extensiile
Calea de administrare poate fi aleasă liber în Magento și se află în env.php. O cale greu de ghicit este utilă, dar nu înlocuiește autentificarea în doi pași și nici limitarea la rețele cunoscute. Verificați regulat utilizatorii de administrare și rolurile lor, precum și integrările și token-urile API.
Extensiile de la terți sunt numeroase la Magento: metode de plată, conexiuni ERP, module de căutare și de marketing. Fiecare aduce cod care trebuie verificat la upgrade-urile PHP. Folosiți composer audit regulat și eliminați complet modulele dezactivate.
Gândiți-vă și la procesele de fundal. Magento lucrează cu cronjob-uri și, adesea, cu consumatori de cozi care rulează ca procese PHP separate din linia de comandă. După actualizarea PHP, acestea trebuie repornite la fel ca PHP-FPM. După schimbarea versiunii majore PHP, ar trebui, în plus, să puneți să fie reconstruit codul generat din generated/ și fișierele statice și să parcurgeți magazinul într-un mediu de test înainte de reluarea funcționării în producție. Cum reușește repornirea în mod corect descrie Repornirea PHP-FPM și a tuturor workerilor.
Ce poate și ce nu poate o actualizare Magento
O versiune Magento sau un patch de securitate de la Adobe închide erori din codul magazinului. Ele nu aplică patchul PHP, nu repornesc procesele FPM, nu elimină scripturi din baza de date și nu șterg conturi de administrator străine. Dacă s-a executat deja cod, este nevoie de o investigație. Cum recunoașteți ușile dosnice explică Recunoașterea și eliminarea webshell-urilor.
Pentru comercianții cu plată cu cardul se aplică în plus: verificați cerințele furnizorului dumneavoastră de plăți pentru incidente de securitate și stabiliți împreună cu el, înainte de reînnoirea cheilor. Dacă este necesară o notificare către autoritatea de supraveghere a protecției datelor clarificați cu responsabilul dumneavoastră cu protecția datelor sau cu avocatul.
Cum ajută PHP SOS concret?
- Clarificăm PHP-ul web și CLI al serverului dumneavoastră Magento și punem să fie confirmate patchul și repornirea.
- Salvăm jurnalele, fișierele și baza de date într-un mod verificabil, la nevoie prin criminalistica noastră IT.
- Verificăm
env.php,pub/, modulele, tabelele de configurare, blocurile CMS și conturile de administrator. - Curățăm, reînnoim cheile și accesurile și documentăm perioada unei posibile afectări pentru protecția datelor și furnizorul de plăți.
Întrebări frecvente
Un patch de securitate Magento închide și PHP2Shell?
Nu. Patchurile Magento remediază erori din codul magazinului. PHP2Shell se află în interpretorul PHP al serverului și este închis doar printr-o actualizare PHP sau printr-un backport confirmat, cu repornirea tuturor proceselor.
Unde ascund atacatorii skimmerele de carduri în Magento?
Adesea nu în fișiere, ci în baza de date, de exemplu în setările pentru scripturi suplimentare din antetul paginii sau în blocurile CMS. De aceea, în caz de suspiciune, trebuie întotdeauna verificată și baza de date.
Cine aplică patchul PHP la Adobe Commerce în cloud?
Depinde de contractul și de mediul dumneavoastră. Întrebați în scris Adobe sau operatorul dumneavoastră despre starea PHP și repornire. Extensiile proprii și conținutul bazei de date rămân în responsabilitatea dumneavoastră.
De ce este app/etc/env.php atât de important?
Fișierul conține accesul la baza de date, cheia de criptare și calea către zona de administrare. Cine a putut să îl citească poate decripta valorile criptate și poate găsi administrarea. În caz de suspiciune, aceste valori ar trebui reînnoite.