PHP2Shell miatt leállt a bexio: a banki adatlekérés is kiesett

Mi történt a bexiónál 2026. október 21-én?

A svájci bexio kisvállalkozói és könyvelési szoftver október 21-én 11:08-kor, közép-európai nyári idő szerint biztonsági óvintézkedésként lekapcsolta a szolgáltatásait. A vállalat a két kritikus, PHP2Shell néven ismert PHP-sérülékenységre hivatkozott. A bexio hivatalos státuszoldalán közölt üzenet szerint a javítócsomagot még aznap várták, és csak biztonsági ellenőrzés után kívánták újraindítani az alkalmazást.

A státuszoldal jelentős kiesést jelzett a bexio Website, Office és Cockpit felületein, valamint a Payroll bérszámfejtési modulnál és a Banking / Fetch transactions funkciónál. A közzétett 21-i állapotjelentések egyikében az API is jelentős kiesésként szerepelt; a részrendszerek státusza és a frissítések az órák során változtak. Nem áll rendelkezésre olyan ellenőrzött, tételes lista, amely minden ügyfélnél egyformán jelentkező hatást igazolna.

A vállalat az ideiglenes kikapcsolást megelőző biztonsági döntésként indokolta, és közleményében azt állította, hogy az ügyfelek adatai biztonságban vannak. Ez nem ugyanaz az állítás, mint hogy minden egyes üzleti folyamat zavartalan maradt volna: a szolgáltatáskiesés a könyvelést és az adatkapcsolatokat akkor is akadályozhatta, ha nem történt bizonyított támadás.

Miért számít különösen a banki tranzakciólekérés kiesése?

A bexio nem egyszerű honlapszerkesztő. A svájci vállalkozások számlázást, ügyfél- és pénzügyi nyilvántartást, könyvelést, dokumentumkezelést és – az előfizetett szolgáltatásoktól függően – banki adatkapcsolatokat is kezelnek benne. A banki tranzakciók automatikus beolvasása segíthet abban, hogy a pénzügyi munkatársak a bankszámlán megjelent tételeket a könyveléssel és a nyitott számlákkal egyeztessék.

A bexio bankkapcsolati útmutatója külön „Retrieve transactions” műveletet mutat be. Az adatkapcsolat egyes bankoknál automatikus szinkronizálást is támogathat. Ha a bexio oldali adatlekérés nem működik, a bankban már könyvelt tranzakciók feldolgozása vagy a belső pénzügyi áttekintés átmenetileg késhet. Ez nem jelenti automatikusan, hogy a banki pénzmozgás is leállt.

Mi működhetett tovább? A SIX bLink és a banki interfészek külön rendszerek

A bexio státuszoldala a nagyobb üzleti alkalmazásleállás alatt a Banking interfaces és a SIX bLink komponenseket külön működőképesnek jelölte. A felsorolt egyes partnerbanki kapcsolatokat szintén működő állapotban tüntette fel. Ez az eset technológiai és üzemeltetési szempontból is fontos: egy bankadatokat fogyasztó alkalmazás kieshet úgy, hogy a banki adatkapcsolati platform önmagában nem áll le.

A bexio saját termékismertetője szerint a bLink-kapcsolatokon keresztül a megfelelő bankoknál automatikusan lekérhetők tranzakciók, és fizetési megbízások is továbbíthatók az e-banki rendszer felé. Az alkalmazásoldali elérhetetlenség tehát a vállalkozó számára akár fizetési előkészítési feladatokat is késleltethet. Nincs azonban bizonyíték arra, hogy a bexio-incidens következtében a bankok saját rendszereiben indított átutalások általánosan elakadtak volna.

A bexio adatkezelési tájékoztatója a banki interfészeket részben közvetlen banki együttműködésen, részben a SIX BBS AG bLink platformján keresztül nyújtott szolgáltatásként írja le. A kapcsolat az ügyfél hozzájárulásához és az adott bank technikai működéséhez kötött. A bLink svájci adatkapcsolati megoldás, amelyet nem szabad automatikusan azonosítani az Európai Unió PSD2-szabályozása szerinti valamennyi nyílt bankolási szolgáltatással.

Mitől okozhat egy PHP-hiba üzleti fennakadást?

