Tudásbázis · Frissítve: 2026. október 25. · WebPot DEV

PHP2Shell: így javítsa a kritikus PHP-hibát tárhelyen és VPS-en

A rövid válasz: 2026. október 21-én a PHP fejlesztői két kritikus hibát javítottak (CVE-2026-109618 és CVE-2026-109619, CVSS 9,2), amelyekkel belépés nélkül, egy ügyesen összerakott kéréssel kódot lehet futtatni szinte bármelyik webes PHP-telepítésen. Egyetlen valódi javítás van: a PHP frissítése a 8.5.12, 8.4.27, 8.3.36 vagy 8.2.35 verzióra (vagy a disztribúció javított csomagjára), utána a PHP-folyamatok újraindítása. Tárhelyen ezt a szolgáltató végzi, Önnek ellenőriznie kell. VPS-en az Ön dolga. A saját szerverünkön a hivatalos kiadás után hét órával már a javított PHP futott.

Mi a PHP2Shell és miért ilyen veszélyes?

A PHP2Shell két, egymással rokon hiba közös neve a PHP értelmezőjében, nem egy bővítményben vagy egy keretrendszerben. Mindkettő ugyanarra a mintára épül: ha egy kérés feldolgozása félúton megszakad (elfogy a memória vagy végzetes hiba lép fel), a PHP egy félkész belső állapotot később érvényesnek tekint. Egy támadó ezt a félkész állapotot a saját adataival tudja feltölteni, a takarítás pedig végül az ő parancsát futtatja le.

• CVE-2026-109618. Ha a PHP az űrlapadatok feldolgozása közben kifut a memóriából, egy bejegyzés számlálója már frissül, maga a bejegyzés viszont nem jön létre. A kérés végi takarítás ezt a szemetet valódi PHP-értékként kezeli.
• CVE-2026-109619. A PHP-folyamat egymás után sok kérést szolgál ki. Egy megszakadt kérés után a folyamatban olyan mutató maradhat, amely már felszabadított memóriára mutat. A következő kérés ezt használja tovább (szakszóval use-after-free). A PHP hivatalos leírása szerint így a memória tartalma is kiolvasható lehet, benne más kérések adataival.

Miért nem véd a WordPress-frissítés vagy a biztonsági bővítmény?

Mert a támadó kérését a PHP még az alkalmazás első kódsora előtt feldolgozza. A hiba a POST-kérés törzsének értelmezésekor jön elő, ezért mindegy, hogy WordPress, Magento, Drupal vagy egy saját fejlesztésű rendszer fut a szerveren: bármelyik PHP-fájl elérhetősége elég, akár egy egyszerű kapcsolatfelvételi oldalé is. A belépési védelem, a captcha és a biztonsági bővítmény ilyenkor még el sem indult.

Kit érint: verziók és futtatási módok

Minden olyan PHP-telepítést, amely webes kéréseket szolgál ki: PHP-FPM, Apache mod_php, php-cgi, FrankenPHP és LiteSpeed. A PHP csapata szerint a legnagyobb kockázatot a mod_php jelenti. A parancssori PHP (CLI, cron) kívülről nem támadható ezen az úton, de ugyanabból a csomagból frissül.

A Linux-disztribúciók (Ubuntu, Debian, Red Hat) és a CloudLinux a javítást gyakran a verziószám változtatása nélkül, visszaportolva adják ki. Ilyenkor egy régebbinek látszó verziószám is lehet már javított, ezért a csomag változásnaplója a mérvadó.

Mi történt október 17. és 23. között?

A harmadik hiba: CVE-2026-115560

Ez a hiba akkor használható ki, ha az alkalmazás a session.serialize_handler értékét a konfigurációban php_binary vagy php_serialize értékre állítja, futás közben ini_set()-tel php-re váltja, miközben a feltöltésjelző (session upload progress) be van kapcsolva. A PHP szerint ez valószínűtlen helyzet. A javítás a következő rendes kiadásban érkezik, addig a PHP azt javasolja, hogy a session.upload_progress.enabled legyen kikapcsolva. A legtöbb oldal ezt a funkciót nem használja, a kikapcsolás tehát semmit nem ront el.

