php2shell: két kritikus PHP-hiba.
Mit tegyél ma, attól függően, hol fut az oldalad?

2026. október 21-én a PHP fejlesztői két súlyos hibát javítottak. A PHP az a programnyelv, amelyen a magyar weboldalak többsége fut: a WordPress-oldalak, a legtöbb webáruház és a legtöbb egyedi fejlesztésű céges oldal is. A hibán keresztül egy támadó bejelentkezés nélkül átveheti az irányítást a szerver fölött. A javítás kész, de nem magától települ: valakinek frissítenie kell a szerveren a PHP-t.

Érint ez téged?

Ha van weboldalad, nagy valószínűséggel igen. A hiba nem a WordPressben vagy egy bővítményben van, hanem magában a PHP-ban, ezért minden PHP-s oldalt érint, függetlenül attól, milyen rendszer épül rá. A PHP szerint minden webes kiszolgálási módot érint, a legnagyobb kockázatot az Apache-modulos (mod_php) futtatásnál látják. Ez a magyar bérelt tárhelyek egy részénél ma is bevett megoldás.

Miért baj ez?

Egy ilyen hibával a támadó saját programot futtathat a szervereden. Ebből a gyakorlatban ez szokott lenni:

• ellopják az ügyféladatokat vagy a webáruház rendeléseit,
• kártékony kódot tesznek az oldaladra, amitől a Google és a böngészők figyelmeztetnek a látogatóknak,
• a szervered spam- vagy támadóhálózat része lesz, és feketelistára kerül,
• zsarolóvírus titkosítja az oldalt és az adatbázist.

Az első támadási kísérleteket több biztonsági cég már a javítás megjelenésének napján látta. Az, hogy pontosan hány oldalt törtek fel, ma még nem tudható. Érdemes úgy kezelni, mintha holnap a te oldalad következne.

Mit tegyél? Három lépés

1. Találd ki, hol fut az oldalad. Három eset van: bérelt tárhelyen (Tárhely.eu, Rackhost, Websupport, Forpsi és társaik), egy ügynökség vagy fejlesztő kezelésében, vagy saját szervereden. Ha nem tudod, nézd meg, kinek fizeted a tárhelyszámlát, ő a kiindulópont.
2. Kérdezz rá írásban: bérelt tárhelynél a szolgáltató frissít, ügynökségnél ők. Neked annyi a dolgod, hogy visszaigazolást kérj. Lent találsz egy kész levelet, csak másold ki.
3. Ellenőrizd a PHP verzióját. A tárhely vezérlőpultján (cPanel: „Select PHP Version”, Plesk: „PHP beállítások”) látszik a verziószám. A javított verziók: 8.5.12, 8.4.27, 8.3.36 és 8.2.35. Egy fontos kivétel: az Ubuntu és a Debian a javítást úgy teszi be, hogy a verziószám nem változik. Ott a szolgáltató szava számít, nem a szám.

Tárgy: PHP biztonsági frissítés (CVE-2026-109618, CVE-2026-109619)

Üdvözlöm!

A(z) PÉLDA.HU oldalam az Önök tárhelyén fut. Kérem, erősítsék meg, hogy a 2026. október 21-én kiadott PHP biztonsági javítást (php2shell, CVE-2026-109618 és CVE-2026-109619) telepítették a szerverre, és írják meg, pontosan melyik PHP-verzió fut most az oldalam alatt.

Köszönöm,
NÉV

Amit nem kell, és amit ne tegyél

• A WordPress vagy a bővítmények frissítése nem oldja meg. A WordPress fejlesztői is kimondták: nem kell és nem is lesz WordPress-frissítés ehhez, a javítás a szerver PHP-jában van.
• Ne telepíts „php2shell-javító” bővítményt vagy kódrészletet, amit üzenetben vagy fórumon küldenek. A biztonsági cégek már figyelmeztettek, hogy a keringő „javítások” egy része kártevő.
• Ne várd meg, amíg a híreket elfelejtik. A javítás kint van, a támadók is tudják. Egy e-mail a szolgáltatónak ma öt perc.

Shoprenteren, UNAS-on, Wixen van az oldalad?

Ezeknél a bérelt rendszereknél a szolgáltató üzemelteti a teljes szervert, neked nincs hozzáférésed a PHP-hoz, tehát teendőd sincs. Egy rövid kérdést azért érdemes feltenni az ügyfélszolgálatnak, hogy visszaigazolják a frissítést.

