Kritikus PHP-hiba: mit jelent a pénzügyi adataidra, és mit kérdezz a szoftverszállítóidtól?

Október 21-én a Nemzeti Kiberbiztonsági Intézet (NBSZ NKI) riasztást adott ki a PHP két kritikus hibájáról. A támadó egyetlen kéréssel, bejelentkezés nélkül futtathat kódot a szerveren. A legtöbb cikk arról szól, hogyan frissítsd a weboldalad. Ez a cikk arról, ami a weboldal mögött van: a számláid, a NAV-kapcsolatod és a bankadataid.

Ha cégvezető vagy pénzügyes vagy, nem neked kell ma este PHP-t frissítened. Az viszont a te dolgod, hogy tudd, ki teszi meg, és mi a terv, ha valami már történt. A technikai részleteket a Composite Solutions teendőlistája részletezi. Itt a pénzügyi oldalra koncentrálunk.

Mi történt pontosan?

A PHP-projekt két kritikus, távolról kihasználható hibát javított, a szakma „php2shell” néven hivatkozik rájuk. Mindkettő CVSS v4.0 szerint 9,2 pontos. A javított verziók: PHP 8.5.12, 8.4.27, 8.3.36 és 8.2.35 (NKI). A 8.1-es és régebbi ágakra nincs hivatalos új kiadás, csak minimális, forrásból fordítható javítás.

A PHP-biztonsági közlemény szerint a támadó a webszerver-folyamat jogaival futtat kódot. Lefordítva: mindent elér, amit az alkalmazásod elér. Az adatbázist, a konfigurációs fájlokat és az azokban tárolt jelszavakat, kulcsokat is.

A PHP a W3Techs szerint az ismert szerveroldali nyelvű weboldalak 69,3%-át hajtja. A magyar .hu domaineken a WordPress részesedése 67,7% (W3Techs), és az is PHP-n fut.

Miért pénzügyi kérdés egy PHP-hiba?

Mert a pénzügyi folyamatok jelentős része ma webes rendszereken fut, és ezek közül sok PHP-alapú. A WooCommerce-webshop, amely a megrendelésből automatikusan számlát állít ki. Az online számlázó vagy ügyviteli rendszer. A könyvelőiroda WordPress-alapú ügyfélportálja. Egy Laravel-alapú belső jóváhagyási vagy kontrollingrendszer. A phpMyAdmin, amelyről senki sem tudta, hogy még fut.

Ezek a rendszerek a konfigurációjukban olyan adatokat tárolnak, amelyek közvetlenül pénzhez vagy pénzügyi adathoz vezetnek:

• NAV Online Számla technikai felhasználó: felhasználónév, jelszó, XML aláírókulcs és cserekulcs. Ezekkel a számlázó a cég nevében küld adatot a NAV-nak. A jogosultságtól függően a cég kiállított és befogadott számláinak adatai is lekérdezhetők vele.
• Fizetési szolgáltatók kulcsai: a kártyás fizetéshez és a visszatérítésekhez használt API-kulcsok.
• Banki kapcsolatok: a kivonatletöltéshez vagy utalásindításhoz használt hozzáférések, ha a rendszer ilyet használ.
• Számla- és partneradatok: vevők, szállítók, bankszámlaszámok, összegek. Ezek személyes adatot is tartalmaznak, ezért a GDPR hatálya alá esnek.
• Levelezési hozzáférés: az SMTP-jelszó, amellyel a rendszer a számlákat és a fizetési emlékeztetőket kiküldi.

Egy weboldal feltörése kellemetlen. A számlázási lánc feltörése könnyen pénzbe kerülhet.

Mi a négy legnagyobb pénzügyi kockázat?

1. Számlaszám-csere és hamis fizetési felszólítás. Aki bejut a számlázóba vagy a levelezési beállításokba, valódi rendszerből küldhet hiteles kinézetű számlát vagy „bankszámlaszám-változás” értesítést. Ez a céges e-mail-csalás (BEC) klasszikus mintája. A módszer nem új. Most viszont nagyon sok rendszer egyszerre nyitott.

