Ugrás a tartalomhoz
Labs

Biztonsági riasztásFrissítve

Kritikus PHP-hiba: ha a weboldala PHP-n fut, most kell lépnie.

A PHP2Shell néven ismert két sebezhetőségen keresztül egy támadó bejelentkezés nélkül futtathat kódot a szerverén. Érintettek a WordPress, WooCommerce, Drupal, Joomla, Magento és Laravel oldalak is. A javítás október 21. óta elérhető — mi ellenőrizzük a rendszerét, telepítjük a javítást, és utána megnézzük, nem történt-e közben baj.

php2shell — advisoryTények
Javítás elérhető · támadási kísérletek folynak
Azonosítók
CVE-2026-109618, CVE-2026-109619
Súlyosság
Kritikus — CVSS 9.2
Kell bejelentkezés?
Nem
Érintett
PHP 5.4-től 8.5-ig
Javítva
8.5.12 · 8.4.27 · 8.3.36 · 8.2.35
Nincs hivatalos javítás
PHP 8.1 és régebbi
Kihasználás
Támadási kísérleteket jelentett a Cloudflare és a watchTowr

Ingyenes ellenőrzés

Érintett a weboldala? Tudja meg 10 másodperc alatt.

Adja meg a címét, és megnézzük, mit árul el nyilvánosan a szervere. Vagy írja be a PHP-verziót, ha már tudja.

Egyszer lekérjük a nyilvános nyitóoldalát, és csak azt nézzük, amit a szerver magától elárul. Támadó kérést nem küldünk. Az ellenőrzött címet feljegyezzük.

Kockázat

Mit jelent ez egy cég számára?

Átvehetik a szerverét

Kódfuttatás bejelentkezés nélkül: a támadó kártevőt telepíthet, spamet küldhet, átirányíthatja a látogatóit, vagy bankkártyaadatokat lophat a webshop fizetési oldaláról.

Kiolvashatják a szerver memóriáját

A hiba kódfuttatás nélkül is kiszivárogtathatja a memóriát — jelszavakat, API-kulcsokat, munkamenet-azonosítókat —, akkor is, ha az oldalon nincs bejelentkezés.

Az adatvédelmi felelősség az Öné

Ha személyes adatok kerülnek illetéktelen kézbe, a GDPR szerint ezt általában 72 órán belül be kell jelenteni a NAIH-nak. Egy frissítés ennél jóval olcsóbb.

Érintettség

Milyen PHP-verziót futtat?

Minden weboldalt kiszolgáló PHP-telepítés érintett: PHP-FPM, Apache mod_php, php-cgi, FrankenPHP és LiteSpeed. A legnagyobb kockázatot a mod_php jelenti.

  • 8.5.12, 8.4.27, 8.3.36, 8.2.35 vagy újabb

    Javítva

    A PHP-val nincs teendő — ellenőrizze, hogy minden szerver és aldomain ezt futtatja.

  • 8.2 – 8.5, régebbi javítóverzió

    Sebezhető

    Frissítés az ág javított kiadására. A 8.2 támogatása 2026. december 31-én megszűnik.

  • 7.4 – 8.1

    Sebezhető, hivatalos kiadás nélkül

    Átállás 8.3-ra vagy 8.4-re, vagy a szolgáltató, illetve a disztribúció javított csomagja. A PHP csak forráskódszintű foltot tett közzé.

  • 5.4 – 7.3

    Sebezhető, javítás nincs

    Sürgős átállás támogatott verzióra; addig ideiglenes védelem vagy karbantartási mód.

  • Shoprenter, Unas, Shopify, Wix

    A szolgáltató felel érte

    Ők üzemeltetik és javítják a szervereket. Az egyedi kiegészítők vagy a mellettük futó saját szerverek viszont érintettek lehetnek.

Amit mi csinálunk

Amit mi csinálunk — már ma.

Egy felelős csapat az első ellenőrzéstől az írásos jelentésig — Önnek nem kell kibogoznia, melyik tanács vonatkozik az Ön rendszerére.

  1. 01

    Felmérés

    Megkeressük az összes helyet, ahol PHP fut: éles oldal, teszt- és elfelejtett aldomainek, konténerek, admin felületek. A verziót a webes környezetben ellenőrizzük, nem csak parancssorban.

  2. 02

    Javítás

    Frissítjük a PHP-t, vagy egyeztetünk a tárhelyszolgáltatóval. Régi (7.4–8.1) PHP esetén átállítjuk 8.3-ra vagy 8.4-re, és teszteljük, hogy a bővítmények és a sablon továbbra is működnek.

  3. 03

    Ideiglenes védelem

    Ha a frissítés nem lehet azonnali, a hivatalos ideiglenes beállításokkal és kérésszűréssel szűkítjük a támadási felületet — tudva, hogy ez nem helyettesíti a javítást.

  4. 04

    Utóellenőrzés

    Átnézzük a naplókat az ismert nyomok után, ellenőrizzük az adminfelhasználókat és a módosított fájlokat, és ha kell, lecseréljük a jelszavakat, API-kulcsokat és a WordPress biztonsági kulcsait.

  5. 05

    Írásos jelentés

    Mit találtunk, mit javítottunk, milyen kockázat maradt. Odaadhatja a vezetőségnek vagy a biztosítójának.

Ideiglenes védelem