A PHP2Shell a PHP futtatókörnyezetben felfedezett, CVE-2026-109618 és CVE-2026-109619 számú kritikus sérülékenységeket jelöli. A hivatalos PHP biztonsági közlemény alapján a hibák bizonyos konfigurációkban hitelesítés nélküli, távoli kódfuttatást is lehetővé tehetnek. Október 21-én a PHP fejlesztői kiadták a javított 8.2.35, 8.3.36, 8.4.27 és 8.5.12 verziókat.

A szolgáltatók előtt lényegében két sürgős feladat állt: a támadási felület csökkentése és a tényleges javított rendszerek visszakapcsolása. Egy üzleti alkalmazás esetében a technikai hiba önmagában nemcsak a webes bejelentkezést érintheti, hanem az összekapcsolt API-kat, adatimportokat, automatizmusokat és adminisztrációs feladatokat is. A bexio leállítása azonban önmagában nem bizonyít sikeres kibertámadást.

Frissítés: Japánban közvetlen banki alkalmazásokat is leállítottak

2026. október 22-i kiegészítés. A svájci bexio esete elsősorban egy bankadatokat feldolgozó üzleti alkalmazás kieséséről szólt. Japánból azonban már olyan, konkrét banki közlemények is megjelentek, amelyek saját mobilalkalmazások és ügyintézési funkciók átmeneti korlátozását igazolják. Ezeket külön kell kezelni az országos elszámolási rendszerek működésétől.

Shizuoka Bank: a bank honlapja és a Shizugin mobilalkalmazás szünetelt

A Shizuoka Bank 2026. október 21-i hivatalos közleménye szerint a PHP biztonsági figyelmeztetése miatt megelőző intézkedésként ideiglenesen leállította a bank és cégcsoportja honlapjait, valamint a Shizugin mobilalkalmazást. A közlemény címe az internetbankolást is említi, de a részletes szolgáltatáslistában a honlap és a mobilapp szerepel. A helyi Televízió Shizuoka október 22-i tudósítása szerint a Shizugin Direct és a Business Portal tovább elérhető maradt. Nem teljes banküzemi leállásról beszélhetünk.

Toyama Daiichi Bank: a CRECO alkalmazás összes funkciója kiesett

A Toyama Daiichi Bank az úgynevezett First Bank with CRECO alkalmazást október 21-én japán idő szerint 17:00-tól rendkívüli biztonsági karbantartás miatt teljesen leállította, még a belépést is. Október 22-i hivatalos tájékoztatásában a lakáshitelek előzetes hitelbírálati igénylésének szünetelését is megnevezte. Ugyanakkor a Private Web és Business Web internetbanki rendszerek normál módon működtek. Eredeti karbantartási bejelentés.

au Jibun Bank: átmeneti hozzáférési problémák lehetőségére figyelmeztetett

Az au Jibun Bank október 22-én 00:40-kor, japán idő szerint közölte, hogy a PHP javításainak alkalmazása közben a weboldal, az internetbank és a mobilalkalmazás egyes részei átmenetileg elérhetetlenné válhatnak. Ez előzetes szolgáltatói figyelmeztetés, nem minden felsorolt csatornára igazolt tényleges kiesés. au Jibun Bank – hivatalos tájékoztatás.

Dai-ichi Hokuetsu Bank és értékpapírszolgáltatók: részleges intézkedések

A Dai-ichi Hokuetsu Bank október 21-én egyes webes és ügyintézési szolgáltatásait korlátozta. A bank október 22-én külön visszaállítási közleményben megerősítette, hogy a bankfióki időpontfoglalás újra használható, miközben más szolgáltatásoknál még fennálltak korlátozások. Az MUFG Morgan Stanley Securities október 21-én az online számlanyitás, a passkey-regisztráció és a NISA-számla igényléséhez kapcsolódó digitális személyazonosítást szüneteltette. Ez utóbbi értékpapír-szolgáltatói ügyfélazonosítási kiesés, nem átutalási rendszerhiba. A brókercég hivatalos közleménye.

A Kyodo News október 21-i híradása szerint a 77 Bank is leállított egyes szolgáltatásokat, a Mizuho Banknál pedig a fióki időpontfoglalás szünetelt. Ezeknél az itt idézett információ sajtóbeszámolón alapul, a pontos szolgáltatási listát és újraindítási időket külön üzemeltetői közlés nélkül nem általánosítjuk. Kyodo News – banki és pénzügyi intézkedések.

Fontos: nincs igazolt országos bankközi elszámolási kiesés