2. Adatszivárgás és bejelentési kötelezettség. Ha a támadó hozzáfér a vevői és partneradatokhoz, az adatvédelmi incidens. A GDPR 33. cikke szerint ezt a tudomásszerzéstől számított 72 órán belül be kell jelenteni a NAIH-nak, ha az az érintettekre kockázatot jelent. NIS2 alá tartozó cégnél a kiberbiztonsági végrehajtási rendelet szerint az első jelentés 24 órán belül esedékes.

3. Visszaélés a NAV-kapcsolattal. A technikai felhasználó adataival a cég nevében lehet kommunikálni a NAV gépi interfészével. Ez a számlák listájának lekérdezését jelenti partnerekkel és összegekkel együtt, vagyis üzleti titok kiszivárgását. Ezért gyanú esetén nem elég a szervert megjavítani: a hozzáférési adatokat is cserélni kell. Ez szerencsére gyors: nem kell új technikai felhasználót létrehozni, a meglévő adatlapján bármikor új kulcsok generálhatók.

4. Leállás a legrosszabb pillanatban. Az NKI szerint, ha a frissítés nem megoldható azonnal, kockázatelemzés alapján az internetről elérhető rendszert ideiglenesen le kell választani. Ha ez a webshop vagy a számlázó, a számlakiállítás is megáll. Érdemes most eldönteni, mi a B-terv, nem akkor, amikor már nincs számlázó.

Kinek a dolga a frissítés?

A PHP frissítése szinte soha nem a cégvezető feladata, de a felelős kijelölése igen. A legtöbb magyar KKV-nál három helyzet fordul elő, és mindegyikben más a teendő.

A legnagyobb kockázat ott van, ahol erre a kérdésre senki nem tud válaszolni. Tipikusan ilyen a pár éve egy szabadúszó által épített webshop, ahol az átadás után senki nem kapott megbízást a szerveroldali karbantartásra.

Mit tegyél ezen a héten?

Hat lépés, amelyhez nem kell informatikusnak lenned. Az első kettőt ma érdemes elkezdeni.

1. Készíts pénzügyi rendszerleltárt. Írd össze, milyen webes rendszeren keresztül folyik számla, megrendelés, fizetés vagy pénzügyi adat. Ide tartozik a webshop, a számlázó, a könyvelői portál, a bérszámfejtő felület és a belső jóváhagyó rendszer is.
2. Kérj írásos megerősítést minden szállítótól. Ne telefonon, hanem e-mailben, hogy dokumentálva legyen. Lent találsz hozzá mintalevelet.
3. Nézd át a NAV technikai felhasználóidat. Az elsődleges felhasználó (az adózó, a törvényes képviselő vagy a bejelentett állandó meghatalmazott) KAÜ-azonosítással lép be, és a NAV Felhasználókezelő „Felhasználók” menüjében (NAV) látja, hány technikai felhasználó van a cég nevében. Ha olyat találsz, amelyről nem tudod, melyik rendszerhez tartozik, az már magában is kockázat. Ha a szállító nem tudja kizárni a behatolást, a technikai felhasználó adatlapján generálj új XML aláírókulcsot és cserekulcsot, cserélj jelszót, majd az új adatokat add meg a számlázóban is. A lépéseket képernyőképekkel a ControlliQ NAV-útmutatója mutatja be.
4. Cseréltesd a kulcsokat, ha gyanú van. Ugyanez vonatkozik a fizetési szolgáltató API-kulcsaira, a banki hozzáférésekre és az SMTP-jelszóra. A frissítés a jövőbeli betörést akadályozza meg. A korábban ellopott kulcsot csak a csere teszi használhatatlanná.
5. Szigorítsd a bankszámlaszám-ellenőrzést. A következő hetekben minden szállítói bankszámlaszám-változást ellenőrizz egy korábbról ismert telefonszámon. Ne a változást bejelentő e-mailben vagy számlán szereplő elérhetőségen.
6. Dokumentáld, mit kérdeztél és mit kaptál. Ki, mikor, melyik rendszert frissítette, és milyen választ adott. NIS2 alá tartozó cégnél ez megfelelési bizonyíték, de bármely cégnél aranyat ér, ha később vita vagy biztosítási kár lesz belőle.