Mikor vagy rendben?

Ha a szolgáltatód vagy a fejlesztőd írásban visszaigazolta, hogy a javított PHP fut, és a vezérlőpulton is ez látszik. Ha saját szervered van, vagy a részletek érdekelnek, a technikai változatban parancsról parancsra leírtuk, mit kell tenni.

A PHP projekt 2026. október 21-én, 16:00-kor (CEST) soron kívüli biztonsági kiadást tett közzé két kritikus, hitelesítés nélkül kihasználható távoli kódfuttatási hibára: CVE-2026-109618 és CVE-2026-109619, közös nevükön php2shell. Mindkettő CVSS 4.0 szerint 9,2. Javított verziók: 8.5.12, 8.4.27, 8.3.36, 8.2.35. Lent az áll, amit mi ma megtettünk a saját szerverünkön, és az, hogy neked mi a teendőd attól függően, hol fut az oldalad.

Röviden

• Két hiba a PHP magjában, nem egy keretrendszerben vagy bővítményben. Minden webes futtatási mód érintett: PHP-FPM, Apache mod_php, php-cgi, FrankenPHP, LiteSpeed. A PHP szerint a kockázat a mod_php-nál a legnagyobb.
• Teljes megoldás csak a frissítés. A PHP saját szavaival: az enyhítő beállítások „csökkentik a kitettséget bizonyos támadási utakon, de nem teszik biztonságossá a telepítést”.
• A 8.1 és régebbi ágak nem kapnak hivatalos kiadást, de a PHP biztonsági csapata minimális forrásjavítást adott a 7.4, 8.0 és 8.1 ághoz, a disztribúciók pedig visszaportolják.
• Ubuntun és Debianon a php -v a frissítés után is a régi számot mutatja. Ott a csomagverziót nézd, nem a PHP-ét.
• Támadási kísérleteket több cég jelentett már a kiadás napján, tömeges feltörésről egyelőre nincs megerősített adat. Úgy kezeld, mintha lenne.

Mi történt, és mi a két hiba

Október 20-án a PHP előzetes figyelmeztetést adott ki, hogy másnap két kritikus hibát javít. A CVE-azonosítók kiszivárogtak, és a kiadás a tervezett október 22. helyett 21-én, 14:00 UTC-kor megjelent. A Cloudflare már hajnali 05:02-kor (CEST) élesítette a tűzfalszabályait, vagyis a nagy szolgáltatók előre megkapták a részleteket.

A PHP tanácsadója a két hibát így írja le (saját fordításban):

• CVE-2026-109618, „RCE via OOM corruption”: a memóriahiány kezelése úgy szakíthatja meg a PHP-t, hogy a kérés belső adatai csak részben inicializálódtak. A kérés lezárásakor a PHP az érvénytelen adatot érvényesként kezelheti.
• CVE-2026-109619, „RCE via stale global state”: a kéréshez tartozó belső állapot túlélheti a mögötte lévő memória felszabadítását. Ugyanazon a workeren egy következő kérés használhatja ezt az elavult állapotot, mielőtt a normál inicializálás visszaállítaná.

Hétköznapi nyelven: a PHP a kérések között megosztott worker-folyamatokban fut, és a két hiba azt használja ki, hogy hibahelyzetben (memóriahiány, végzetes hiba) a takarítás hiányos marad. A Sansec elemzése szerint a sérülékeny kód a PHP 5.4-ig nyúlik vissza, tehát gyakorlatilag minden ma futó PHP érintett. A PHP megerősítette, hogy a mod_php-nál létezik bemutatott kihasználás, ahol egy hitelesítés nélküli kérés már az alkalmazáskód futása előtt elindítja a támadást.

Javított verziók, disztribúciós csomagok, lejárt ágak

A Remi repo (gyakori CentOS, Alma, Rocky szervereken) 21-én még nem adott frissítést, és a bérelt tárhelyeken használt CloudLinux és cPanel csomagok is később érkeznek, mint a sima disztribúciós csomagok. Ezért a bérelt tárhelyek egy része később lesz javítva, mint egy saját VPS. Ez a kérdés a szolgáltatódnak szól, nem neked kell megoldanod.

Teendők aszerint, hol fut az oldalad

1. Bérelt (osztott) tárhely: cPanel, Plesk, DirectAdmin