Kiket érintett a támadás és hogyan?

A PHP2Shell legnagyobb, mindenki által látható kárát nem a feltörések okozták, hanem az óvatosságból elrendelt leállások. A nyilvános források szerint október 25-ig egyetlen nagy szervezet sem jelentett be igazolt behatolást. A kormányok és a nagy szolgáltatók egy része viszont inkább lekapcsolta a PHP-s oldalait, amíg a javítás meg nem jelent és fel nem került.

A kitettség becslései nagyon eltérnek: a Palo Alto Networks 22,6 millió potenciálisan sebezhető példányt mért, egy független kutató 1,3 millió, egy Shodan-alapú számolás 1,9 millió internetről elérhető PHP-s gépet. A különbség a mérési módszerből adódik. A W3Techs szerint az ismert szerveroldali nyelvű weboldalak 69 százaléka PHP-n fut.

Hogyan próbálták kihasználni?

• Csapdahálózatok és pásztázás. Az Amazon már október 17-én, a watchTowr és más biztonsági cégek október 21-től rögzítettek kísérleteket a csapdagépeiken (honeypot). A Cloudflare október 21-én reggel korai támadásokat jelzett, még a javítás megjelenése előtt.
• Tárhelyszolgáltatók. A Patchstack október 21-én reggel arról számolt be, hogy a tárhelypartnerei több aktív kihasználási esetet láttak. A szolgáltatókat nem nevezte meg.
• Kiszivárgott és hamis támadókódok. A hibák leírása már a javítás előtt felkerült a VirusTotalra. A PHP biztonsági csapata az utána terjedő bemutató kódok (PoC) között a kiadás idején működőt nem talált. A biztonsági cégek szerint ezek egy része maga is kártevőt rejthet.
• Miért nem lett belőle (eddig) tömeges feltörés? A Sansec szerint nincs olyan egyetlen kérés, amely minden szerveren működne, mint a Log4Shellnél: a támadónak ismernie kell a célszerver beállításait. A nyilvános kódok többsége alapértelmezett PHP-n nem működik, sokuk egy külön fájlbeillesztési (LFI) hibát is igényel. A Rapid7 szerint minden bemutatott támadás csak egy adott operációs rendszer, PHP-verzió és webszerver párosításon működött. A VulnCheck viszont szabványos, éles PHP 8.4-es beállításon is működő támadást épített, igaz, csak az ügyfeleinek adta ki. A javítatlan szerver tehát egy felkészült támadó ellen továbbra is védtelen.

Mit veszít, akit eltalálnak?

• Kódfuttatás a webszerver nevében. A támadó webshellt vagy kártevőt telepíthet, hozzáférhet a fájlokhoz és az adatbázishoz, onnan pedig továbbléphet más rendszerekre.
• Kiszivárgó titkok. A hibák memóriakiolvasási útján a Sansec szerint jelszavak, munkamenet-azonosítók, API-kulcsok és akár a TLS privát kulcs is kikerülhet, akkor is, ha az alkalmazás nem használ munkamenetet. Ha egy szerver napokig javítatlanul volt elérhető, a kulcsok és a jelszavak cseréje is indokolt lehet.
• Kiesés. A lekapcsolás maga is kár: Magyarországon és Hollandiában az online ügyintézés is szünetelt. Ezért számít, hogy egy szerver órák alatt frissíthető legyen, ne napok alatt.

Javítás osztott tárhelyen

Osztott tárhelyen a PHP-t a szolgáltató telepíti és frissíti, Ön nem fér hozzá a szerverhez. A dolga ezért az ellenőrzés: tudnia kell, hogy a javítás valóban felkerült.