A Kyodo News az országos japán bankszövetség (Zenginkyo) tájékoztatására hivatkozva arról számolt be, hogy a bankközi fizetési rendszerek működésében nem észleltek a PHP-sérülékenységekhez köthető fennakadást. Ez összhangban áll azzal, hogy egy banki app, azonosítási felület vagy számlaadatokat kezelő külső szoftver kiesése nem szükségszerűen állítja le a tényleges számlavezetést és a pénzforgalmi elszámolást. Kyodo – bankszövetségi közlés, 2026. október 21–22.

Biztonsági tényhatár: az ismertetett banki intézkedések a közölt információk szerint megelőző karbantartások vagy hozzáféréskorlátozások. Nem jelentik azt, hogy a felsorolt bankokat sikeresen feltörték, ügyféladatok szivárogtak ki, vagy valamennyi banki tranzakció megszakadt. Állapot: 2026. október 22., reggel, az elérhető banki közlemények alapján.

Mit tehet egy vállalkozás, ha egy pénzügyi alkalmazása hirtelen nem érhető el?

1. Először az üzemeltető hivatalos státuszát ellenőrizze. A bexiohoz hasonló szolgáltatások esetében a státuszoldal megmutathatja, hogy az adatlekérés, az API, a számlázás vagy csak a webes belépés érintett-e. Jegyezze fel az esemény és az újraindítás idejét.
2. A bankszámlaadatokat a bank saját, hivatalos csatornáján is ellenőrizze. Ha a pénzügyi alkalmazás nem lát egy jóváírást vagy terhelést, attól az még megjelenhet a bank nyilvántartásában. Ne tekintse a sikertelen képernyőfrissítést bizonyítéknak a banki tranzakció elmaradására.
3. Kerülje a fizetési megbízások vak, ismételt indítását. Egy lelassult vagy nem válaszoló felület miatt nem mindig egyértelmű, hogy egy előző műveletet már továbbítottak-e. Mielőtt újrapróbálkozna, ellenőrizze a banki megbízás állapotát a duplikációk elkerülésére.
4. A helyreállítás után egyeztesse az adatokat. Nézze meg, hogy a kiesés időszakának banki tételei bekerültek-e a könyvelésbe, az automatizált szinkronizálás behozta-e a lemaradást, és a csatlakozó API-folyamatok tovább működnek-e.
5. Legyen üzletmenet-folytonossági terve. Dokumentálja, mely kulcsfolyamatok függnek egyetlen külső pénzügyi szolgáltatótól, ki jogosult válsághelyzetben banki kivonatot lekérni, és miként végezhető el a sürgős egyeztetés szükség esetén ellenőrzött alternatív módon.

Miért fontos ez a magyar cégeknek?

A bexio svájci szolgáltató, ezért a kiesése nem jelent magyar banki üzemzavart. A mögötte álló probléma azonban minden olyan magyar vállalkozásnak ismerős lehet, amely számlázóprogramot, ERP-rendszert, banki API-kapcsolatot vagy felhős könyvelési szolgáltatást köt össze. Ha a bankszámlától független üzleti alkalmazás leáll, a pénz mozgása és a pénzügyi adminisztráció valós idejű láthatósága eltérhet egymástól.

Különösen webshopoknál, szolgáltató vállalkozásoknál és automatizált könyvelést használó cégeknél fontos előre tudni, hogy egy kiesés a fizetés indítását, a fizetés állapotának lekérését vagy pusztán a könyvelési egyeztetést érinti-e. Ezek más-más teendőt igényelnek, és gyakran más üzemeltetőnél kell keresni a hibát.

Összegzés: a PHP2Shell miatt meghozott bexio-döntés láthatóvá tette a digitális pénzügyi szolgáltatások egymásra épülését. A bankok, az adatkapcsolati platformok és a könyvelési alkalmazások külön rendszerek, de egyetlen láncot alkotnak a vállalkozás napi munkájában. A tanulság nem az, hogy az összekapcsolás önmagában veszélyes, hanem hogy a szolgáltatásfüggőségeket és a helyreállítási utakat ugyanúgy kezelni kell, mint a banki kockázatokat.

A cikk a 2026. október 21-i státuszbejegyzéseken alapul. A részfunkciók állapota az esemény során változhatott; teljes helyreállítási időpontot csak végleges szolgáltatói tájékoztatás alapján közlünk. A szélesebb nemzetközi hatásról lásd országonkénti PHP2Shell-körképünket, a sérülékenység technikai hátteréről pedig külön elemzésünket.