# PHP-sebezhetőség azonnali lezárása > Még nyitva a PHP-rés? Távolról frissítünk, újraindítjuk az összes folyamatot, és igazolást adunk. Hívjon minket, vagy írjon nekünk WhatsAppon. Forrás: https://phpsos.de/hu/soforthilfe/php-luecke-sofort-schliessen/ Állapot: 2026. 10. 25. Szolgáltató: PHP SOS, PHP-vészhelyzeti segítség és szerverbiztonság. Azonnali segítség WhatsAppon: https://wa.me/491736494914?text=%C3%9Cdv%C3%B6zl%C3%B6m%2C%20PHP%20SOS%21%20Seg%C3%ADts%C3%A9gre%20van%20sz%C3%BCks%C3%A9g%C3%BCnk%20a%20PHP-szerver%C3%BCnkkel.%20C%C3%A9g%3A%20%E2%80%A6%20Weboldal%3A%20%E2%80%A6 **Röviden:** Aki a PHP2Shell PHP-rést még ma le akarja záratni, négy dologra van szüksége: a megfelelő frissítésre, az összes PHP-folyamat újraindítására, a már bejuttatott kártékony kód ellenőrzésére és egy igazolásra. Érintett? Hívjon minket. Segítünk. Ezt távolról, az első üzenettől átvesszük. > **Azonnal cselekedjen:** > **Most ne töröljön semmit, és ne telepítsen újra semmit.** A javításnál is érvényes: először mentés, aztán módosítás. Ha már bejutott valami, szükségünk van a fájlok és a naplók állapotára. [Vészhelyzet bejelentése](https://phpsos.de/hu/notfall/), és Önnel együtt tisztázzuk a sorrendet. ## Miért nem várhat a rés A két rés, a CVE-2026-109618 és a CVE-2026-109619 magában a PHP-ban van, és bejelentkezés nélkül, távolról teszi lehetővé kártékony kód futtatását. A BSI kihirdette a 3. riasztási szintet (narancs), és azonnali frissítést javasol. Ha ez nem azonnal lehetséges, a webszervereket átmenetileg le kell választani a hálózatról. Médiabeszámolók szerint már a javítások 2026. október 21-i közzététele előtt voltak az első megfigyelt támadási kísérletek. A Cloudflare megfigyelt kísérleteket, és védelmi szabályokat vezetett be, de figyelmeztet, hogy a pusztán a kérésadatok alapján felállított szabályok nem elegendők. Fontos az üzemeltetőknek: egy CMS-frissítés nem zárja le a PHP-rést. Beszámolók szerint a WordPress.org sem tervez ellene frissítést, mert a rés az értelmezőben van. Csak a PHP szintjén zárható le, vagyis azon, amit a szerver ténylegesen végrehajt. ## Mit tegyen azonnal 1. **Ismerje a célverziót.** Javított a PHP 8.5.12, 8.4.27, 8.3.36 és 8.2.35. A PHP 8.2 2026. december 31-én éri el a támogatás végét, ezt számolja bele a tervbe. 2. **Vegye számba az összes rendszert.** A tesztszervereket, a konténer-image-eket és az internetről elérhető régi rendszereket is. 3. **Tisztázza a felelősséget.** Tárhelycsomagoknál és menedzselt szervereknél a szolgáltató telepít. Írásban kérdezze meg a verziót és az újraindítást. 4. **Őrizze meg a naplókat.** 2026. október 20-tól, a szakmai sajtó szerint. 5. **Egyeztessen időablakot.** Az újraindítás rövid időre megszakítja a folyamatban lévő kéréseket. Határozzon meg egy időpontot, amikor valaki döntéseket tud hozni. 6. **Ne várjon, ha nyitva van.** Ha nem lehet azonnal javítani, velünk együtt vizsgálja meg az elszigetelést vagy az átmeneti intézkedéseket. ## Hogyan segít konkrétan a PHP SOS? 1. **Helyzetfelmérés:** Felmérjük a rendszereket, a PHP-verziókat, az üzemmódokat, a tárhelyszolgáltatókat és az elérhetőséget, és meghatározzuk a sorrendet: először a legjobban kitett rendszerek. 2. **Mentés és lezárás:** Mentjük a pillanatnyi állapotot, telepítjük a frissítést, vagy a tárhelyet az igazoltan javított állapotra hozzuk, és újraindítjuk az összes folyamatot. Konténereknél újraépítjük az image-et, és kihelyezzük. 3. **Vizsgálat és tisztítás:** Mivel a javítás nem távolítja el a kártékony kódot, megvizsgáljuk, vannak-e egy korábbi behatolás jelei, és szükség esetén megtisztítunk. 4. **Keményítés és jelentés:** Rendszerenként írásos igazolást és ajánlásokat kap, hogy a következő frissítés gyorsabban menjen. A szolgáltatási kört a [PHP-javítási szolgáltatás](https://phpsos.de/hu/leistungen/php-patch-service/) írja le. ## Frissítés, újraindítás, igazolás: mi számít A leggyakoribb hiba a frissítés újraindítás nélkül. Amíg régi folyamatok futnak a memóriában, a sebezhető kód aktív marad, még ha a fájlok újak is. Az útmutató az [A PHP-FPM és az összes worker újraindítása](https://phpsos.de/hu/php2shell/php-fpm-neustart/) oldalon áll. A második hiba az, ha hiszünk a kijelzésnek: a disztribúciók és a tárhelyszolgáltatók gyakran backportokat szállítanak, és ilyenkor a verziószám ugyanaz marad. Megbízható a csomag changelogja a CVE-számokkal, a Debian-családban az `apt-get changelog ` paranccsal. Ezenkívül a PHP-kézikönyv szerint a biztonsági kiadások óta az új `memory_hard_limit_percent` direktíva érvényes. Ha egy PHP-verzió nem ismeri, érintett. A teszt rövid: ```bash php -r 'var_dump(ini_get("memory_hard_limit_percent"));' ``` Verziónként és üzemmódonként le kell futtatni, mert a parancssor más PHP-verziót használhat, mint a webszerver. Végül rögzítjük az eredményt, hogy megmutathassa a tárhelyszolgáltatójának, a biztosítójának vagy a megrendelőjének. ## Ha a frissítés nem lehetséges azonnal Vannak okok, amiért a frissítés ma nem megy: egy régi alkalmazás, amely újabb PHP-verziókon nem fut, egy tárhelyszolgáltató jóváhagyás nélkül, egy konténer-image egy rögzített pipeline-ban. Ezekre az esetekre a php.net átmeneti intézkedéseket nevez meg, amelyek kifejezetten nem jelentenek teljes védelmet: a `memory_limit=-1` beállítása úgy, hogy az alkalmazások ne írhassák felül, a `post_max_size` korlátozása, a `session.upload_progress.enabled=0`, valamint PHP 8.5-ön a `fatal_error_backtraces=0`, mindegyik újraindítással. Ehhez jönnek a peremen lévő védelmi szabályok, amelyek nem pótolják a frissítést. Egy keringő tanácsot, amely szerint az összes `PHPSESSID`-t tartalmazó kérést blokkolni kell, a szakírók kifejezetten elutasítják. Hogy mely intézkedések illenek az Ön rendszeréhez, és mit törhetnek el, azt előtte megbeszéljük. Többet erről a [Azonnali intézkedések, ha még nem tud javítani](https://phpsos.de/hu/php2shell/sofortmassnahmen-ohne-patch/) oldalon és a [WAF és virtuális javítás](https://phpsos.de/hu/leistungen/waf-virtuelles-patching/) témánál olvashat. A PHP 8.1-re és a régebbiekre külön helyzet érvényes, amelyet a [PHP 8.1 és régebbi: mi érvényes most](https://phpsos.de/hu/php2shell/php-8-1-und-aelter/) oldal ír le. ## Mit érdemes elküldenie nekünk - A szerverek és tárhelyszolgáltatók listája, amennyiben van - A `php -v` kimenete rendszerenként és az üzemmódra vonatkozó megjegyzés - Annak megadása, hogy konténer, Plesk, cPanel vagy menedzselt ajánlat van-e használatban - Kívánt időablak és kapcsolattartó az újraindításokhoz - Megjegyzések a 2026. október 17. óta észlelt feltűnő jelenségekről ## Miért a PHP SOS A munkánk Made in Germany, és a kiberbiztonsági szakemberekből álló partnerhálózatunkkal több mint 25 éve az informatikai biztonságra szakosodtunk. Egy kapcsolattartója van, aki kíséri a frissítést, ellenőrzi az újraindítást, és átadja az igazolást. Távolról dolgozunk, kiszállás nélkül, és minden lépést dokumentálunk. Nem ígérünk csodákat: a javítás lezárja a rést, de nem bizonyítja, hogy korábban nem történt semmi, és ezt így is mondjuk meg Önnek. ## Érintett? Hívjon minket. Segítünk. Ne hagyja tovább nyitva a rést. Hívjon minket, vagy írjon WhatsAppon. Az első üzenettől átvesszük az ügyet, és addig maradunk, amíg az incidens le nem zárul, és dokumentált nem lesz. [Vészhelyzet bejelentése most](https://phpsos.de/hu/notfall/). ## Gyakori kérdések **Lezárhatom magam a PHP-sebezhetőséget, vagy segítségre van szükségem?** A frissítés egy rendszergazdának megoldható, de hibára hajlamos: annak a verziónak kell érvényesnek lennie, amelyik ténylegesen kiszolgál, és az összes folyamatnak újra kell indulnia. Aki több szerverrel, konténer-image-ekkel vagy sajátosságokkal rendelkező tárhelyszolgáltatóval dolgozik, támogatással időt és hibákat spórol. **Újra kell indítani a PHP-t a frissítés után?** Igen. Az új fájlok önmagukban nem elegendők, amíg régi PHP-folyamatok futnak a memóriában. Az összes workert, illetve folyamatot újra kell indítani, mod_php esetén a webszervert. **Mit tegyek, ha még nincs frissítés a PHP-verziómhoz?** A PHP 8.1-hez és a régebbiekhez a PHP-projekt már nem ad hivatalos frissítést. Ilyenkor a szolgáltató igazoltan javított backportja, a migráció egy karbantartott verzióra, vagy átmeneti intézkedések szükségesek, amelyek azonban nem nyújtanak teljes védelmet. **Elég a session.upload_progress.enabled beállítást 0-ra állítani?** Nem. A szakmai beszámolók szerint a beállítás önmagában nem zárja le mindkét rést, a PHP-frissítés kötelező marad. Csak a php.ini-ben, az FPM-poolban vagy a szerverkonfigurációban állítsa be, ne az ini_set()-tel vagy a .user.ini-ben. **Honnan tudom, hogy a rés utána tényleg le van zárva?** A futó rendszeren végzett igazolásból: verzió vagy a csomag changelogja, a memory_hard_limit_percent új direktívára végzett teszt, és annak megerősítése, hogy a frissítés után az összes folyamat újraindult. ## Források - [php.net: biztonsági közlemények](https://www.php.net/) - [PHP 8 ChangeLog](https://www.php.net/ChangeLog-8.php) - [PHP-kézikönyv: alapkonfiguráció (ini.core)](https://www.php.net/manual/en/ini.core.php) - [BSI: Szövetségi Információbiztonsági Hivatal (Németország)](https://www.bsi.bund.de/)