1. Nézze meg a PHP-verziót. cPanelen a „PHP verzió kiválasztása” vagy a MultiPHP Manager, Pleskben a domain „PHP beállítások” oldala mutatja. WordPressben: Eszközök › Webhely egészsége › Információ › Szerver.
2. Ne csak a számot nézze. Ha 8.5.12, 8.4.27, 8.3.36, 8.2.35 vagy újabb, rendben van. Ha alacsonyabb, még lehet javított (a szolgáltató visszaportolhatta a javítást), de ezt csak ő tudja megerősíteni.
3. Kérjen írásos választ. Az alábbi levelet egy az egyben elküldheti az ügyfélszolgálatnak.
4. PHP 8.1 vagy régebbi esetén váltson. Készítsen mentést, ha lehet, próbálja ki tesztoldalon, majd a panelen állítsa 8.3-ra vagy 8.4-re. A régi sablonok és bővítmények új PHP-n hibázhatnak, ezért utána nézze végig a fontos oldalakat, webáruháznál a pénztárat is.
5. Ha az oldal Cloudflare mögött van, a Cloudflare a PHP2Shell elleni szabályait az ingyenes csomagban is élesítette. Pro vagy magasabb csomagnál a felügyelt szabályok blokkoljanak, ne csak naplózzanak. Ez kiegészítő réteg, nem javítás: a szerver közvetlen IP-címén át a szűrő megkerülhető.

Ami tárhelyen nem segít: a WordPress, a sablon vagy a bővítmények frissítése (jó dolog, de ezt a hibát nem javítja), egy biztonsági bővítmény telepítése, illetve a session.upload_progress.enabled kikapcsolása .user.ini fájlban vagy ini_set()-tel. A PHP leírása szerint ezek a beállítások túl későn hatnak, a támadó kérése addigra feldolgozódik.

Javítás VPS-en és konténerben

Saját szerveren a teljes lánc az Öné: a csomag frissítése, a futó folyamatok cseréje és az ellenőrzés. Az újraindítás kimaradása a leggyakoribb hiba: a lemezen már a javított PHP van, a memóriában viszont még a régi fut.

Ubuntu és Debian

Először derítse ki, melyik PHP szolgálja ki a webet. A php -v csak a parancssori változatot mutatja, a weboldalak gyakran egy másik ágon futnak.

# Mely PHP-FPM ágak futnak? (a socket nevéből látszik)
ls /run/php/
php-fpm8.3 -v

# Frissítés (az ondrej/sury tárolóból és az Ubuntu vagy Debian biztonsági tárolójából egyaránt)
sudo apt update
apt list --upgradable 2>/dev/null | grep php
sudo apt upgrade

# Újraindítás: minden futó PHP-ág és az Apache (ha mod_php-t használ)
sudo systemctl restart php8.3-fpm
sudo systemctl restart apache2

# Ellenőrzés: a verzió és az indulás ideje (a frissítés utáni legyen)
php-fpm8.3 -v
systemctl show -p ActiveEnterTimestamp php8.3-fpm

Ha a disztribúció saját PHP-csomagját használja (például Ubuntu 24.04 alapból 8.3-at hoz), a verziószám nem ugrik 8.3.36-ra, a javítás visszaportolva érkezik. Ilyenkor a csomag változásnaplójában keresse a CVE-számot:

zgrep -c "CVE-2026-109618" /usr/share/doc/php8.3-common/changelog.Debian.gz

Ha az eredmény 0, a javítás még nincs fent: nézze meg, engedélyezve van-e a biztonsági tároló, vagy várja meg a disztribúció közleményét.

AlmaLinux, Rocky Linux, RHEL

sudo dnf upgrade 'php*'
sudo systemctl restart php-fpm httpd
php-fpm -v

Remi tárolónál a php83-php-fpm jellegű csomag- és szolgáltatásnevekkel ugyanez a menet.

Docker és konténerek

A konténerben futó PHP nem frissül a gazdagéppel együtt. A képet friss alapképből kell újraépíteni, a régi konténereket pedig lecserélni. Ha a Dockerfile pontos verziót rögzít (például php:8.3.35-fpm), azt is írja át.

docker compose build --pull
docker compose up -d
docker compose exec app php -v   # az „app” helyére a saját szolgáltatása neve kerül

