Attól, hogy a tárhelykezelő felületen PHP 8.3 látható, a webhely még nem feltétlenül védett: a két kritikus sebezhetőség javítása csak a 8.3.36-os verzióban érhető el. A PHP fejlesztőcsapata sürgősségi frissítéseket adott ki, miután több európai kormányzati webhelyet elővigyázatosságból leállítottak – írja a Reuters.
Franciaországi, hollandiai, finnországi és dániai közszolgáltatások is érintettek voltak, egyes intézmények pedig inkább levették oldalukat az internetről a javítások telepítéséig. A reakció túlzónak tűnhet, ám a két hiba lehetővé teszi a távoli, hitelesítés nélküli kódfuttatást. A támadónak nincs szüksége fiókra, jelszóra vagy korábbi szerverhozzáférésre.
Melyik PHP-verzió szükséges?
Nem elég, ha a kezelőfelületen PHP 8.2, 8.3, 8.4 vagy 8.5 szerepel. Az utolsó számjegy is számít:
| PHP-ág | Sérülékeny verziók | Első javított verzió |
|---|---|---|
| PHP 8.5 | 8.5.12 alatt | 8.5.12 |
| PHP 8.4 | 8.4.27 alatt | 8.4.27 |
| PHP 8.3 | 8.3.36 alatt | 8.3.36 |
| PHP 8.2 | 8.2.35 alatt | 8.2.35 |
| PHP 8.1 vagy régebbi | támogatásból kikerült ágak | frissítés vagy a szolgáltató által igazolt javítás |
A PHP 8.2 csak 2026. december 31-ig kap hivatalos javításokat. A PHP 8.1-hez, 8.0-hoz és 7.4-hez minimális javítások készültek, elsősorban azok számára, akik forrásból fordítják a PHP-t, de az ajánlott megoldás továbbra is egy támogatott ágra való átállás. Egyes Linux-disztribúciók és LTS-szolgáltatások backporttal is beépíthetik a javítást, ezért a kijelzett verziószám eltérhet a PHP.net-en közzétettől. A szolgáltatónak kifejezetten meg kell erősítenie, hogy javította a következőket: CVE-2026-109618 és CVE-2026-109619.
Hogyan kompromittálhatók a webhelyek?
Az első sebezhetőség azt használja ki, ahogyan a PHP egy kérés feldolgozása közben kezeli a memóriahiányt, beleértve a feltöltéseket érintő eseteket is. A második miatt korábbi belső adatok válhatnak elérhetővé egy későbbi kérés számára. Mindkettő 10-ből 9,2 pontos értékelést kapott, és szerveroldali parancsvégrehajtáshoz vezethet.
Azok a telepítések érintettek, amelyek az alábbiakon keresztül szolgálnak ki weboldalakat:
- PHP-FPM;
- Apache a következővel:
mod_php; php-cgi;- FrankenPHP;
- LiteSpeed.
A konfigurációk mod_php tekinthetők a legkockázatosabbnak. A PHP figyelmeztetése szerint a bemutatott támadás még azelőtt kiváltható, hogy maga az alkalmazás futni kezdene. Ez azt jelenti, hogy egy WordPress-biztonsági bővítmény vagy az alkalmazásba telepített tűzfal akár be sem tud avatkozni.
Teendők WordPress-webhely esetén
A WordPress, a sablon és a bővítmények frissítése nem javítja a PHP-t, mert a nyelv szerveroldalon fut. WordPress-webhelyen az aktív verzió itt ellenőrizhető:
Eszközök → Webhely állapota → Információk → Szerver → PHP-verzió
WordPress-dokumentáció megerősíti, hogy itt a webhely által ténylegesen használt konfiguráció látható. Ne kizárólag a tárhelykezelőben kiválasztott verzióra hagyatkozzon: a szerveren több PHP-verzió is telepítve lehet, miközben a webhely még egy régebbi PHP-FPM poolon fut.
Megosztott vagy menedzselt tárhely esetén:
- Ellenőrizze a webhely által ténylegesen használt verziót, ne csak a kezelőfelületen elérhető változatot.
- Kérdezzen rá a szolgáltatónál, hogy telepítették-e a két CVE javítását.
- Erősítse meg, hogy szükséges-e az új verzió kézi kiválasztása.
- A módosítás előtt készítsen teljes biztonsági mentést.
- Frissítés után tesztelje az űrlapokat, feltöltéseket, rendeléseket és az adminisztrációs felületet.
VPS vagy dedikált szerver üzemeltetésekor frissíteni kell a használt disztribúció PHP-csomagjait, majd újra kell indítani a PHP-FPM-, Apache- vagy LiteSpeed-szolgáltatásokat. A parancs php -v a terminálban ellenőrzi a verziót, de ez eltérhet a webhely által használt változattól; az ellenőrzést a webes alkalmazáson keresztül is meg kell ismételni.
A WAF és a biztonsági mentés nem helyettesíti a frissítést
A PHP egyértelműen kimondja, hogy a frissítésen kívül nincs teljes körű védelmi módszer. A feltöltések korlátozása, bizonyos funkciók letiltása session.upload_progress és a nagy méretű kérések szűrése csökkentheti egyes támadási lehetőségeket, de nem teszi biztonságossá a szervert. Ezeket a változtatásokat csak a szerver rendszergazdája végezze el, mert befolyásolhatják a webhely működését.
Ha a frissítés nem végezhető el azonnal, a CERT-EU azt javasolja, hogy az alkalmazást válasszák le az internetről, vagy ideiglenesen állítsák le. A javítás telepítése után ellenőrizni kell a naplókat, a nemrég módosított fájlokat, az újonnan létrehozott rendszergazdai fiókokat és az ismeretlen folyamatokat. Kompromittálódásra utaló jelek esetén az egyszerű frissítés nem távolítja el a már telepített rosszindulatú kódot.
Az MI megtalálta a hibákat, de a támadásokat is felgyorsíthatja
Az első problémát Calif és az OpenAI közös kutatása nyomán jelentették, amelyhez a GPT-5.6 Solt használták. A Wiz egymástól függetlenül saját Atlas rendszerével és más MI-modellekkel azonosította a sebezhetőségeket. A hibás kód évek óta létezett, de a teljes kihasználási lánc bizonyítása manuális kutatással nehéz volt.
A javítások közzététele után ugyanez az automatizálás használható a kód összehasonlítására és egy exploit gyors elkészítésére. Ez a következő lépés azok után az esetek után, amikor azt láttuk, hogy MI-ügynökök rejtett kriptobányászokat találnak és kihasználják a nem frissített szervereket: a javítás nyilvánosságra hozatala és a támadások kezdete közötti időablak egyre rövidebb.
A tárhelyszolgáltatónak nem azt kell kérdezni, hogy „PHP 8.3-at használok-e?”, hanem ezt: „A webhely PHP 8.3.36-ot vagy olyan csomagot futtat, amelyben javították a CVE-2026-109618 és CVE-2026-109619 hibát?” Ha a szolgáltató ezt nem tudja megerősíteni, a szervert továbbra is sérülékenynek kell tekinteni.
