Īsi: Pašreizējā Magento ievainojamība sauc PHP2Shell un slēpjas nevis Magento, bet PHP. Magento ielāps to neaizver. Pēc PHP atjaunināšanas ar pārstartēšanu pārbaudiet app/etc/env.php, datubāzi uz skimmeriem un administratoru kontu sarakstu.
Ko PHP2Shell nozīmē Magento veikaliem
Magento Open Source un Adobe Commerce ir lielas PHP lietojumprogrammas, kas parasti darbojas ar PHP-FPM. Ievainojamības CVE-2026-109618 un CVE-2026-109619 saskaņā ar PHP komandu ļauj izpildīt ļaunprātīgu kodu bez pieteikšanās. Vai pats veikals ir aktuāls, tam nav nozīmes.
Magento veikali jau gadiem ir iecienīts mērķis kredītkaršu skimmingam, kurā norēķinu procesā tiek nolasīti ievadītie dati. PHP2Shell tam atver vēl vienu ceļu. Palo Alto Networks saskaitīja vairāk nekā 22,6 miljonus pieejamu, potenciāli ievainojamu PHP instanču; kuri veikali tajās ietilpst, nav zināms.
Magento ievainojamība: PHP stāvokļa pareiza noteikšana
Magento administrēšanas panelī PHP versiju neizceļ. Tāpēc pārbaudiet stāvokli hostinga panelī domēnam vai palūdziet to apstiprināt hostinga sniedzējam. php -v komandrindā rāda tikai CLI PHP, ar kuru darbojas bin/magento un cron uzdevumi. Tīmekļa PHP caur FPM var būt cita versija, un abiem jābūt ielāpotiem.
Labotās upstream versijas ir 8.5.12, 8.4.27, 8.3.36 un 8.2.35, distributīvu backport labojumiem var būt vecāki numuri. Kuras PHP versijas atbalsta jūsu Magento versija, pārbaudiet pēc sistēmas prasībām Adobe dokumentācijā (experienceleague.adobe.com). Adobe Commerce uz Adobe infrastruktūras jautājiet Adobe vai savam operatoram par stāvokli. Soli pa solim instrukciju piedāvā raksts PHP versijas un ielāpa stāvokļa pareiza pārbaude.
Kur Magento atrodas ļaunprātīgs kods
| Vieta | Saturs | Pārbaudes punkts |
|---|---|---|
app/etc/env.php |
Datubāze, šifrēšanas atslēga, administrēšanas ceļš | Izmaiņu datums, aizdomu gadījumā vērtības mainīt |
pub/ |
Dokumentu sakne, pub/media, pub/static |
PHP faili medijiem un static mapēs |
app/code/ |
Pašu moduļi | Nezināmi moduļi, mainīti faili |
vendor/ |
Composer pakotnes, arī paplašinājumi | Atšķirības no lockfile |
generated/, var/ |
Ģenerētais kods, kešatmiņa, žurnāli | Saglabāt žurnālus, kodu ģenerēt no jauna |
| Datubāze | Konfigurācija, CMS bloki, administratoru lietotāji | Sveši skripti, jauni administratori |
Skimmeri Magento bieži atrodas datubāzē, piemēram, iestatījumos papildu skriptiem lapas galvenē vai kājenē un CMS blokos. Tīra failu skenēšana tos palaiž garām. Droša lasīšanas piekļuve palīdz pirmajam skatienam (tabulu prefikss atkarīgs no instalācijas):
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%';
Notīrīts norēķinu process nenozīmē, ka dati nav aizplūduši. Saglabājiet žurnālus no 20.10.2026 un datubāzes izvilkumus, pirms noņemat skriptus. Tikai tā vēlāk var noteikt, kopš kura laika un kuri pasūtījumi bija skarti.
Administrēšanas apgabals un paplašinājumi
Administrēšanas ceļš Magento ir brīvi izvēlams un ir norādīts env.php. Grūti uzminams ceļš ir lietderīgs, bet neaizstāj divfaktoru autentifikāciju un ierobežojumu uz zināmiem tīkliem. Regulāri pārbaudiet administratoru lietotājus un viņu lomas, kā arī integrācijas un API pilnvaras (token).
Trešo pušu paplašinājumu Magento ir daudz: maksājumu veidi, ERP savienojumi, meklēšanas un mārketinga moduļi. Katrs atnes kodu, kas PHP jauninājumos jāpārbauda. Regulāri izmantojiet composer audit un pilnībā noņemiet izslēgtos moduļus.
Padomājiet arī par fona procesiem. Magento strādā ar cron uzdevumiem un bieži ar rindu consumer procesiem, kas kā atsevišķi PHP procesi darbojas komandrindā. Pēc PHP atjaunināšanas tie jāpārstartē tāpat kā PHP-FPM. Pēc PHP galvenās versijas maiņas turklāt likt no jauna uzbūvēt generated/ ģenerēto kodu un statiskos failus un veikalu izklikšķināt testa vidē, pirms atsāk produktīvo darbību. Kā pārstartēšana izdodas pareizi, apraksta PHP-FPM un visu worker procesu pārstartēšana.
Ko Magento atjauninājums var un ko ne
Magento izlaidums vai Adobe drošības ielāps aizver kļūdas veikala kodā. Tas neielāpo PHP, nepārstartē FPM procesus, nenoņem skriptus no datubāzes un neizdzēš svešus administratoru kontus. Ja kods jau ir izpildīts, nepieciešama izmeklēšana. Kā atpazīt slēptas ieejas, skaidro raksts Webshell atpazīšana un noņemšana.
Tirgotājiem ar karšu maksājumiem papildus ir spēkā: pārbaudiet sava maksājumu pakalpojumu sniedzēja noteikumus drošības incidentiem un pirms atslēgu maiņas saskaņojiet to ar viņu. Vai nepieciešams ziņojums datu aizsardzības uzraudzības iestādei, noskaidrojiet kopā ar savu datu aizsardzības speciālistu vai advokātu.
Kā PHP SOS palīdz konkrēti?
- Mēs noskaidrojam jūsu Magento servera tīmekļa un CLI PHP un liekam apstiprināt ielāpu un pārstartēšanu.
- Mēs izsekojami saglabājam žurnālus, failus un datubāzi, vajadzības gadījumā ar mūsu IT forensikas palīdzību.
- Mēs pārbaudām
env.php,pub/, moduļus, konfigurācijas tabulas, CMS blokus un administratoru kontus. - Mēs attīrām, mainām atslēgas un piekļuves un dokumentējam iespējamās skartības laika posmu datu aizsardzības un maksājumu pakalpojumu sniedzēja vajadzībām.
Biežāk uzdotie jautājumi
Vai Magento drošības ielāps aizver arī PHP2Shell?
Nē. Magento ielāpi labo kļūdas veikala kodā. PHP2Shell atrodas servera PHP interpretatorā, un to aizver tikai PHP atjauninājums vai apstiprināts backport ar visu procesu pārstartēšanu.
Kur uzbrucēji Magento slēpj kredītkaršu skimmerus?
Bieži nevis failos, bet datubāzē, piemēram, iestatījumos papildu skriptiem lapas galvenē vai CMS blokos. Tāpēc pēc aizdomām vienmēr jāpārbauda arī datubāze.
Kurš ielāpo PHP Adobe Commerce mākonī?
Tas atkarīgs no jūsu līguma un vides. Rakstiski jautājiet Adobe vai savam operatoram par PHP stāvokli un pārstartēšanu. Pašu paplašinājumi un datubāzes saturs paliek jūsu atbildībā.
Kāpēc app/etc/env.php ir tik svarīgs?
Fails satur datubāzes piekļuvi, šifrēšanas atslēgu un ceļu uz administrēšanas apgabalu. Kas to varēja nolasīt, var atšifrēt šifrētas vērtības un atrast administrēšanas paneli. Aizdomu gadījumā šīs vērtības jāmaina.