Ha ma nem tud frissíteni: ideiglenes enyhítés

A PHP csapata néhány beállítást javasol arra az időre, amíg a frissítés nem fér bele. Ezek csökkentik a kockázatot, de nem szüntetik meg. A php.ini-be vagy a PHP-FPM pool fájljába kerülnek, utána minden PHP-folyamatot újra kell indítani.

; php.ini (a .user.ini és az ini_set() itt nem hat)
session.upload_progress.enabled = 0
fatal_error_backtraces = 0        ; csak PHP 8.5
post_max_size = 8M                ; 32M, ha az oldalon van fájlfeltöltés
upload_max_filesize = 6M          ; mindig kisebb, mint a post_max_size

; PHP-FPM pool, például /etc/php/8.3/fpm/pool.d/www.conf
php_admin_value[memory_limit] = -1

A memory_limit = -1 a CVE-2026-109618 kiváltó okát (a memóriakorlát elérését) zárja ki, cserébe egyetlen kérés is elviheti a szerver teljes memóriáját. Csak akkor alkalmazza, ha a PHP-folyamatok memóriáját más is korlátozza (konténer- vagy cgroup-limit) és a webszerver is szűri a kérések méretét (nginxben client_max_body_size). A CERT-EU azt javasolja, hogy ami nem frissíthető, azt átmenetileg vegye le a nyilvános internetről, a CISA pedig a PHP 8.1-es és régebbi rendszereket kapcsoltatná le a javításig.

Feltörték? Így ellenőrizze

A frissítés a jövőbeli támadást zárja ki, a múltbelit nem. Mivel az első kísérlet október 17-én történt, a naplókat ettől a naptól érdemes átnézni. A jelek külön-külön lehetnek ártalmatlanok is, együtt viszont gyanúsak.

• Memóriahiba a kérés indulásakor: „Allowed memory size … exhausted” hibaüzenet, amely a kód helyett „Unknown on line 0”-t ír, főleg sorozatban, egy folyamaton.
• Összeomló PHP-folyamatok: SIGSEGV (signal 11) a PHP-FPM naplójában.
• Szokatlan kérések: nagy, darabolt POST-kérések, sok vagy mélyen egymásba ágyazott űrlapmezővel, hosszú vagy bináris PHPSESSID süti.
• Shell a webszerver nevében: ha a www-data felhasználó sh, bash, curl vagy wget parancsot futtat, az a legerősebb jel.
• Új PHP-fájlok a feltöltési és gyorsítótár-mappákban, ahol PHP-nak nem volna szabad lennie.

# Memóriahiba a kérés indulásakor
sudo zgrep -h "Allowed memory size" /var/log/php*-fpm.log* /var/log/nginx/error.log* | grep -c "Unknown on line 0"

# Összeomló PHP-folyamatok
sudo zgrep -h "SIGSEGV" /var/log/php*-fpm.log*

# A webszerver felhasználója shellt vagy letöltőt futtat?
ps -u www-data -o pid,lstart,cmd | grep -E "sh -c|bash|curl|wget"

# Október 17. óta létrehozott PHP-fájlok a feltöltési mappákban
sudo find /var/www -path "*upload*" -name "*.php" -newermt 2026-10-17

Ha bármelyikre gyanús találat van, ne takarítson azonnal, mert a nyomokkal a bizonyítékot is eltünteti. Mentse le a naplókat, cserélje le az összes jelszót és kulcsot (adatbázis, levelezés, fizetési és API-kulcsok), az oldalt pedig egy október 17. előtti, tiszta mentésből állítsa helyre. Ehhez érdemes szakembert hívni.

Hogyan vészeltük át mi?

A saját és ügyfeleink WebPotCMS oldalai egy általunk üzemeltetett Ubuntu LTS szerveren futnak: a tesztkörnyezetekkel és az adminfelületekkel együtt harmincegy nginx-webhely, előttük Cloudflare, mögöttük PHP-FPM 8.5 és 8.3. Az alábbi időpontok nem becslések, hanem a szerver csomagkezelő- és szolgáltatásnaplójából valók.

