Trumpai: Dabartinė Magento saugumo spraga vadinasi PHP2Shell ir slypi ne Magento, o PHP. Magento pataisa jos neuždaro. Po PHP atnaujinimo ir paleidimo iš naujo patikrinkite app/etc/env.php, duomenų bazę dėl skimerių ir administratorių paskyrų sąrašą.
Ką PHP2Shell reiškia Magento parduotuvėms
Magento Open Source ir Adobe Commerce yra didelės PHP programos, kurios dažniausiai veikia su PHP-FPM. PHP komandos teigimu, spragos CVE-2026-109618 ir CVE-2026-109619 leidžia vykdyti kenkėjišką kodą be prisijungimo. Ar pati parduotuvė naujausia, čia nesvarbu.
Magento parduotuvės jau daug metų yra mėgstamas kredito kortelių skimingo taikinys, kai atsiskaitant perskaitoma įvestis. PHP2Shell atveria dar vieną kelią. Palo Alto Networks suskaičiavo daugiau nei 22,6 mln. viešai pasiekiamų, potencialiai pažeidžiamų PHP egzempliorių; kurios parduotuvės tarp jų, nežinoma.
Magento saugumo spraga: kaip teisingai nustatyti PHP būseną
Magento administravime PHP versijos neparodo ryškiai. Todėl būseną patikrinkite domeno talpinimo valdymo skydelyje arba paprašykite talpintojo ją patvirtinti. php -v komandinėje eilutėje rodo tik CLI PHP, su kuriuo veikia bin/magento ir cron užduotys. Žiniatinklio PHP per FPM gali būti kita versija, ir abu turi būti pataisyti.
Ištaisytos oficialios (upstream) versijos yra 8.5.12, 8.4.27, 8.3.36 ir 8.2.35; distribucijų atgaliniai perkėlimai (backport) gali turėti senesnius numerius. Kurias PHP versijas palaiko jūsų Magento versija, pagal sistemos reikalavimus patikrinkite Adobe dokumentacijoje (experienceleague.adobe.com). Dėl Adobe Commerce Adobe infrastruktūroje klauskite Adobe arba savo operatoriaus apie būseną. Nuoseklią instrukciją pateikia Kaip teisingai patikrinti PHP versiją ir pataisų būseną.
Kur Magento slepiasi kenkėjiškas kodas
| Vieta | Turinys | Patikros punktas |
|---|---|---|
app/etc/env.php |
Duomenų bazė, šifravimo raktas, administravimo kelias | Keitimo data, reikšmes atnaujinti kilus įtarimui |
pub/ |
Dokumentų šaknis, pub/media, pub/static |
PHP failai medijos ir static aplankuose |
app/code/ |
savi moduliai | nežinomi moduliai, pakeisti failai |
vendor/ |
Composer paketai, taip pat plėtiniai | Nukrypimai nuo lockfile |
generated/, var/ |
sugeneruotas kodas, talpykla, žurnalai | Išsaugoti žurnalus, kodą sugeneruoti iš naujo |
| Duomenų bazė | Konfigūracija, CMS blokai, administratoriai | svetimi scenarijai, nauji administratoriai |
Magento skimeriai dažnai slypi duomenų bazėje, pavyzdžiui, papildomų scenarijų nustatymuose puslapio antraštėje ar poraštėje ir CMS blokuose. Vien failų skenavimas jų nepastebi. Nepavojingi skaitymo užklausos padeda pirmajam žvilgsniui (lentelių priešdėlis priklauso nuo diegimo):
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%';
Išvalytas atsiskaitymas nereiškia, kad duomenys nenutekėjo. Prieš šalindami scenarijus išsaugokite žurnalus nuo 2026 m. spalio 20 d. ir duomenų bazės kopijas. Tik taip vėliau galima nustatyti, nuo kada ir kurie užsakymai buvo paveikti.
Administravimo sritis ir plėtiniai
Magento administravimo kelias renkamas laisvai ir nurodytas env.php. Sunkiai atspėjamas kelias prasmingas, bet nepakeičia dviejų veiksnių prisijungimo ir apribojimo žinomiems tinklams. Reguliariai tikrinkite administratorius ir jų roles, taip pat integracijas bei API žetonus.
Magento trečiųjų šalių plėtinių yra daug: mokėjimo būdai, ERP integracijos, paieškos ir rinkodaros moduliai. Kiekvienas atneša kodą, kurį reikia tikrinti per PHP atnaujinimus. Reguliariai naudokite composer audit ir išjungtus modulius pašalinkite visiškai.
Pagalvokite ir apie foninius procesus. Magento veikia su cron užduotimis ir dažnai su eilių vartotojais (consumer), kurie komandinėje eilutėje veikia kaip atskiri PHP procesai. Po PHP atnaujinimo juos reikia paleisti iš naujo lygiai kaip PHP-FPM. Pakeitus pagrindinę PHP versiją taip pat reikėtų iš naujo sugeneruoti generated/ kodą ir statinius failus bei bandomojoje aplinkoje išbandyti parduotuvę, prieš vėl pradedant gyvą veikimą. Kaip tvarkingai paleisti iš naujo, aprašyta puslapyje PHP-FPM ir visų vykdytojų paleidimas iš naujo.
Ką gali Magento atnaujinimas ir ko ne
Magento leidimas ar Adobe saugumo pataisa uždaro parduotuvės kodo klaidas. Ji netaiso PHP, nepaleidžia iš naujo FPM procesų, nepašalina scenarijų iš duomenų bazės ir neištrina svetimų administratorių paskyrų. Jei kodas jau buvo įvykdytas, reikia tyrimo. Kaip atpažinti užpakalines duris, paaiškina Kaip atpažinti ir pašalinti webshell.
Prekybininkams, priimantiems mokėjimus kortele, papildomai galioja: patikrinkite savo mokėjimo paslaugų teikėjo reikalavimus saugumo incidentų atveju ir prieš keisdami raktus suderinkite su juo. Ar reikia pranešti duomenų apsaugos priežiūros institucijai, išsiaiškinkite su savo duomenų apsaugos pareigūnu arba teisininku.
Kaip PHP SOS padeda konkrečiai?
- Išsiaiškiname jūsų Magento serverio žiniatinklio ir CLI PHP ir leidžiame patvirtinti pataisą bei paleidimą iš naujo.
- Žurnalus, failus ir duomenų bazę išsaugome atsekamai, prireikus per mūsų IT kriminalistiką.
- Tikriname
env.php,pub/, modulius, konfigūracijos lenteles, CMS blokus ir administratorių paskyras. - Išvalome, atnaujiname raktus ir prieigas bei dokumentuojame galimo poveikio laikotarpį duomenų apsaugai ir mokėjimo paslaugų teikėjui.
Dažni klausimai
Ar Magento saugumo pataisa uždaro ir PHP2Shell?
Ne. Magento pataisos taiso parduotuvės kodo klaidas. PHP2Shell yra serverio PHP interpretatoriuje ir uždaroma tik PHP atnaujinimu arba patvirtintu atgaliniu perkėlimu (backport) su visų procesų paleidimu iš naujo.
Kur užpuolikai slepia kredito kortelių skimerius Magento?
Dažnai ne failuose, o duomenų bazėje, pavyzdžiui, papildomų scenarijų nustatymuose puslapio antraštėje arba CMS blokuose. Todėl kilus įtarimui visada reikia patikrinti ir duomenų bazę.
Kas pataiso PHP Adobe Commerce debesyje?
Tai priklauso nuo jūsų sutarties ir aplinkos. Raštu paklauskite Adobe arba savo operatoriaus apie PHP būseną ir paleidimą iš naujo. Savi plėtiniai ir duomenų bazės turinys lieka jūsų atsakomybėje.
Kodėl app/etc/env.php toks svarbus?
Faile yra duomenų bazės prieiga, šifravimo raktas ir kelias į administravimo sritį. Kas galėjo jį perskaityti, gali iššifruoti užšifruotas reikšmes ir rasti administravimą. Kilus įtarimui šias reikšmes reikėtų atnaujinti.