Kritikus PHP-biztonsági frissítés: két infrastruktúra, egy fontos tanulság

A helyzet

Vannak napok, amikor egy új funkciót vagy egy látványos megjelenést ünneplünk. A mai munka ezzel szemben akkor sikeres, ha a látogató szinte semmit nem vesz észre. 2026. október 21-én a PHP fejlesztői két kritikus sebezhetőséget hoztak nyilvánosságra. A hibák nem egyetlen weboldal vagy WordPress-bővítmény kódjában voltak, hanem magában a PHP futtatókörnyezetben. Mivel a Columbia Games kereskedelmi rendszere és a KampányMűveköt is kiszolgáló szerverkörnyezet több ponton PHP-t használ, október 22-én célzott biztonsági karbantartást és auditot végeztünk. A cél a javított verziók tényleges ellenőrzése, a szükséges komponensek frissítése, a szolgáltatások működésének megőrzése és a kockázatok megértése volt – nem egy mindenre kiterjedő, kapkodó rendszerátépítés.

A megoldási út

Először szétválasztottuk az érintett technológiai rétegeket: a Columbia Games új CCM v2 API-ját, a régi WordPress Docker-konténerét és a külön Ubuntu 24.04 LTS webkiszolgálót. A hivatalos PHP és Canonical közleményeket a ténylegesen futó verziókkal vetettük össze. Ahol upstream PHP-cserére volt szükség, ott kontrollált konténerfrissítést alkalmaztunk; ahol az Ubuntu backportja már települt, ott ezt a csomag- és telepítési naplókkal igazoltuk. A kiadásokhoz mentési és visszaállítási tervet rendeltünk, majd konfigurációellenőrzésekkel, HTTP-smoke tesztekkel, alkalmazás-health checkkel és naplóvizsgálattal győződtünk meg a működésről. A hivatalos sérülékenységi és disztribúciós hivatkozásokat a bejegyzés végén közvetlenül is megnyithatóvá tettük.

1. Két CVE, amit nem lehetett figyelmen kívül hagyni

A CVE-2026-109618 egy memóriahiányos helyzetben hibásan kezelt belső állapothoz, a CVE-2026-109619 pedig a kérések között megmaradó, már felszabadított memóriára mutató hivatkozásokhoz kapcsolódik. A két probléma 9,2-es CVSS v4.0 besorolást kapott: kritikus súlyosságú sebezhetőségekről beszélünk. Bizonyos érintett konfigurációkban ezek távoli kódfuttatást (RCE) tehetnek lehetővé előzetes bejelentkezés nélkül. Ez nem azt jelenti, hogy minden PHP-oldal automatikusan kompromittálható, hanem azt, hogy a kihasználási feltételek teljesülése esetén a kár súlyos lehet. A hivatalos figyelmeztetés külön kiemeli az Apache mod_php használatát: bizonyos esetekben a támadás még az alkalmazás saját PHP-kódjának futása előtt megtörténhet. A jól megírt üzleti logika tehát önmagában nem javítja ki az alatta dolgozó futtatókörnyezet hibáját.

2. Miért fontos ez egy átlagos látogatónak?

A weboldal mögötti szoftverek általában láthatatlanok. A látogató megnyitja a katalógust, kiválaszt egy terméket, bejelentkezik, vagy elküld egy űrlapot. Közben az alkalmazás szerveroldali kódot futtat, adatbázist kérdez, és kezeli az adatokat. Ha maga a futtatókörnyezet sérülékeny, az érintett beállításoktól és a folyamat jogosultságaitól függően veszélybe kerülhet az adatvédelem, a rendelkezésre állás vagy az alkalmazás sértetlensége. A biztonsági frissítés nem új gombot és nem gyorsabb animációt ad, hanem megszüntet egy ismert támadási lehetőséget. Ez az a fajta munka, amelynek legjobb jele sokszor éppen a változatlanul működő weboldal. A látogatónak nem kell máshogyan használnia a szolgáltatást, az üzemeltetőnek viszont sokkal több dolgot kell ellenőriznie.

