A történet
Mi történt pontosan
A hibákat a Calif nevű biztonsági cég találta meg, az OpenAI biztonsági munkára hangolt modelljével dolgozva, és tőlük függetlenül a Google tulajdonában lévő Wiz is jelezte ugyanezt. A kutatók php2shell néven hivatkoznak rájuk, mert a kihasználásukkal parancsértelmezőt lehet indítani a kiszolgálón.
Javítás a 8.5.12, a 8.4.27, a 8.3.36 és a 8.2.35 kiadásban jelent meg, tehát ezek valamelyikénél újabb verzió kell mindenhova. Az érintettség széles. A CERT-EU tájékoztatása szerint az ötös verziótól kezdve minden PHP kiadás érintett lehet, és a mérések szerint több százezer kiszolgáló fut olyan régi verzión, amihez már nem jár támogatás.
Csütörtökre készült eredetileg a javítás, végül egy nappal korábban megjelent, mert a kihasználást bemutató videó idő előtt nyilvánosságra került. Kihasználásról a megjelenés napján még alig érkezett jelzés, felderítő jellegű forgalomból viszont annál több.
A nevek mögött két ismert szereplő áll. Közülük a Wiz a felhőbiztonsági piac egyik nagy neve, amit a Google vásárolt meg, a Calif pedig az a fajta új cég, ami kifejezetten modellekkel keres hibát a kódban. Hogy a kettő egymástól függetlenül ugyanarra a hibára jutott, az önmagában is jelzés arról, hogy ez a módszer működik.
A számok miatt érdemes komolyan venni. Ez a nyelv viszi a világ szerveroldali kódjának nagy részét, a tartalomkezelőktől a webshopokon át a belső ügyviteli felületekig, és rengeteg olyan rendszer fut rajta, amihez évek óta nem nyúlt senki. Vagyis nem egy szűk fejlesztői kör ügyéről van szó, hanem mindenkié, akinek van honlapja.
A lényeg
Nem a hiba az újdonság, hanem a sorrend
PHP sérülékenység korábban is volt, és lesz is. Ami most más, az a felfedezés módja. Egy AI eszköz végigolvasta a kódot, megtalálta a hibát, és a védők kaptak néhány napot arra, hogy javítsanak, mielőtt bárki támadna.
Az OpenAI ezt védői ablaknak nevezi. Addig tart, amíg a hiba ismert a javítók körében, de még nem használja ki senki. Az ablak most kinyílt, és a frissítés sebessége dönti el, hogy ki fér be rajta.
A szimmetria viszont nem marad meg sokáig. Ugyanezek az eszközök a támadók kezében is ott vannak, és ők is végig tudják olvasni ugyanazt a kódot. A különbség annyi, hogy nekik nem kell senkivel egyeztetniük a közzététel időpontjáról.
Ebből a védekező oldalnak egy kellemetlen következménye van. Eddig a támadás és a javítás között volt annyi súrlódás, hogy egy közepes cég is beérte havi karbantartással. Ez a türelmi idő most összement, és nem azért, mert a támadók szorgalmasabbak lettek.
Vezetői kérdés
A kérdés nem technikai
Egy vezetőnek ebből három dolog számít. Tudja-e a cég, hol fut nála PHP. Ki az, aki frissíteni tudja. És mennyi idő alatt.
A legtöbb helyen az első kérdésnél megakad a dolog. Külön szállítóknál él a honlap, a webshop, a belső ügyviteli felület és néhány évekkel ezelőtt megrendelt mikrooldal, és nincs egyetlen lista arról, melyik min fut.
Egy szolnoki kereskedő ügyfelemnél tavaly ez a lista két napig készült, és a végén kiderült, hogy a webshop mellett van két régi kampányoldal is, amiről senki nem tudott, és amit évek óta nem frissített senki. Nem az AI korszak hozta ezt a problémát, viszont most drágább, mint korábban.
Érdemes a kérdést a legegyszerűbb formában feltenni a következő vezetői megbeszélésen. Ha ma délután kiderülne, hogy a honlapunk alapjában kritikus hiba van, akkor ki az, aki ezt estig megjavítja, és honnan tudná meg egyáltalán, hogy baj van. Amíg erre nincs név és nincs csatorna, minden más másodlagos.
Sok helyen a honlap üzemeltetése évek óta ugyanannál az ügynökségnél van, és a kapcsolattartó azóta már máshol dolgozik. Ilyenkor a hozzáférések és a jelszavak is kérdésessé válnak, és egy sürgős javítás abba is beleszaladhat, hogy senki nem tud belépni a kiszolgálóra.
Idő
A javítás ideje üzleti mérőszám lett
Régebben elég volt havonta ránézni a frissítésekre. Amikor a hibát egy gép találja meg és egy másik gép keresi a sérülékeny kiszolgálókat, akkor a napok számítanak, nem a hetek.
Érdemes ezért kimondani egy számot. Kritikus hibánál mennyi idő alatt kerül ki a javítás a rendszereinkre. Hetvenkét óra reális vállalás a legtöbb középvállalatnál, és ez benne is lehet a szállítói szerződésben.
A méréshez sem kell bonyolult eszköz. Elég rögzíteni, mikor jelent meg a javítás, és mikor került fel. Az első három eset után kiderül, hol akad el a folyamat, és rendszerint nem a technikán múlik, hanem azon, hogy ki hagyja jóvá a leállást.
Van ennek egy ritkán emlegetett ellentétele is. A gyors frissítés kockázattal jár, mert egy javítás el is ronthat valamit. Ezért kell mellé teszt és visszaállítási terv, és ezért nem lehet ezt egyetlen ember hétvégi műszakjára bízni. A hetvenkét óra pont azért reális vállalás, mert belefér egy ellenőrzött kiadás.
Egy hazai középvállalatnál ezt a számot nem a fejlesztők szokták megadni, hanem a vezetés. Ők tudják, mennyi állásidő fér bele egy hétköznap délutánba, és mennyibe kerül egy órányi leállás a webshopban. Ebből jön ki az a vállalás, amit utána tartani is lehet.
Szállító
Amit a szállítótól kell kérni
Ha a rendszert külsős csapat üzemelteti, akkor írásban érdemes kérdezni. Milyen verzió fut, mikor volt az utolsó frissítés, és mennyi időn belül javítanak kritikus hiba esetén.
A válasz minősége önmagában is információ. Aki egy napon belül válaszol verziószámmal, az nagy eséllyel tudja is, mit üzemeltet. Ahol viszont két hétig nem érnek rá, ott a következő sérülékenységnél sem lesz másképp.
A szerződésbe pedig kerüljön be a vállalás. Nem azért, hogy legyen kit büntetni, hanem mert ettől lesz valakinek a dolga a frissítés, és nem marad senki feladata.
Ugyanilyen fontos kérdés, hogy a szállító honnan értesül a hibáról. Ha csak a hírekből, akkor a cég mindig késésben lesz. Aki figyel egy sérülékenységi listát vagy a gyártó értesítőjét, az rendszerint a megjelenés napján tud lépni, és ez a két vagy három nap különbség szokta eldönteni a dolgot.
A kérdést érdemes most feltenni, nem a következő riasztás közben. Egy nyugodt hétköznap délelőtt megírt levélre korrekt válasz jön, ugyanez pánikban már számonkérésnek hangzik, és a szállító védekezni fog ahelyett, hogy dolgozna.
Tanulság
Mit tanulhatunk a felfedezés módjából
A gépi kódátnézés ma már nem ígéret. Egy modell végigolvas egy sok millió sorból álló kódbázist, és megtalálja benne azt a mintát, amit évek óta mindenki átnézett. A biztonsági munkában ez a rész automatizálható lett.
Ettől még nem a gép dönt. A javítás kiadásának időzítése, az érintettek értesítése és a közzététel rendje emberi döntés maradt, és most is ez okozta a legnagyobb feszültséget, amikor a bemutató videó idő előtt kikerült.
Saját fejlesztésű rendszernél innen jön a tanulság. Ha a kódunkat nem nézi át rendszeresen valaki vagy valami, akkor abban ugyanúgy ott vannak a hibák, csak nem tudunk róluk. A különbség az, hogy ezeket már a másik oldal is meg tudja találni géppel.
Ebből következik az is, hogy a saját kód átnézését érdemes beépíteni a fejlesztési körbe. Nem külön projektként, hanem úgy, hogy minden nagyobb kiadás előtt lefut egy gépi átnézés, és a talált tételekből az számít, amit egy ember is megerősít. A gépi találatok jó része zaj, a maradék viszont éppen az, amit évekig senki nem vett észre a kódban.
Nem árt tudni, hogy ez a módszer nem hibátlan. A modell sok olyan találatot is jelez, ami végül semmi, és a megerősítés emberi munka marad. Ettől még a mérleg a védők felé billen, mert a végigolvasás ára majdnem nulla lett, a megerősítés pedig arányosan kevés időt visz el.
Teendő
Amit ezen a héten érdemes megcsinálni
Az első lépés a lista. Minden rendszer, ami webet szolgál ki, a honlaptól a belső felületekig, és mellé a felelős neve.
A második a verziók ellenőrzése és a frissítés ütemezése. Ahol a verzió már nem kap támogatást, ott nem javítás kell, hanem költözés egy támogatott változatra, és ezt érdemes projektként kezelni, nem hibajavításként.
A harmadik a mérés rögzítése. Mikor jelent meg a javítás, és mikor került fel. Ebből lesz a vállalás, amit a következő körben már lehet tartani.
Ez a három lépés néhány napot visz el, és nem kíván új beszerzést. A következő kritikus hibánál pedig ez a különbség a nyugodt szerda és a pánikszerű hétvége között.
Érdemes a listát egy helyen tartani, és felelőst rendelni minden sorhoz. Ha ez csak egy táblázat, az is elég, a lényeg, hogy a következő riasztásnál ne kelljen összeszedni, hanem meg lehessen nyitni.
A régi, támogatás nélküli verziókkal külön kell foglalkozni. Ott a frissítés rendszerint nem egyetlen kattintás, mert a kód is átírást kíván, és ezt a munkát a legtöbb cég addig halogatja, amíg nem történik baj. Ennél olcsóbb egy tervezett költözés, amire van idő tesztelni.
Források
Ahol a részletek megtalálhatók
A két sérülékenység azonosítója CVE-2026-109618 és CVE-2026-109619, a javítás pedig a PHP 8.5.12, 8.4.27, 8.3.36 és 8.2.35 kiadásban érhető el. A felfedezés körülményeiről és a közzététel időzítéséről a szakmai sajtó számolt be, köztük a CyberScoop és a The Hacker News.