Lehet, hogy a bejglit majszolva elkerülte a figyelmedet, vagy a karácsonyi hajrában egyszerűen átsiklottál felette, de 2025. december 22-én egy nagyon fontos email landolhatott a fiókodban a WooCommerce csapatától.
A tárgymező ártalmatlannak tűnt: „Security vulnerability identified in WooCommerce has been patched”.
A tartalom azonban kevésbé volt megnyugtató: egy olyan biztonsági rést foltoztak be, ami két éve tátongott a világ legnépszerűbb webáruház-motorján, és ami lehetővé tette, hogy illetéktelenek belelássanak más vásárlók rendeléseibe.
Ha 8.1 és 10.4.2 közötti verziót használsz (tehát szinte biztosan érintett vagy), és még nem frissítettél 10.4.3-ra, akkor most hagyd abba az olvasást, és indítsd el a frissítést. Most.
Ha kész vagy, gyere vissza, és elmagyarázzuk, mi történt pontosan, és miért nem dőlhetsz hátra a jövőben sem.
Mi történt pontosan? (A technikai háttér)
A hiba a WooCommerce úgynevezett Store API-jában rejtőzött. Ez az a felület, amin keresztül a webshopod különböző modern funkciói (pl. a blokk alapú pénztár) kommunikálnak az adatbázissal.
A sebezhetőség típusa az, amit a szakmában IDOR-nak (Insecure Direct Object Reference) hívnak.
Képzeld el úgy, mint egy szállodai recepciót.
Te bejelentkezel a szállodába (regisztrált felhasználó vagy a shopban).
Odamesz a recepcióhoz, és kéred a számládat.
A recepciós (az API) nem kéri el a szobakulcsodat, hanem csak annyit kérdez: „Hányas szoba?”.
Te bemondasz egy véletlenszerű számot (egy vendégrendelés azonosítóját).
És a recepciós gondolkodás nélkül odaadja neked egy olyan ember számláját, aki már kijelentkezett (vendégvásárló), rajta a nevével, címével és a fogyasztásával.
A hibát az okozta, hogy a rendszer ellenőrizte ugyan, hogy be vagy-e jelentkezve, de azt nem ellenőrizte elég szigorúan, hogy az a rendelés, amit lekérdezel, tényleg a tiéd-e – feltéve, ha az egy vendég (regisztráció nélküli) rendelés volt.
Technikai részletek: Miért „csak” a vendégrendelések?
(Ez a rész fejlesztőknek szól)
A WooCommerce a regisztrált felhasználók rendeléseit szigorúbban köti a user_id-hoz. A vendégrendelések (Guest Orders) azonban technikai értelemben „gazdátlanok” az adatbázisban (gyakran 0-s ID-vel vagy session alapú azonosítással futnak).
A Store API egyik végpontja (endpoint) lehetővé tette, hogy egy autentikált (tehát bármilyen regisztrált, akár „Vásárló” jogkörű) felhasználó lekérje ezeket az adatokat, ha ismerte vagy kitalálta a rendelés ID-ját. Bár a WooCommerce szerint ehhez „specifikus tudás” kellett, a rendelésazonosítók gyakran szekvenciálisak (egymás után következnek: 1001, 1002, 1003…), így egy egyszerű scripttel végigpróbálgathatók voltak.
„Két éve létezik, de nem használták ki” – Akkor mi a baj?
A WooCommerce emailje hangsúlyozza: „At this time, we have no indication that this vulnerability has been exploited.” (Jelenleg nincs jel arra, hogy ezt kihasználták volna).
Ez megnyugtatóan hangzik, de 2025-ben a kiberbiztonságban van egy farkastörvény: Amint kijön a javítás (patch), a sebezhetőség nyilvánossá válik.
A hackerek most nem pihennek. Éppen azt csinálják, amit „Reverse Engineering”-nek hívunk. Megnézik a WooCommerce 10.4.2 és a 10.4.3 kódja közötti különbséget.
Meglátják, hogy melyik fájlban változott meg az ellenőrzés.
Ebből 5 perc alatt rájönnek, hogyan lehetett volna feltörni az oldalt.
És írnak rá egy robotot, ami mostantól végigpásztázza az internetet, olyan webshopokat keresve, akik a karácsonyi szünet miatt még nem frissítettek.
Tehát a veszély most a legnagyobb, nem az elmúlt két évben volt.
Milyen adatok kerülhettek veszélybe?
Bár bankkártyaadatok nem szivárogtak ki (mivel azokat a WooCommerce nem tárolja közvetlenül olvasható formában), a GDPR szempontjából ez így is súlyos incidens lehetett volna. A hozzáférhető adatok:
Vásárló teljes neve
Szállítási és számlázási cím
Email cím
Telefonszám
Megvásárolt termékek listája
Ez az adathalmaz tökéletes alapanyag a jövőbeli adathalász (phishing) támadásokhoz.
Mit kell tenned webshop tulajdonosként?
Azonnali frissítés: Ellenőrizd a Vezérlőpult -> WooCommerce -> Állapot menüpontban a verziószámot. Ha nem 10.4.3 (vagy újabb), frissíts azonnal.
Gyorsítótárak törlése: Ha használsz cache plugint (WP Rocket, LiteSpeed Cache) vagy szerver oldali gyorsítótárat, a frissítés után mindenképp ürítsd ki. Előfordulhat, hogy a régi, sebezhető API válaszok benne maradtak a cache-ben.
Wppajzs ellenőrzés: Ha ügyfelünk vagy, dőlj hátra. A rendszereink figyelik a verziókat, és a menedzselt karbantartás keretében ezeket a kritikus frissítéseket prioritással kezeljük.
Tanulság 2025-re
Ez az eset tökéletesen példázza, miért nem létezik „kész” webáruház. A szoftverek folyamatosan változnak, a hibák pedig néha évekig rejtve maradnak. A WooCommerce csapata példás gyorsasággal reagált és javította a hibát az összes támogatott verzióban (visszamenőleg a 8.1-ig!).
A te felelősséged „csak” annyi, hogy ne hagyd nyitva az ajtót akkor sem, amikor éppen az ünnepi pihenésedet töltöd. Vagy bízd olyanokra, akik az ünnepek alatt is figyelnek helyetted.
Nem szeretnél minden egyes biztonsági emailnél gyomorgörcsöt kapni?
Bízd a Wppajzs csapatára a webshopod védelmét, és mi gondoskodunk róla, hogy a javítások már akkor fent legyenek, mire te elolvasod a híreket!
Gyakori kérdések
Értesítenem kell a vásárlóimat (GDPR)?
Mivel a WooCommerce hivatalos álláspontja szerint nincs bizonyíték arra, hogy a hibát bárki kihasználta volna (0-day exploit), és a javítás megelőző jellegű volt, jelenleg nem szükséges pánikot kelteni és értesíteni az ügyfeleket. Az incidensbejelentés (NAIH felé) csak akkor kötelező, ha valószínűsíthető az adatvédelmi incidens megtörténte.
A Wppajzs megvédett volna ettől frissítés nélkül is?
Ez egy ún. logikai hiba volt az alkalmazás kódjában, amit hagyományos tűzfallal (WAF) nehéz kiszűrni, hiszen a kérés technikailag „szabályosnak” tűnik (egy bejelentkezett felhasználó lekér egy adatot). Ezért kritikus a patch management, vagyis a gyors frissítés, amit szolgáltatásunk részeként biztosítunk.
Automatikus frissítésre van állítva a WooCommerce-em. Biztonságban vagyok?
Elvileg igen. A WooCommerce kényszerített biztonsági frissítést is alkalmazhat ilyen esetekben. De az ördög nem alszik: lépj be és ellenőrizd manuálisan. Sokszor egy tárhelyhiba vagy egy másik plugin összeakadása megállíthatja az automata folyamatot.