A PHP-t a szolgáltató frissíti, te nem férsz hozzá a csomagokhoz. A teendőd: nézd meg a vezérlőpulton a PHP-verziót (cPanel: „Select PHP Version” vagy „MultiPHP Manager”, Plesk: a domain „PHP beállítások” lapja), és kérj írásos visszaigazolást a szolgáltatótól. Ha több PHP-verzió közül választhatsz, és a tiéd 7.x vagy 8.0/8.1, most jó alkalom átállni 8.3-ra vagy 8.4-re, mert azokra biztosan jön csomag. Előtte egy teszt-aldomainen próbáld ki, hogy az oldalad fut-e rajta.

2. Menedzselt rendszer: Shoprenter, UNAS, Wix, Webnode, menedzselt WordPress

Itt a szolgáltató üzemelteti a teljes szervert, neked a PHP-hoz nincs hozzáférésed, teendőd sincs. Egy rövid kérdést érdemes feltenni az ügyfélszolgálatnak, és eltenni a választ.

3. VPS vagy saját szerver: te frissítesz

Ubuntu 24.04, Apache + mod_php (ezt futtatjuk mi is):

sudo apt update
apt-cache policy libapache2-mod-php8.3 | head -3   # Candidate: 8.3.6-0ubuntu0.24.04.13
sudo apache2ctl configtest                          # "Syntax OK" nélkül ne menj tovább
sudo apt install --only-upgrade $(dpkg -l 'php8.3*' libapache2-mod-php8.3 | awk '/^ii/{print $2}')
dpkg -l libapache2-mod-php8.3 | tail -1             # .13 kell
ps -o lstart -C apache2 | head -2                   # újraindult-e az Apache a frissítés után

Ubuntu/Debian, PHP-FPM: ugyanez a csomagkör a php8.x-fpm csomaggal, utána sudo systemctl restart php8.3-fpm. Nézd meg, hogy tényleg újraindult minden worker, mert a régi folyamatokban a régi kód fut tovább.

Debian 12/13: apt update && apt install --only-upgrade 'php8.2*' (bookworm), illetve 'php8.4*' (trixie), aztán FPM- vagy Apache-újraindítás. A javított csomagverziók a fenti táblázatban.

Docker: a hivatalos php image-ek 8.3.36, 8.4.27, 8.5.12 címkéi tartalmazzák a javítást. Nem elég a konténert újraindítani: új image-et kell húzni és újraépíteni (docker compose pull && docker compose up -d --build). Ha a Dockerfile fix verzióra mutat (például php:8.3.30-fpm), emeld meg.

Remi, Ondřej PPA, egyéb külső tároló: nézd meg a tároló saját közleményét. A Remi 21-én még nem adott csomagot. Ha nem tudsz várni, a lenti enyhítések jönnek, és figyeld a tárolót.

Két tanulság a saját frissítésünkből: ne futtass vak apt upgrade-et, mert ha a gépen Docker is fut, a docker-ce frissítése újraindítja az összes konténert. És ha több szolgáltató több szerverén van oldalad, írd fel egy listába, melyiket mikor erősítették meg, mert holnapután már nem fogsz emlékezni.

4. Ügynökség vagy fejlesztő kezeli

Kérdezd meg, hol fut az oldal, és mikor települt a javítás. Egy jó válasz konkrét: szolgáltató, PHP-ág, csomagverzió, időpont. Ha a válasz „a WordPress naprakész”, az nem erre a kérdésre felel.

5. Cloudflare vagy más WAF van előtte

A Cloudflare a saját közlése szerint 03:02 UTC óta szűri a felismert támadási mintákat, és látta, hogy a támadók módosítgatják a terhelést a szabályok megkerülésére. Egy WAF időt ad, de nem helyettesíti a frissítést. A Cloudflare zárómondata is ez: frissítsd a PHP-t, és hagyd bekapcsolva a védelmet.

Ha most nem tudsz frissíteni

A PHP hivatalos enyhítései, a saját figyelmeztetésükkel együtt: ezek „csökkentik a kitettséget bizonyos támadási utakon, de nem teszik biztonságossá a telepítést”.

