# Feltört webshop? IT-biztonság kereskedőknek

> Feltört vagy a PHP2Shell által veszélyeztetett webshop? Így védik a kereskedők a vevői fiókokat, a fizetést és a bevételt, és így indul az első néhány óra.

Forrás: https://phpsos.de/hu/branchen/onlineshops/  
Á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:** 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](https://phpsos.de/hu/plattformen/shopware-6/), [WooCommerce](https://phpsos.de/hu/plattformen/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](https://phpsos.de/hu/ratgeber/google-warnung-entfernen/) ú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 |

> **Fontos:**
> 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

1. Állítsa a webshopot karbantartási módba, vagy ha ez nem lehetséges, kapcsolja le átmenetileg a hálózatról.
2. 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.
3. Kérje a tárhelyszolgáltatótól a PHP-csomag állapotának és az újraindításnak az írásos visszaigazolását.
4. 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.
5. 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](https://phpsos.de/hu/compliance/dsgvo-meldepflicht-72-stunden/). 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](https://phpsos.de/hu/leistungen/malware-entfernung/).
- 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.

## Források

- [php.net: biztonsági közlemények](https://www.php.net/)
- [BSI: figyelmeztetések és ajánlások](https://www.bsi.bund.de/)
- [GDPR 33. cikk: bejelentés a felügyeleti hatóságnak](https://dsgvo-gesetz.de/art-33-dsgvo/)
- [OWASP Top 10](https://owasp.org/www-project-top-ten/)