Miért nem kellett pánikba esni?

A gyors frissítés volt a döntő lépés, de nem ez volt az egyetlen. A szerveren a frissítés előtt is több réteg állt a PHP előtt. Ezek pont egy ilyen, belépés előtt kihasználható hibánál érik meg az árukat.

• nginx basic auth az adminfelületeken. Az adminisztrációs eszközöket és a tesztoldalakat jelszó védi, amelyet az nginx kér el, még mielőtt a kérés a PHP-hoz jutna. Jelszó nélkül a támadó POST-kérése el sem éri a hibás kódrészt. A legkockázatosabb futtatási mód, az Apache mod_php nálunk csak ilyen belső eszközök mögött fut, a portját a tűzfal kívülről nem engedi.
• Minden PHP előtt nginx áll. A PHP-folyamatok kívülről közvetlenül nem érhetők el, a kérések méretét az nginx korlátozza, mielőtt a PHP egyáltalán látná őket.
• Cloudflare a nyilvános oldalak előtt. Október 21-én a Cloudflare élesítette a PHP2Shell-szabályait, így a nyilvános oldalaink forgalma ezen a szűrőn is átment. Erre nem építettünk, mert szűrő, nem javítás.
• fail2ban hét figyelővel. SSH, levelezés és két nginx-figyelő fut: az egyik a sebezhetőséget kereső robotokat, a másik a basic auth jelszópróbálgatóit tiltja ki, egyszerre a szerver tűzfalán és a Cloudflare-en. A tiltás egy napig tart, ismétlésnél egyre tovább, legfeljebb egy hétig. Egyetlen, jól célzott kérést a fail2ban nem állít meg, de a tömeges pásztázás zaját jelentősen csökkenti: október 22. óta csak az SSH-figyelő közel hatszáz címet tiltott ki.

Amit ebből megtanultunk

1. A gyors kézi frissítés nem terv. Aznap este ráértünk, máskor talán nem. Ezért került a PHP tárolója az automatikus frissítések közé.
2. A frissítés csak az újraindítással együtt ér valamit. Azt, hogy a szolgáltatások valóban újraindultak, nem feltételeztük, hanem a csomagnapló és az indulási idő összevetésével ellenőriztük.
3. A nem használt szoftver is kockázat. Minden régi PHP-ág, felejtett adminfelület és tesztoldal egy újabb hely, amit frissíteni kell.
4. A jelszavas előszűrés olcsó és működik. Ami nem a nyilvánosságnak szól, az ne is legyen nyilvános: egy basic auth sor az nginxben egy belépés előtti hibát is kivéd.

Megelőzés a következő hibára

A PHP2Shell nem az utolsó ilyen hiba lesz. A kutatók szerint ez egy hibaminta, nem egyetlen elírás. Az ilyen hibákat ráadásul egyre több csapat keresi mesterséges intelligenciával. A cél tehát nem az, hogy a következőt kitaláljuk, hanem hogy amikor jön, órák alatt lezárható legyen.

Automatikus biztonsági frissítés, a PHP tárolójával együtt

Ubuntun az unattended-upgrades alapból csak a disztribúció biztonsági tárolóját frissíti. Ha a PHP egy külön tárolóból jön (például ondrej/php), azt külön fel kell venni, különben a PHP kimarad.

// /etc/apt/apt.conf.d/50unattended-upgrades
Unattended-Upgrade::Allowed-Origins {
    "${distro_id}:${distro_codename}-security";
    "LP-PPA-ondrej-php:${distro_codename}";
};

Mellé érdemes a needrestart csomagot is telepíteni: frissítés után kijelzi, illetve beállítástól függően újra is indítja azokat a szolgáltatásokat, amelyek még a régi könyvtárakat használják.

Ami nem nyilvános, kerüljön jelszó vagy IP-szűrés mögé