• CVE-2026-109619: session.upload_progress.enabled=0, majd minden worker újraindítása. Olyan helyen állítsd (php.ini, FPM pool, szerverkonfiguráció), amely a kérés feldolgozása előtt érvényesül. Az ini_set() és az FPM .user.ini erre nem jó. Ez a megerősített session-utat zárja, más változatokat nem.
• PHP 8.5-ön: fatal_error_backtraces=0 és worker-újraindítás.
• CVE-2026-109618: memory_limit=-1 olyan módon, amit az alkalmazás nem írhat felül (php_admin_value az FPM poolban vagy az Apache-konfigban), és ellenőrizd, hogy egyetlen könyvtár- vagy alkalmazásszintű beállítás sem tesz vissza véges limitet. Ez a vezérelhető memóriahibát veszi ki, de egy mögöttes allokációs hiba továbbra is elérheti a sérülékeny utat.
• post_max_size = 8M, ha nincs fájlfeltöltés, 32M, ha van; az upload_max_filesize maradjon alatta. A kérésméretet, a mezők számát, a multipart-részek számát és a fejlécek számát is érdemes korlátozni, úgy, hogy a Content-Length nélküli kérésekre is vonatkozzon.
• Konténer- vagy cgroup-limitet használj elérhetőségi korlátnak, lehetőleg úgy, hogy csak az érintett worker haljon meg. Ne használd helyette az RLIMIT_AS vagy RLIMIT_DATA korlátot, mert az pont a sérülékeny allokációs hibát idézheti elő.
• Távolítsd el az érvénytelen vagy elavult, kérésenként alkalmazott beállításokat, amelyek az inicializálás előtt diagnosztikát írnak ki. A hibaüzenet elrejtése (error_reporting, display_errors, @) nem segít.

Webáruháznál a Sansec egy durvább, átmeneti lépést is ajánl: a multipart/form-data kérések tiltása a webszerveren, vagy a bolt átmeneti csak-olvasható módba tétele, amíg a frissítés megtörténik. Ez feltöltést és egyes űrlapokat is megtör, tehát csak tudatosan, rövid időre.

Hogyan ellenőrizd, hogy tényleg javítva van

• Disztribúciós csomagnál a csomagverzió számít, nem a PHP-é: dpkg -s php8.3-cli | grep Version (Debian/Ubuntu), rpm -q php (RHEL-család). Ubuntu 24.04-en a jó válasz 8.3.6-0ubuntu0.24.04.13.
• Forrásból vagy hivatalos csomagból: php -v, illetve egy ideiglenes <?php echo PHP_VERSION; fájl, amit utána törölsz. 8.3.36 / 8.4.27 / 8.5.12 / 8.2.35 a jó.
• Újraindult-e a futó folyamat? A csomag telepítése nem jelenti, hogy a memóriában lévő régi kód leállt. Apache: ps -o lstart -C apache2, az indulási idő legyen a frissítés utáni. FPM: systemctl status php8.3-fpm, „Active since” a frissítés után.
• Bérelt tárhelyen: a vezérlőpult verziószáma és a szolgáltató írásos visszaigazolása. Ha a panel 8.3.6-ot mutat, az Ubuntu-alapú szervernél még lehet javított; kérdezz rá a csomagverzióra.

Kihasználják-e már?

Az első nap jelentései ellentmondásosak, ezért érdemes forrás szerint nézni:

• A PHP bemutatott kihasználásról ír mod_php alatt, de nem állítja, hogy valós támadást észleltek volna.
• A Cloudflare támadási forgalmat és a szabályokat kerülgető, módosított terheléseket látott, számokat nem közölt.
• A watchTowr mindkét hibát reprodukálta, és kísérleteket látott a saját csapdaszerverein.
• A Patchstack reggel „több aktív kihasználási esetről” írt, délután a saját adatai alapján „csak szondázó támadásokra, áttörés kemény bizonyítéka nélkül” enyhített, a cikk címe ettől még „attacks ongoing” maradt.
• A Huntress 16:00-ig (CEST) nem látott kihasználást a saját ügyfélkörében, és nem tudott működő PoC-ot reprodukálni.
• A Tenable szerint nyilvánosan kering „exploit” kód, de nem ellenőrizték, hogy működik-e, és figyelmeztet: az ilyen kód néha kártevővel van megspékelve.

A gyakorlati következtetés nem függ attól, melyik forrásnak van igaza: a javítás nyilvános, a hibát a támadók is látják, a kérdés napok, nem hetek.

Mit csináltunk mi ma

A saját szerverünk Ubuntu 24.04-en fut, Apache prefork + mod_php, 69 virtuális hoszttal (39 domain), köztük ügyféloldalakkal. Ma este ezt csináltuk, időbélyeggel (CEST):