3. Columbia Games: a CCM v2 API frissítése

A Columbia Games új CCM v2 rendszere termékkatalógust, ügyfélfolyamatokat, letölthető termékeket, kereskedői szabályokat és rendeléseket szolgál ki. A PHP-alapú API-nál nem engedhetjük meg, hogy egy biztonsági karbantartás kontrollálatlan üzleti változássá váljon. Ezért célzottan a futtatókörnyezetet frissítettük a javított PHP 8.3.36 verzióra. A production kiadás után ellenőriztük a szolgáltatás egészségi állapotát és a kapcsolódó adatbázisok elérhetőségét. A /api/health végpont sikeres választ adott, és az ellenőrzött három adatbázis-kapcsolat működött. Fontos, hogy ez nem helyettesíti az összes üzleti funkció kézi tesztelését; azt mutatja, hogy a kritikus alapútvonalak a frissítés után rendelkezésre álltak. A változtatás célja kizárólag az ismert PHP-kockázat mérséklése volt.

4. Columbia Games WordPress: külön konténer, külön ellenőrzés

A hagyományos WordPress-weboldal saját Apache/PHP Docker-környezetben futott, ahol korábban PHP 8.4.21 volt telepítve. Mivel éppen az Apache mod_php az egyik kiemelten érintett konfiguráció, ezt a környezetet külön kezeltük. Mentést készítettünk a WordPress adatbázisáról és feltöltött fájljairól, ellenőriztük a mentési állományokat, és előkészítettük a visszaállítás lehetőségét. Ezután a WordPress-konténert a javított PHP 8.4.27 verzióval építettük és indítottuk újra, a MariaDB-t változatlanul hagyva. Frissítés után az apache2ctl konfigurációtesztje sikeres volt, a tényleges php -v már 8.4.27-et jelzett, a vizsgált friss logokban nem volt PHP fatal error, és a belső valamint nyilvános HTTP-ellenőrzések megfelelő választ adtak. Egy biztonsági frissítés akkor tekinthető érdemben előrehaladottnak, ha nemcsak a verziószámot, hanem a szolgáltatást is ellenőriztük.

5. KampányMűvek: a backport nem elavult javítás

A KampányMűvek szolgáltatásait is kiszolgáló Ubuntu 24.04.5 LTS szerveren más volt a helyzet. A Canonical már kiadta a javítást tartalmazó PHP-csomagot: 8.3.6-0ubuntu0.24.04.13. Ez elsőre régebbinek tűnhet a PHP 8.3.36-nál, de a disztribúciók gyakran az eredeti támogatott csomagba emelik át a biztonsági javításokat, vagyis backportolnak. A csomag teljes, disztribúcióspecifikus verziószáma és a Canonical USN-8948-1 közleménye számít, nem csak az upstream verziórész. A szerver naplói szerint ezt a biztonsági csomagot az automatikus mechanizmus október 20-án telepítette. Október 22-én tehát nem állítottuk úgy be, mintha ekkor érkezett volna meg először a javítás: a már fenn lévő csomag megfelelőségét ellenőriztük, és további célzott üzemeltetési feladatokat végeztünk.

6. A felesleges PHP-kiszolgálás letiltása

A biztonság nem csak a legújabb csomagok telepítéséből áll. Azt is érdemes átgondolni, mire van valóban szüksége egy weboldalnak. A szerver vizsgálatakor 1067 állományt néztünk át, és az ellenőrzött webes fájlok között nem találtunk PHP-forráskódot. Az adott weboldalak kiszolgálásához ezért nem volt indokolt az Apache általános PHP-végrehajtási lehetőségét fenntartani. Megszüntettük a globális Apache–PHP-FPM kezelőkapcsolatot, és külön korlátoztuk a PHP-forrásállományok közvetlen webes elérését. Ezzel nem állítjuk, hogy minden jövőbeli támadás lehetőségét kizártuk, de kevesebb feleslegesen engedélyezett funkció maradt. A támadási felület csökkentése egyszerű elv: amit nem kell elérhetővé tenni, azt ne tegyük elérhetővé.