Mintalevél a szoftverszállítóknak

Tárgy: PHP-sérülékenység (CVE-2026-109618, CVE-2026-109619) – kérünk írásos megerősítést

Tisztelt Partnerünk!

Az NBSZ NKI 2026. október 21-én riasztást adott ki a PHP futtatókörnyezet két kritikus sérülékenységéről. Kérjük, írásban erősítsék meg az alábbiakat az általunk használt [rendszer neve] szolgáltatással kapcsolatban:

1. Érinti-e a szolgáltatást a sérülékenység (fut-e PHP a rendszerben vagy annak bármely komponensében)?
2. Ha igen: telepítették-e a PHP javított verzióját vagy a disztribúció javított csomagját, és mikor? (A pontos verziószámra nincs szükségünk.)
3. Észleltek-e gyanús aktivitást a javítás előtti időszakban?
4. Szükséges-e részünkről bármilyen teendő, például hozzáférési adatok vagy kulcsok cseréje?

Köszönjük a gyors választ.

Ha egy szállító napokig nem válaszol, az is információ. Érdemes ehhez igazítani, mennyire bízod rá a pénzügyi adataidat.

Mit tegyen a könyvelőiroda?

A könyvelőirodák kockázata nagyobb, mert egy rendszerben sok ügyfél adata van. Ha az iroda ügyfélportálja vagy dokumentumfeltöltő felülete PHP-n fut, egy sikeres támadás nem egy cég számláit érinti, hanem az összes ügyfélét. Ugyanez igaz, ha az iroda rendszere ügyfelek NAV technikai felhasználóit tárolja a számlaadatok letöltéséhez.

Három dolgot javaslunk az irodáknak. Ellenőrizd a saját portálod PHP-verzióját és üzemeltetőjét, ugyanazzal a mintalevéllel. Tájékoztasd röviden az ügyfeleidet, hogy a számlázóik szállítójától kérjenek megerősítést, mert sokan erről nem fognak hallani. Ha pedig az irodád kezeli ügyfelek technikai felhasználóit, írd össze, hol vannak tárolva, hogy gyanú esetén gyorsan cserélni tudd őket.

Mennyire sürgős valójában?

Nagyon. A hibák részletei a Huntress szerint már a javítás előtt kiszivárogtak. A Tenable összefoglalója szerint az Amazon már október 17-én, négy nappal a nyilvánosságra hozatal előtt rögzített kihasználási kísérletet a csapdarendszerein. A watchTowr mindkét hibára lát támadási kísérleteket, a Cloudflare pedig korai támadásokról számol be.

A kép nem egyértelmű, és ezt érdemes őszintén kimondani. A CISA október 21-én még nem észlelt aktív kihasználást. A PHP-projekt a kiadáskor nem talált működő támadókódot a kiszivárgott példák között. Sikeres, megerősített betörésről eddig nincs hivatalos információ.

A cégvezetői döntést ez nem változtatja meg. Egy biztonsági kutató becslése szerint több mint 1,3 millió internetről elérhető szerver lehet sérülékeny (Tenable). Ha a részletek kiszivárogtak, és többen próbálkoznak, a sikeres támadás csak idő kérdése.

Mit tettünk a ControlliQ-ban?

A ControlliQ-t a Composite Solutions fejleszti és üzemelteti, így a frissítés a mi feladatunk volt. A javított PHP hivatalosan október 21-én 16:00-kor jelent meg. A mi környezetünkben telepíthető csomag formájában 23:43-kor vált elérhetővé, és azonnal telepítettük. A javítás a szerveroldalon történt, a felhasználóinknak ehhez semmit nem kell tenniük.