• 21:40 – apt update; a jelölt csomag 8.3.6-0ubuntu0.24.04.13, vagyis a javított. Reggel még .12 volt.
• 21:45 – apache2ctl configtest: Syntax OK. Ha itt hiba lett volna, az újraindítás után az összes oldal állt volna.
• 22:07 – célzott frissítés csak a 13 PHP-csomagra, nem teljes apt upgrade, mert a gépen Docker is fut.
• 22:07:30 – az Apache újraindult. A kiesés ezred másodpercek és pár másodperc közötti, a fájlalapú PHP-sessionök megmaradtak, bejelentkezés nem veszett el.
• 22:20 – mind a 39 domain lekérdezve HTTPS-en: 38 a várt választ adja, egyetlen 500-as egy régi, külső adatbázisra mutató WordPress-másolat, amely már korábban is hibás volt.

Egy dolog, amire nem számítottunk: a php -v a frissítés után is 8.3.6-ot ír. Ez Ubuntun normális, a javítás a csomagban van, a verziószám nem változik. Aki csak a PHP verzióját nézi, tévesen hiheti, hogy nincs javítva, vagy fordítva, hogy már megvan.

Gyakori kérdések

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

Nem. A hiba a PHP-ban van, nem a WordPressben. A WordPress fejlesztői is közölték, hogy nem készül és nem is kell WordPress-frissítés ehhez. A javítást a szerver PHP-jának frissítése adja.

PHP 7.4-en vagy 8.1-en fut az oldalam. Mi van velem?

Hivatalos kiadás nincs ezekre az ágakra. A PHP minimális forrásjavítást adott a 7.4, 8.0 és 8.1 ághoz, a disztribúciók (például az Ubuntu 22.04 a php8.1-re) visszaportolják. Ha bérelt tárhelyen vagy, a szolgáltatótól függ. Középtávon a verzióváltás az egyetlen megoldás, mert ezek az ágak más hibákra sem kapnak már javítást.

Shoprenteren, UNAS-on vagy Wixen van a boltom. Kell tennem valamit?

Nem, ezeknél a szolgáltató üzemelteti a szervert, és ő frissít. Egy visszaigazolást kérj az ügyfélszolgálattól.

Cloudflare van az oldalam előtt. Akkor védett vagyok?

Részben. A Cloudflare tűzfalszabályai a felismert mintákat szűrik, és ez időt ad, de a Cloudflare maga is azt írja, hogy frissíteni kell. A támadók már a kiadás napján módosított terhelésekkel próbálkoztak.

Honnan tudom, hogy már feltörték az oldalam?

Biztos jelet ma még egyik forrás sem publikált. Gyanús: ismeretlen PHP-fájlok a webgyökérben vagy a feltöltési mappákban, módosított index.php vagy .htaccess, új adminfelhasználó, új ütemezett feladat, a naplóban szokatlan, nagy méretű multipart/form-data POST-kérések. Ha bármelyik igaz, a frissítés mellett jelszócsere és a fájlok összevetése egy korábbi mentéssel a következő lépés.

Mennyi ideig áll az oldal a frissítés alatt?

Apache mod_php-nál egy újraindítás, jellemzően 1–3 másodperc. PHP-FPM-nél a workerek újraindítása, hasonló nagyságrend. A PHP-sessionök fájlalapú tárolásnál megmaradnak.

Kell jelszót cserélnem?

Önmagában a frissítés miatt nem. Ha a fenti gyanús jelek bármelyikét látod, vagy az oldal napokig javítatlanul futott nyilvános támadási kísérletek mellett, akkor igen: admin, adatbázis, FTP/SSH és a szerveren tárolt API-kulcsok.

Források

• PHP: Security Release, 2026. október 21. (a két tanácsadó: GHSA-w8hw-w9fx-j79w, GHSA-6wmf-4rv5-p3rp)
• Ubuntu CVE-2026-109618, CVE-2026-109619, USN-8948-1
• Debian Security Tracker (DSA-6574-1, DLA-4848-1)
• Cloudflare: WAF-védelem a PHP-hibákra
• Sansec: php2shell
• Tenable: php2shell GYIK
• Huntress: Rapid Response
• Patchstack: élő idővonal
• watchTowr: elemzés
• HWSW: magyar hír

Frissítési napló

• 2026. október 21., 23:40 (CEST) – A cikk első változata. A saját szerverünk frissítve 22:07-kor. Hazai tárhelyszolgáltatói visszajelzést még nem publikálunk; ahogy írásos megerősítés érkezik, ide kerül.