Ma nem tud frissíteni? Addig ezt tegye.

A PHP biztonsági közleményének ideiglenes beállításai. Csökkentik a kockázatot, de a PHP saját szavaival: nem teszik biztonságossá a telepítést.

php.ini · php-fpm pool
  • memory_limit = -1

    php_admin_value-val beállítva, hogy az alkalmazás ne írhassa felül (CVE-2026-109618).

  • post_max_size = 8M

    Maradjon alacsony; feltöltésekhez legfeljebb 32M.

  • session.upload_progress.enabled = 0

    CVE-2026-109619.

  • fatal_error_backtraces = 0

    Csak PHP 8.5 alatt.

Utána indítson újra minden PHP-folyamatot (PHP-FPM, Apache).

  • A memory_limit = -1 mellett egyetlen kérés is elfogyaszthatja a szerver memóriáját: figyelje.
  • A WordPress vagy a webshop karbantartási módja nem véd: a PHP még azelőtt feldolgozza a kérést, hogy az alkalmazás ellenőrizné.
  • A Cloudflare WAF-szabályai csak akkor segítenek, ha a szerver kizárólag a Cloudflare felől fogad forgalmat.
  • Ne telepítsen ismeretlen „javító” bővítményt vagy bemásolt kódrészletet.

Árulkodó jelek

Jelek, amelyek támadásra utalhatnak.

  • Szokatlan, fájlfeltöltés-jellegű (multipart) kérések, amelyeket memórialimit-hibák követnek
  • Ismétlődő HTTP 500-as hibák
  • Szokatlanul hosszú vagy hibás PHPSESSID sütik
  • Megmagyarázhatatlan PHP-folyamat-újraindulások

Ezek egyike sem bizonyítja a betörést. Ha ilyet lát: frissítsen, kezelje a szervert potenciálisan feltörtként, és cserélje le a rajta tárolt jelszavakat és kulcsokat.

Gyakori kérdések.

Mi az a PHP2Shell?

Két kritikus PHP-sebezhetőség, a CVE-2026-109618 és a CVE-2026-109619 közös neve. Memóriakezelési hibák abban, ahogyan a PHP a végzetes hibákat — főleg a memória elfogyását — kezeli: a támadó bejelentkezés nélkül kódot futtathat a szerveren, vagy kiolvashatja a memóriáját. A PHP 2026. október 21-én adta ki a javításokat.

Érintett a WordPress-oldalam?

Igen, ha a szerverén javítatlan, 5.4 és 8.5 közötti PHP fut — a WordPress verziójától és a bővítményektől függetlenül. A kutatók a WordPress, a Drupal, a Joomla és a Magento friss verzióin is bemutatták a bejelentkezés nélküli támadást. A hiba a PHP-ban van, nem a WordPressben, ezért WordPress-frissítéssel nem javítható.

Megosztott tárhelyem van. Nem oldja meg a szolgáltató?

A szerver PHP-ját általában a szolgáltató frissíti, de a legtöbb csomagnál Ön választja ki, melyik PHP-verziót használja az oldala. Ha ez 8.1 vagy régebbi, lehet, hogy arra nem lesz javítás. Nézze meg a vezérlőpulton a kiválasztott verziót, és kérdezze meg a szolgáltatót, mikor telepítette a javítást.

Shoprenter vagy Unas webshopom van. Kell tennem valamit?

A bérelt webshopplatformok (Shoprenter, Unas, Shopify, Wix) saját maguk üzemeltetik és javítják a szervereiket, így a PHP-val Önnek nincs teendője. A mellette saját szerveren futó oldalt, blogot vagy integrációt viszont érdemes ellenőrizni.

Elég, ha az oldalam a Cloudflare mögött van?

Nem. A Cloudflare az ingyenes csomagban is bevezetett szabályokat az ismert támadási mintákra, de ezek ideiglenesek, és csak akkor érnek valamit, ha a szerver kizárólag a Cloudflare felől fogad forgalmat. A frissítést nem helyettesítik.

PHP 7.4-et használunk. Most mi lesz?

A PHP projekt a 8.1-es és régebbi ágakra nem ad ki hivatalos javítást (a 7.4–8.1 ágra csak forráskódszintű folt készült). A valódi megoldás az átállás 8.3-ra vagy 8.4-re. Régi WordPress-bővítményeknél vagy egyedi kódnál ez tesztelést igényel — ezt mi elvégezzük.

Honnan tudom, hogy feltörték-e az oldalamat?

Biztosan csak a szerver naplóiból és fájljaiból állapítható meg. Jellemző nyomok: memórialimit-hibák szokatlan kérések után, sok 500-as hiba, furcsa PHPSESSID sütik. Ha az oldal a javítás előtt sebezhető volt, érdemes lecserélni a jelszavakat és az API-kulcsokat — ezt az utóellenőrzés során elvégezzük.

Mennyibe kerül a javítás?

Mielőtt bármihez hozzányúlnánk, fix árat adunk. Ez attól függ, hány szerverről és milyen PHP-verziókról van szó: egy támogatott ágon belüli frissítés gyors munka, egy 7.4-ről induló átállás több tesztelést igényel. Partnereinknél a biztonsági frissítések a havidíj részei.

Ne várja meg az első incidenst.

Küldje el a weboldala címét. Még aznap megmondjuk, érintett-e, és mennyibe kerül a javítás.