Röviden: A jelenlegi Magento biztonsági rés neve PHP2Shell, és nem a Magentóban van, hanem a PHP-ben. Egy Magento-javítás nem zárja le. A PHP-frissítés és az újraindítás után ellenőrizze az app/etc/env.php fájlt, az adatbázist skimmerek szempontjából és az admin-fiókok listáját.
Mit jelent a PHP2Shell a Magento webshopok számára
A Magento Open Source és az Adobe Commerce nagy PHP-alkalmazások, amelyek többnyire PHP-FPM-mel futnak. A CVE-2026-109618 és a CVE-2026-109619 rések a PHP-csapat szerint lehetővé teszik kártékony kód futtatását bejelentkezés nélkül. Az nem számít, hogy maga a webshop naprakész-e.
A Magento webshopok évek óta a bankkártya-skimming kedvelt célpontjai, amelynél a pénztárban bevitt adatokat kiolvassák. A PHP2Shell erre egy további utat nyit. A Palo Alto Networks több mint 22,6 millió nyilvánosan elérhető, potenciálisan sebezhető PHP-példányt számolt; hogy mely webshopok vannak köztük, nem ismert.
Magento biztonsági rés: a PHP-állapot helyes megállapítása
A Magento nem jeleníti meg feltűnően a PHP-verziót az adminban. Az állapotot ezért ellenőrizze a domainhez tartozó tárhelypanelben, vagy erősíttesse meg a tárhelyszolgáltatójával. A php -v a parancssorban csak a CLI-s PHP-t mutatja, amellyel a bin/magento és a cron-feladatok futnak. Az FPM-en keresztüli web-PHP más verzió lehet, és mindkettőnek javítottnak kell lennie.
A javított upstream verziók: 8.5.12, 8.4.27, 8.3.36 és 8.2.35, a disztribúciók backportjai régebbi számot is viselhetnek. Hogy a Magento-verziója mely PHP-verziókat támogatja, azt a rendszerkövetelmények szerint az Adobe dokumentációjában (experienceleague.adobe.com) ellenőrizheti. Az Adobe infrastruktúráján futó Adobe Commerce esetén kérdezze meg az Adobe-t vagy az üzemeltetőjét az állapotról. Lépésenkénti útmutatót a A PHP-verzió és a javítási állapot helyes ellenőrzése kínál.
Hol lapul a kártékony kód a Magentóban
| Hely | Tartalom | Ellenőrzési pont |
|---|---|---|
app/etc/env.php |
adatbázis, titkosítási kulcs, admin útvonal | módosítás dátuma, gyanú esetén az értékek megújítása |
pub/ |
dokumentumgyökér, pub/media, pub/static |
PHP-fájlok a média- és static-mappákban |
app/code/ |
saját modulok | ismeretlen modulok, módosított fájlok |
vendor/ |
Composer-csomagok, bővítmények is | eltérések a lockfile-tól |
generated/, var/ |
generált kód, gyorsítótár, naplók | naplók mentése, kód újragenerálása |
| Adatbázis | konfiguráció, CMS-blokkok, admin-felhasználók | idegen szkriptek, új adminok |
A Magentóban a skimmerek gyakran az adatbázisban vannak, például az oldalfejben vagy oldallábban lévő további szkriptek beállításaiban és a CMS-blokkokban. Egy tiszta fájlkeresés átnézi őket. Veszélytelen olvasási hozzáférések segítenek az első pillantásnál (a táblaelőtag a telepítéstől függ):
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%';
Egy megtisztított pénztár nem jelenti, hogy nem szivárogtak el adatok. Mentse a naplókat 2026. 10. 20-tól és az adatbázis-kivonatokat, mielőtt eltávolítja a szkripteket. Csak így állapítható meg később, mikortól és mely rendelések érintettek.
Admin felület és bővítmények
Az admin útvonal a Magentóban szabadon választható, és az env.php-ban áll. Egy nehezen kitalálható útvonal ésszerű, de nem pótolja a kétfaktoros bejelentkezést és az ismert hálózatokra való korlátozást. Rendszeresen ellenőrizze az admin-felhasználókat és szerepköreiket, valamint az integrációkat és az API-tokeneket.
A harmadik féltől származó bővítmények száma a Magentónál nagy: fizetési módok, ERP-kapcsolatok, kereső- és marketingmodulok. Mindegyik olyan kódot hoz, amelyet PHP-frissítéseknél ellenőrizni kell. Rendszeresen használja a composer audit parancsot, és a kikapcsolt modulokat teljesen távolítsa el.
Gondoljon a háttérfolyamatokra is. A Magento cron-feladatokkal és gyakran üzenetsor-consumerekkel dolgozik, amelyek külön PHP-folyamatként futnak a parancssorból. A PHP-frissítés után ezeket ugyanúgy újra kell indítani, mint a PHP-FPM-et. A PHP főverziójának váltása után a generated/ mappában lévő generált kódot és a statikus fájlokat is újra kell építtetni, a webshopot pedig tesztkörnyezetben végig kell kattintani, mielőtt az éles üzem újraindul. Hogyan sikerül tisztán az újraindítás, azt a A PHP-FPM és az összes worker újraindítása oldal írja le.
Mit tud egy Magento-frissítés, és mit nem
Egy Magento-kiadás vagy az Adobe biztonsági javítása lezárja a webshop kódjában lévő hibákat. A PHP-t nem javítja, FPM-folyamatokat nem indít újra, szkripteket nem távolít el az adatbázisból, és idegen admin-fiókokat nem töröl. Ha már futott kód, vizsgálatra van szükség. Hogyan ismerheti fel a hátsó ajtókat, azt a Webshellek felismerése és eltávolítása útmutató magyarázza el.
A kártyás fizetést alkalmazó kereskedőkre ezenfelül érvényes: ellenőrizze a fizetési szolgáltatója biztonsági incidensekre vonatkozó előírásait, és a kulcsok megújítása előtt egyeztessen vele. Hogy szükséges-e bejelentés az adatvédelmi felügyeleti hatóságnak, azt az adatvédelmi felelősével vagy ügyvédjével tisztázza.
Hogyan segít konkrétan a PHP SOS?
- Tisztázzuk a Magento-szervere web- és CLI-s PHP-ját, és megerősíttetjük a javítást és az újraindítást.
- Nyomon követhetően mentjük a naplókat, a fájlokat és az adatbázist, szükség esetén az IT-forenzikánk révén.
- Ellenőrizzük az
env.php-t, apub/mappát, a modulokat, a konfigurációs táblákat, a CMS-blokkokat és az admin-fiókokat. - Tisztítunk, megújítjuk a kulcsokat és a hozzáféréseket, és dokumentáljuk az esetleges érintettség időszakát az adatvédelem és a fizetési szolgáltató számára.
Gyakori kérdések
Lezárja egy Magento biztonsági javítás a PHP2Shellt is?
Nem. A Magento-javítások a webshop kódjában lévő hibákat szüntetik meg. A PHP2Shell a szerver PHP-értelmezőjében van, és csak PHP-frissítés vagy egy megerősített backport, valamint az összes folyamat újraindítása zárja le.
Hol rejtik el a támadók a bankkártya-skimmereket a Magentóban?
Gyakran nem fájlokban, hanem az adatbázisban, például az oldalfejben lévő további szkriptek beállításaiban vagy CMS-blokkokban. Ezért gyanú esetén mindig az adatbázis ellenőrzése is hozzátartozik.
Ki javítja a PHP-t az Adobe Commerce felhőben?
Ez a szerződésétől és a környezetétől függ. Kérdezze meg írásban az Adobe-t vagy az üzemeltetőjét a PHP-állapotról és az újraindításról. A saját bővítmények és az adatbázis tartalma az Ön felelőssége marad.
Miért olyan fontos az app/etc/env.php?
A fájl tartalmazza az adatbázis-hozzáférést, a titkosítási kulcsot és az admin felület útvonalát. Aki el tudta olvasni, vissza tudja fejteni a titkosított értékeket, és megtalálja az admint. Gyanú esetén ezeket az értékeket meg kell újítani.