A pontos verziószámot szándékosan nem közöljük. Ez nem titkolózás, hanem bevett biztonsági gyakorlat: minél kevesebbet árul el egy rendszer a saját felépítéséről, annál nehezebb célzottan támadni. Ha extra óvatosságból mégis cserélnéd a NAV technikai felhasználód kulcsait, a NAV-útmutatónk végigvezet rajta. Az új adatokat az Integrációk oldalon a NAV Online Számla kártyán tudod megadni, a rendszer mentéskor azonnal ellenőrzi a kapcsolatot.

Ez a felhős szolgáltatás egyik kevésbé látványos előnye. A futtatókörnyezet frissítése a szolgáltató felelőssége, és egy ilyen riasztásnál nem neked kell kideríteni, ki nyúl hozzá. Ettől függetlenül a fenti mintalevelet nekünk is nyugodtan elküldheted, írásban is megerősítjük a fentieket.

Mi a tanulság?

A kérdés nem az, hogy melyik PHP-verzió a javított, hanem az, hogy tudod-e, hol vannak a pénzügyi adataid, és ki felel értük. Ha erre egy riasztás napján nem tudsz válaszolni, a következő riasztásnál sem fogsz. Ezt a térképet most, nyugodt körülmények között érdemes elkészíteni.

A pénzügyi rendszerleltár egyébként nemcsak biztonsági kérdés. Ugyanez a térkép mutatja meg, hol fut kézzel, e-mailben vagy Excelben az adat a rendszerek között. Erről a pénzügyi automatizálás KKV-knak cikkünkben és az Excel-hibák valós költségéről szóló elemzésünkben írtunk részletesebben.

Gyakran ismételt kérdések

Online számlázót használok, nekem is kell valamit tennem?

Frissítened nem kell, ez a szolgáltató dolga. Kérj tőle írásos megerősítést, hogy telepítette-e a javítást, és kell-e cserélned bármilyen hozzáférési adatot. Ha a szolgáltató gyanús aktivitást észlelt, cseréltesd a NAV technikai felhasználó jelszavát és kulcsait.

Elég, ha a webshopban frissítem a WordPresst és a bővítményeket?

Nem. A hiba a PHP futtatókörnyezetben van, nem a WordPressben vagy a WooCommerce-ben. Ezt csak a PHP javított verziója vagy a Linux-disztribúció javított csomagja oldja meg, a frissítés után a PHP-folyamatok újraindításával együtt.

Miért kellene lecserélnem a NAV technikai felhasználó kulcsait, ha a rendszert már frissítették?

Mert a frissítés csak a jövőbeli betörést akadályozza meg. Ha a támadó a javítás előtt bejutott, a konfigurációban tárolt jelszót és kulcsokat már ismerheti. Ezeket csak a csere teszi használhatatlanná. Ha a szállító nem tudja kizárni a behatolást, a csere a biztonságosabb döntés. Nem kell hozzá új technikai felhasználó: a NAV Felhasználókezelőben a meglévő adatlapján bármikor új kulcsok generálhatók (útmutató).

Adatvédelmi incidensnek számít, ha a számlázóm sérülékeny volt?

Önmagában a sérülékenység nem incidens. Ha viszont kiderül, hogy illetéktelen hozzáfért a vevői vagy partneradatokhoz, az adatvédelmi incidens. A GDPR szerint 72 órán belül be kell jelenteni a NAIH-nak, ha az érintettekre kockázatot jelent. Konkrét esetben fordulj adatvédelmi szakemberhez.

Honnan tudom, hogy a könyvelőm rendszere érintett-e?

Kérdezd meg tőle közvetlenül. A fenti mintalevél neki is elküldhető. Egy felkészült irodának egy-két napon belül tudnia kell válaszolni, hogy fut-e PHP az ügyfélportálja vagy dokumentumkezelője alatt, és frissítették-e.

Ez a cikk tájékoztató jellegű, nem minősül jogi vagy informatikai biztonsági tanácsadásnak. A helyzet gyorsan változik, az adatok 2026. október 22-i állapotot tükröznek.