PHP2Shell: amikor a weboldaladhoz jelszó sem kell

Októberben két olyan hibát javítottak a PHP-ban, a programnyelvben, amin a weboldalak nagyjából 70%-a fut, köztük minden WordPress-oldal, hogy állami szervezetek és nagyvállalatok inkább lekapcsolták a weboldalaikat, amíg frissítettek. Mit jelent ez egy kisvállalkozás oldalára, és mit érdemes most megtenned?

Mi történt?

2026. október 21-én a PHP fejlesztői sürgősségi javítást adtak ki két hibára. A szakma PHP2Shell néven emlegeti őket, a hivatalos jelük CVE-2026-109618 és CVE-2026-109619. Mindkettő 9,2-es súlyosságot kapott a tízes skálán, ami a „kritikus” kategória.

A részletek egy nappal a javítás előtt kiszivárogtak, és az Amazon már négy nappal a javítás megjelenése előtt támadási kísérletet látott. Több ország kiberbiztonsági hatósága adott ki figyelmeztetést, itthon a Nemzeti Kiberbiztonsági Intézet is. Volt, ahol kormányzati oldalakat kapcsoltak le óvatosságból, és egy időre még a Wikipédia egyik belső rendszere is leállt.

Tényleg olyan, mint a filmekben?

Ismered a jelenetet: a hekker begépel pár sort, és már bent is van. A valóságban ez ritkán ilyen egyszerű, de ennél a hibánál nagyon közel járt hozzá. A támadónak nem kellett jelszó, nem kellett felhasználói fiók, és nem kellett, hogy bárki rákattintson valamire. Elég volt egyetlen, ügyesen összerakott kérést küldenie a weboldalnak, és a saját programját futtathatta a szerveren. A hibát felfedező kutatók ezt egy teljesen friss, frissített WordPressen mutatták be.

Ha valaki a saját programját futtatja a szervereden, onnantól az övé az oldalad: átírhatja, átirányíthatja a látogatóidat egy csaló oldalra, elhelyezhet rajta kártevőt, vagy elviheti az ott tárolt adatokat, például a kapcsolatfelvételi űrlapon érkezett üzeneteket.

A teljes képhez hozzátartozik: a támadás nem minden szerveren működik egyformán, és tömeges feltörési hullámot eddig nem erősítettek meg. Az amerikai kiberbiztonsági hivatal (CISA) viszont október 26-án felvette mindkét hibát a ténylegesen kihasznált sebezhetőségek listájára, vagyis valódi támadásokban is használják őket. És ami a legfontosabb: a Censys mérése szerint két héttel a javítás után a sebezhető PHP-t futtató szerverek többsége, 46 millióból 29 millió, még mindig nem volt frissítve.

Miért nem elég a WordPress frissítése?

Képzeld el, hogy a WordPress a bolt, a PHP pedig az épület, amiben a bolt van. Ezúttal nem a boltban volt a hiba, hanem az épület bejárati ajtajában. Hiába frissíted a WordPresst, a bővítményeket és a sablont, hiába telepítesz biztonsági bővítményt: ezek mind a boltban vannak, az ajtót nem cserélik ki.

Az ajtót az cseréli, aki az épületet üzemelteti, vagyis a tárhelyszolgáltatód. A javított PHP-verziók: 8.5.12, 8.4.27, 8.3.36 és 8.2.35. A nagy szolgáltatók többsége október végére telepítette őket. A gond ott van, ahol senki nem figyel: a régi tárhelycsomagokon, a saját szervereken, és azoknál az oldalaknál, amelyeket évek óta senki nem gondoz.

Mit tegyél most?

  1. Nézd meg, milyen PHP-n fut az oldalad. A WordPress adminban az Eszközök menüben találod a webhely állapotát mutató oldalt (angolul Site Health). Ott az Információ fülön, a Szerver résznél látszik a PHP verziója. Ha alacsonyabb a fenti számoknál, az még nem biztos, hogy baj: egyes szolgáltatók a régi verziószám mellett is telepítik a javítást. Ezt csak ők tudják megmondani.
  2. Kérdezd meg a tárhelyszolgáltatódat. Ezt az üzenetet bemásolhatod:
    Jó napot! A weboldalam ([a domain neve]) a [verziószám] PHP-verziót használja. Telepítették már a szerveremre a PHP2Shell (CVE-2026-109618 és CVE-2026-109619) javítását? Ha még nem, mikorra várható? Köszönöm!
    Ha azt válaszolják, hogy „bekapcsoltunk egy tűzfalszabályt”, az jó hír, de nem ugyanaz, mint hogy „frissítettük a PHP-t”. Az utóbbit kérdezd, amíg nem kapsz rá egyértelmű választ.
  3. Ha 8.1-es vagy régebbi PHP-n vagy, válts. Ezek a verziók hivatalosan már nem kapnak javítást, csak egyes szolgáltatók foltozzák őket a saját hatáskörükben. A legtöbb tárhelynél a kezelőfelületen át lehet állni újabbra. Előtte készíts mentést, és utána nézd végig a fontos oldalakat, mert egy régi bővítmény elromolhat az új verzión.
  4. Ha az oldalt senki nem gondozza, nézesd meg. Ha a fejlesztő, aki készítette, már nem elérhető, vagy évek óta senki nem lépett be az adminba, érdemes megnézetni, nem járt-e már bent valaki. Gyanús jelek: ismeretlen adminisztrátor a felhasználók között, az oldal néha egy idegen oldalra dob át, a Google figyelmeztetést mutat a találat mellett, vagy furcsa, nem általad írt oldalak jelennek meg a keresőben.

Miért írok erről?

Mert pont ez az, amiért a Kotodát elindítottam. A WordPress jó eszköz, de egy kisvállalkozás bemutatkozó oldalához egy egész programot kell a szerveren futtatni, és azt folyamatosan frissíteni kell: a WordPresst, a bővítményeket, a sablont és most már a PHP-t is. Ha ez elmarad, előbb-utóbb baj lesz belőle.

Az általam készített oldalak egyszerű, kész HTML-fájlok. A szerveren nem fut PHP, nincs adatbázis és nincs admin felület, így egy ilyen hibával nincs mit elindítani. Ettől egy oldal nem lesz sebezhetetlen, de a támadási felület nagy része egyszerűen nincs ott, és nem kell minden ilyen hírnél aggódnod.

Források

← Vissza a bloghoz