7. Rendszercsomagok, kompatibilitás, tudatos hatókör

A PHP-audit mellett további 14 APT-csomagot is frissítettünk a kiszolgálón. A csomagkezelő által tervezett műveleteket előre megvizsgáltuk, a karbantartás nem igényelt csomageltávolítást vagy teljes szerver-újraindítást. Az Ubuntu 24.04.5 LTS verziót szándékosan megtartottuk: egy kritikus sérülékenység célzott javítását nem szabad összekeverni egy teljes operációsrendszer-verzióváltással. Utóbbihoz külön kompatibilitási teszt, migrációs terv és visszaállítási eljárás kell. A frissítés itt nem azt jelentette, hogy minden csomagot a lehető legújabb upstream verzióra cserélünk, hanem azt, hogy a pontosan ismert biztonsági kockázatot a lehető legkisebb szükséges beavatkozással kezeljük.

8. A deploy nem az utolsó lépés: valódi ellenőrzés kell

A frissítés sikerét nem lehet egyetlen zöld terminálüzenettel vagy HTTP 200-as válasszal eldönteni. A Columbia Games környezetében a PHP-verziókat, Apache-konfigurációt, konténerlogokat, API-health állapotot és adatbázis-kapcsolatokat ellenőriztük. A KampányMűveköt is kiszolgáló szerveren hét HTTPS-végpont válaszát hasonlítottuk össze a korábbi állapottal; mind a hét megőrizte a várt HTTP-viselkedését, az átirányításokkal együtt. A konfigurációs ellenőrzések és a frissített szolgáltatások állapota megfelelő volt. Ezek célzott smoke tesztek, nem korlátlan biztonsági garanciák, de a változtatások kockázatát jelentősen csökkentik. Mentés és visszaállítási terv nélkül pedig még egy kis javítás is szükségtelenül nagy kockázatot jelenthet.

9. Ami nem látszik a képernyőn, attól még valódi fejlesztés

Ma nem jelent meg új gomb, nem terveztünk át egy termékoldalt, és nem vezettünk be új üzleti funkciót. Ehelyett a Columbia Games két külön PHP-futtatókörnyezete megkapta a megfelelő biztonsági javítást, a KampányMűvek infrastruktúráján ellenőriztük a Canonical támogatott backportját, további csomagokat frissítettünk, és megszüntettük a szükségtelen webes PHP-kezelés egy részét. A vizsgált szolgáltatások elérhetőek maradtak. Ez a munka kevésbé látványos, de a hosszú távon megbízható szoftverhez elengedhetetlen. Egy éles rendszer nem attól jó, hogy ma működik, hanem attól is, hogy holnap biztonságosabban, ellenőrizhetőbben és visszaállítható módon működik tovább.

Mi lett belőle

A Columbia Games CCM v2 API a javított PHP 8.3.36 verzión, a külön WordPress Apache-konténer PHP 8.4.27-en működik; az utóbbinál a korábbi verzió 8.4.21 volt. A KampányMűveköt is kiszolgáló Ubuntu-szerveren ellenőriztük a Canonical által javított, már október 20-án telepített PHP-csomagot, 14 további rendszercsomagot frissítettünk, és szigorítottuk a felesleges PHP-kiszolgálást. A célzott health, napló-, konfigurációs és HTTP-ellenőrzések az érintett vizsgált szolgáltatások működését igazolták. Nem jelentünk teljes körű penetrációs tesztet vagy minden felhasználói műveletre kiterjedő UAT-t; az állításaink az ellenőrzött felületekre és műveletekre vonatkoznak.