Adatbázis-kezelő, levelezési admin, tesztoldal, fejlesztői másolat: ezek egyike sem a látogatóknak szól. Az nginx basic auth a server blokk szintjén minden útvonalat véd, a PHP-hoz vezetőt is.

# jelszófájl létrehozása (apache2-utils csomag)
sudo htpasswd -c /etc/nginx/.htpasswd admin
sudo chown root:www-data /etc/nginx/.htpasswd
sudo chmod 640 /etc/nginx/.htpasswd

# /etc/nginx/sites-available/admin.example.hu.conf
server {
    server_name admin.example.hu;
    auth_basic           "Belépés szükséges";
    auth_basic_user_file /etc/nginx/.htpasswd;
    # IP-szűrés helyette vagy mellette:
    # allow 203.0.113.10;
    # deny  all;
    ...
}

Cloudflare mögött az IP-szűréshez az nginxnek a látogató valódi címét kell látnia (real_ip_header CF-Connecting-IP), különben a Cloudflare címeit szűri. Kényelmesebb, naplózott alternatíva a Cloudflare Access vagy a VPN.

fail2ban az nginxre is, ne csak az SSH-ra

A legtöbb telepítésen a fail2ban csak az SSH-t figyeli. Két nginx-figyelő bekapcsolása néhány sor. Ezek a basic auth próbálgatóit és a sebezhetőséget kereső robotokat is kitiltják.

# /etc/fail2ban/jail.local
[DEFAULT]
bantime           = 1d
bantime.increment = true
bantime.maxtime   = 1w

[nginx-http-auth]
enabled = true

[nginx-botsearch]
enabled = true

Cloudflare mögött a tűzfalon tiltott IP-cím nem ér semmit, mert a kérés a Cloudflare címéről érkezik. Ilyenkor a fail2ban a Cloudflare API-n át is tud tiltani (a gyári cloudflare action), mi mindkét helyen tiltunk.

A többi réteg röviden

• Támogatott PHP-ág. A 8.2 2026. december 31-én kifut. Aki most frissít, rögtön a 8.4-re vagy a 8.5-re lépjen, így a következő hibánál nem a verzióváltással kell küzdenie.
• Kérésméret és memória korlátja. Az nginxben webhelyenként annyi client_max_body_size, amennyi kell, a PHP-folyamatok memóriája pedig legyen felülről korlátozva (FPM pool, konténer, cgroup).
• Elszigetelés. Webhelyenként külön PHP-FPM pool és rendszerfelhasználó, open_basedir beállítással. Ha egy oldal el is esik, ne vigye magával a többit.
• Riasztás. Értesítés, ha a PHP-FPM naplójában összeomlás jelenik meg, vagy ha a webszerver felhasználója shellt indít.
• Külső mentés, kipróbált visszaállítással. Egy feltörés után ez dönti el, hogy órák vagy napok alatt áll helyre az oldal.

Ha nincs saját rendszergazdája, ezeket a lépéseket a VPS-üzemeltetés keretében mi is elvégezzük, WordPress oldalaknál pedig a WordPress-karbantartás része.

Gyakori kérdések a PHP2Shell hibáról

Kapcsolódó oldalakUbuntu VPS szerver üzemeltetés, VPS szerver: mire jó és mikor éri meg?, WordPress karbantartás árak.

Források (lekérve: 2026. október 25.)PHP: hivatalos biztonsági közlemények (október 20., 21. és 23.) · Datadog Security Labs: a hiba elemzése és felismerése · Tenable: GYIK és idővonal · Palo Alto Unit 42: fenyegetettségi összefoglaló · Recorded Future: a kihasználás idővonala · Sansec: webáruházak és a tömeges kihasználás esélye · Origo: leállt a magyarorszag.hu · NOS: holland kormányzati oldalak offline · Helsinki Times: finn kormányzati leállás

KépekA borítóképen a PHP hivatalos logója látszik, változtatás nélkül: Colin Viebrock, CC BY-SA 4.0, forrás: php.net. A cikk nem a PHP csapatának hivatalos közleménye. Az ábrák a WebPot DEV saját készítésűek.