Röviden: Ha a webshopját feltörték, vagy nem javított PHP-verzión fut, három dologról van szó egyszerre: az ügyféladatokról, a fizetési folyamatról és a bevételről. Állítsa a webshopot ellenőrzötten karbantartási módba, mentse el a naplókat 2026. 10. 20-tól, és tisztázza, ki frissíti és indítja újra a PHP-t az Ön szerverén.
Mi forog kockán egy webshopban
A webshop több, mint egy weboldal. Ügyfélfiókokat kezel jelszó-hash-ekkel, szállítási és számlázási címeket, rendelési előzményeket, kuponokat, és gyakran árukészlet-kezelő rendszerekhez, futárszolgálatokhoz és piactérekhez kapcsolódó interfészeket is. Aki kódot tud futtatni a szerveren, általában hozzáfér az adatbázishoz és az ott tárolt API-kulcsokhoz.
A kártyaadatok többnyire nem Önnél, hanem a fizetési szolgáltatónál vannak. Ez azonban csak részben megnyugtató: a támadó JavaScriptet csempészhet a rendelési folyamatba, amely a böngészőben kiolvassa a beírt adatokat. Az ilyen skimming-szkriptek a webshop üzemeltetése közben alig tűnnek fel, mert a rendelések teljesen normálisan lefutnak.
Ide tartoznak az interfészek is. Az a webshop, amely a rendeléseket átadja az árukészlet-kezelőnek, a futárszolgálatoknak és a piacterek felé, az ehhez szükséges hozzáférési kulcsokat többnyire a szerveren lévő konfigurációs fájlokban tárolja. Aki ezeket lemásolja, a kereskedő nevében szállítócímkéket hozhat létre, készletet módosíthat vagy visszaélhet a piactéri fiókokkal.
Tipikus webshoprendszerek, és miért érinti őket a PHP2Shell
A középvállalkozások körében elterjedt webshoprendszerek PHP-n futnak: Shopware 6, WooCommerce, Magento, OXID, PrestaShop és számos régebbi Shopware 5 telepítés. A PHP2Shell (CVE-2026-109618 és CVE-2026-109619, egyenként CVSS 9,2) magában a PHP-ban van. A támadónak nincs szüksége vevői fiókra vagy rendszergazdai hozzáférésre.
A kereskedők számára ez azt jelenti, hogy a legújabb webshop-frissítés nem véd. A döntő kérdés az, hogy a szerveren a PHP 8.5.12, 8.4.27, 8.3.36 vagy 8.2.35 verzión fut-e, illetve hogy a szolgáltató telepített-e backportot, és hogy ezt követően újraindult-e minden PHP-folyamat. A PHP 8.1-es vagy régebbi verzión futó, régi webshopokhoz a PHP-projekt már nem ad hivatalos frissítést. Ilyenkor a vészhelyzet mellett migráció is ránk vár, amelyet nem érdemes időnyomás alatt, a főszezonban elvégezni.
Feltört webshop: mit jelent egy incidens konkrétan
A feltört webshop több szinten okoz kárt, és ezek felerősítik egymást:
- Bevétel: a karbantartási mód minden órája rendelésekbe kerül. Az a webshop viszont, amely észrevétlenül tovább működik, érezhetően drágább is lehet.
- Ügyféladatok: az elszivárgott címeket és rendeléseket célzott adathalász levelekhez használják, amelyek hitelesnek hatnak, mert valódi rendeléseket említenek.
- Láthatóság: ha a Google kártékony kódot észlel, figyelmeztetés jelenik meg a keresési találatok között. Hogyan szabadulhat meg tőle, azt a Google-figyelmeztetés eltávolítása útmutató mutatja meg.
- Partnerek: a fizetési szolgáltatóknak és a piactereknek saját előírásaik vannak a biztonsági incidensekre. Aki későn jelent, az elszámolásnál kellemetlenségeket kockáztat.
Ki a felelős: az ügynökség, a tárhelyszolgáltató vagy a kereskedő?
Sok webshopban a PHP kérdése két szék közé esik. Az ügynökség megépítette a webshopot és gondozza a bővítményeket, a tárhelyszolgáltató üzemelteti a szervert, a kereskedő pedig abból indul ki, hogy a kettő közül valaki gondoskodik róla. Menedzselt tárhelynél többnyire a szolgáltató javít, saját vServer esetén senki sem automatikusan.
| Feladat | Tipikusan felelős | Ellenőrizze |
|---|---|---|
| PHP-csomag frissítése | tárhelyszolgáltató vagy szerverüzemeltető | írásos visszaigazolás a csomag állapotáról |
| PHP-folyamatok újraindítása | aki a szervert kezeli | az újraindítás időpontja |
| Webshop és bővítmények | ügynökség | karbantartási szerződés és hozzáférések |
| Fizetési szolgáltató tájékoztatása | kereskedő | szerződéses bejelentési kötelezettségek |
A PHP-javítás nem bizonyítja, hogy korábban nem történt semmi. Ha a webshop elleni támadás a 10. 17. és a javítás időpontja között történt, a bejuttatott kód tovább futhat. Mielőtt feloldja a riasztást, ellenőriztesse.
Az első órák: a teendők sorrendje kereskedőknek
- Állítsa a webshopot karbantartási módba, vagy ha ez nem lehetséges, kapcsolja le átmenetileg a hálózatról.
- Mentse el a webszerver, a PHP és a webshop naplóit 2026. 10. 20-tól, mielőtt a naplóforgatás törölné őket.
- Kérje a tárhelyszolgáltatótól a PHP-csomag állapotának és az újraindításnak az írásos visszaigazolását.
- Cserélje le a rendszergazdai jelszavakat, a fizetési, szállítási és piactéri API-kulcsokat, valamint az adatbázis-hozzáféréseket, de csak a tisztítás után.
- Ellenőrizze a fizetési folyamatot, a fizetési bővítményeket és a beágyazott szkripteket változások szempontjából.
Ha adatszivárgásra utaló jelek vannak, megkezdődik a GDPR 72 órás határideje. A jogi értékelést az adatvédelmi felelőssel és adott esetben az ügyvéddel együtt végezze el.
Hogyan segít konkrétan a PHP SOS?
- Távolról ellenőrizzük a PHP-csomag tényleges állapotát, az üzemmódot (például mod_php vagy PHP-FPM), és azt, hogy minden worker újraindult-e.
- Megvizsgáljuk a webshop fájljait, az adatbázist és a fizetési folyamatot webshellek, skimming-kód és új rendszergazdai fiókok után kutatva, és eltávolítjuk a talált kártékony szoftvert.
- Egyeztetünk az ügynökséggel és a tárhelyszolgáltatóval, hogy a webshop karbantartása és a szerverüzemeltetés ne fussanak el egymás mellett.
- A megállapításokat és az intézkedéseket úgy dokumentáljuk, hogy bemutathassa őket a fizetési szolgáltatónak, a biztosítónak és az adatvédelmi felelősnek.
- Ezután megerősítjük a szervert, és kívánságára átvesszük a folyamatos felügyeletet.
Gyakori kérdések
Le kell kapcsolnom a webshopot a hálózatról a PHP2Shell miatt?
A BSI (a német szövetségi információbiztonsági hivatal) azt javasolja, hogy a webszervert átmenetileg le kell kapcsolni a hálózatról, ha a PHP-frissítés nem azonnal lehetséges. Webshop esetében gyakran jobb megoldás a tájékoztató oldallal működő karbantartási mód, mint egy hibaüzenet. Amint a PHP javítva van és minden folyamat újraindult, a webshop újra megnyithat.
Veszélyben vannak a bankkártyaadatok a webshopomban?
A legtöbb webshopban a kártyaadatok nem a saját szerveren, hanem a fizetési szolgáltatónál vannak. Veszélyes viszont a fizetési oldalba (checkout) épített, manipulált kód, amely a beírt adatokat még azelőtt kiolvassa, hogy azok a szolgáltatóhoz érnének. Ezért egy támadás utáni minden vizsgálatnak ki kell terjednie a fizetési folyamatra is.
Elég, ha frissítem a Shopware-t vagy a WooCommerce-t?
Nem. A PHP2Shell magát a PHP-t érinti, nem a webshoprendszert. A webshop frissítése nem zárja le a rést, a PHP-javítás pedig nem távolítja el a már korábban bejuttatott kártékony kódot.
Kit kell értesítenem adatszivárgás után?
Személyes adatok esetén szóba jön az adatvédelmi hatóság értesítése 72 órán belül, a kockázattól függően pedig az érintettek tájékoztatása is. Ehhez járulnak a fizetési szolgáltatóval és a biztosítóval szembeni szerződéses kötelezettségek. Az egyedi esetben történő értékelést az adatvédelmi felelőssel és ügyvéddel együtt végezze el.