# Magento biztonsági rés, PHP2Shell: a Magento és az Adobe Commerce védelme

> Magento és Adobe Commerce védelme a PHP2Shell után: PHP-állapot tisztázása, env.php védelme, skimmerek keresése az adatbázisban és a pub/ mappában.

Forrás: https://phpsos.de/hu/plattformen/magento-adobe-commerce/  
Állapot: 2026. 10. 25.  
Szolgáltató: PHP SOS, PHP-vészhelyzeti segítség és szerverbiztonság. Azonnali segítség WhatsAppon: https://wa.me/491736494914?text=%C3%9Cdv%C3%B6zl%C3%B6m%2C%20PHP%20SOS%21%20Seg%C3%ADts%C3%A9gre%20van%20sz%C3%BCks%C3%A9g%C3%BCnk%20a%20PHP-szerver%C3%BCnkkel.%20C%C3%A9g%3A%20%E2%80%A6%20Weboldal%3A%20%E2%80%A6

**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](https://phpsos.de/hu/php2shell/php-version-pruefen/) 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):

```bash
bin/magento info:adminuri
bin/magento module:status
```

```sql
SELECT username, email, created FROM admin_user;
SELECT path, value FROM core_config_data WHERE path LIKE 'design/%' AND value LIKE '%<script%';
```

> **Fontos:**
> 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](https://phpsos.de/hu/php2shell/php-fpm-neustart/) 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](https://phpsos.de/hu/ratgeber/webshell-erkennen/) ú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](https://phpsos.de/hu/leistungen/it-forensik/) révén.
- Ellenőrizzük az `env.php`-t, a `pub/` 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.

## Források

- [php.net: biztonsági közlemények](https://www.php.net/)
- [Adobe Commerce](https://business.adobe.com/)
- [OWASP Cheat Sheets](https://cheatsheetseries.owasp.org/)
- [Palo Alto/TechTarget: nyilvánosan elérhető példányok](https://www.techtarget.com/cybersecurity/news/366652444/PHP2Shell-22M-exposed-servers-at-risk-as-emergency-patches-released)