Röviden: Aki függőségeket akar frissíteni, annak három csomagvilágra kell folyamat: Composer-csomagokra a PHP-kódban, npm-modulokra a frontend-buildben, valamint bővítményekre vagy témákra a CMS-ben. Ide tartozik egy rögzített ritmus, egy felelős személy, tesztek a kitelepítés előtt és egy terv a frissítés nélküli csomagokra. A PHP2Shell ellen ez nem segít, mert az a rés magában a PHP-ban van, de segít az idegen kód sok rése ellen.
Három csomagvilág, egy vakfolt
A 2026. október 21. utáni héten minden a PHP-értelmező körül forgott. Sok csapat eközben észrevette, hogy nem ismeri pontosan a saját építőelemeinek verzióit. A weboldal fut, az ügynökség foglalkozik vele, a bővítmény jelentkezik, ha van valami új: így vagy hasonlóan szólnak a feltevések, amíg valaki utána nem néz.
Egy tipikus PHP-projekt ma lényegesen több idegen, mint saját kódból áll. Az OWASP Top 10 a sebezhető és elavult komponenseket külön kockázati kategóriaként vezeti. A probléma ritkán a hiányzó eszköz, hanem a hiányzó rutin: a frissítések akkor történnek meg, ha valakinek van ideje, a biztonsági közlemények pedig egy olyan postafiókba kerülnek, amelyet senki sem olvas.
Mely függőségeket frissíti hol
Minden csomagvilágnak saját eszközei és saját buktatói vannak. A következő áttekintés segít, hogy semmit se hagyjon ki.
| Csomagvilág | Állomány megjelenítése | Rések ellenőrzése | Tipikus buktató |
|---|---|---|---|
| Composer (PHP-könyvtárak) | composer show |
composer audit |
közvetett csomagok, amelyeket senki sem ismer |
| npm (frontend-build) | npm ls |
npm audit |
egy újraépítés nélküli frissítés sosem ér el a szerverre |
| CMS-bővítmények és témák | admin felület vagy CLI | gyártói tájékoztatók, biztonsági szolgáltatások | felhagyott bővítmények, frissítési csatorna nélküli fizetős bővítmények |
| PHP és bővítményei | csomagkezelő | a disztribúció security trackere | a megjelenített verzió keveset mond a backportokról |
Az utolsó sor szigorúan véve nem tartozik az alkalmazás függőségei közé, de gyakran ugyanabban a pillanatban elfelejtik. Ugyanez érvényes az idegen szerverekről közvetlenül beágyazott szkriptekre, például CDN-ből származó könyvtárakra, chat-widgetekre vagy követőkódra. Egyetlen lock-fájlban sem szerepelnek, de a látogatói böngészőjében futnak. Vegye fel őket a listára, és ellenőrizze, hogy rögzített verziókat ágyaztak-e be a „mindig a legújabb” helyett. A composer audit, a lock-fájl és a buildbe illesztés részleteit a Composer-függőségek ellenőrzése résekre útmutató tartalmazza. Hogy a Composer alapvetően hogyan működik, azt a Composer: a PHP csomagkezelője magyarázza el.
A karbantartási ciklus hat lépésben
Egy teherbíró folyamatnak nem kell bonyolultnak lennie. Ez a sorrend vált be:
- Az állomány rögzítése: minden projekthez a közvetlen függőségek listája verzióval, eredettel és céllal. A lock-fájlok (
composer.lock,package-lock.json) a repositoryba tartoznak. - A közlemények gyűjtése: az ellenőrző eszközök minden buildnél lefutnak, és ezenkívül rendszeresen a kiszolgált állapoton is, kódmódosítás nélkül is.
- Értékelés: használják-e az érintett csomagot éles üzemben, elérhető-e az érintett funkció, van-e javított verzió?
- Frissítés és tesztelés stagingben: először a biztonsági frissítések ugyanazon főverzión belül, az új főverziókra való ugrásokat külön vállalkozásként tervezni.
- Kitelepítés visszaúttal: az előző állapot csomagként vagy release-ként elérhető marad, adatbázis-mentés a frissítés előtt.
- Dokumentálás: mit frissítettek mikor, mit nem tudatosan, és miért.
Ügyeljen közben a composer.json és a package.json verziómegadásaira. A túl szűk megadások megakadályozzák, hogy a biztonsági javítások egyáltalán telepíthetők legyenek. A túl tág megadások viszont ellenőrizetlenül hoznak új főverziókat a projektbe. Az vált be, ha engedélyezi a frissítéseket a főverzión belül, a következőre való ugrást pedig tudatosan tervezi.
A CMS-bővítményeknél a rendelkezésre álló frissítések gyakran a parancssorban is megjeleníthetők, a WordPressnél például a WP-CLI-vel:
# Elérhető frissítések megjelenítése, bármit is módosítva
wp plugin list --update=available
wp theme list --update=available
# Frontend-csomagok: elavult verziók és ismert rések
npm outdated
npm audit --omit=dev
Az automatikus bővítményfrissítések közvetlenül az éles rendszeren kényelmesek, de kockázatosak, ha utána senki sem ellenőriz. Csak akkor kapcsolja be őket, ha minden futás előtt mentés, utána pedig ellenőrzés biztosított.
Ha nincs frissítés
Nem minden közleményt lehet egy kattintással megoldani. A sebezhető függőségek kezeléséről szóló OWASP Cheat Sheet több esetet különböztet meg, amelyek jól átvihetők a mindennapokra:
- Elérhető javítás: stagingben telepíteni, tesztelni, kitelepíteni. Ha valami elromlik, a saját kódot kell igazítani ahelyett, hogy a frissítés heverne.
- Bejelentett, de még nem elérhető javítás: a gyártó kerülőmegoldását megvalósítani, az érintett funkciót ha lehet kikapcsolni vagy elzárni, a döntést rögzíteni.
- Nem várható javítás: helyettesítő csomagot keresni, vagy a javítást magunk visszaportolni, olyan teszttel, amely megkülönbözteti a rést a javítás előtt és után.
A CMS-bővítményeknél gyakori a negyedik eset: a bővítményt felhagyták. Ilyenkor csak a csere vagy az eltávolítás segít. Ugyanez érvényes a tisztázatlan forrásból származó bővítményekre, például a fizetős bővítmények „ingyenes” másolataira. Ezek nem kapnak frissítést a hivatalos csatornán, és nem ritkán maguk is kártékony kódot tartalmaznak. A WordPress-üzemeltetők számára a tudnivalókat a WordPress és a PHP2Shell foglalja össze.
Felelősség tisztázása, mielőtt jön a következő közlemény
Az elavult csomagok leggyakoribb oka nem technikai akadály, hanem egy nyitott kérdés: ki csinálja? Az olyan projekteknél, amelyeket egy ügynökség épített, és belül üzemeltetnek, gyakran senki sem érzi magát felelősnek. Minden projektre határozza meg, ki kapja a közleményeket, ki értékel és ki hagy jóvá, és írja le.
Tervezzen ezenkívül időt. Egy havi rögzített karbantartási időpont, amelyen a függőségeket ellenőrzik és frissítik, megakadályozza, hogy a frissítések évekig felgyűljenek. Minél hosszabb ideje nem frissítettek egy projektet, annál nagyobb és kockázatosabb a következő ugrás. Hogyan illeszkednek a PHP és a csomagok frissítései egy átfogó folyamatba, azt a Patchmenedzsment folyamatként, nem tűzoltásként írja le.
Hogyan segít konkrétan a PHP SOS?
- Felmérjük a projektjei összes függőségét a Composerből, az npm-ből és a CMS-ből, és megjelöljük az elavult, sebezhető és felhagyott csomagokat.
- Automatikus ellenőrzéseket állítunk be, és meghatározzuk, ki melyik közleményt értékeli.
- Stagingben frissítünk, teszteljük a legfontosabb folyamatokat, és visszaúttal telepítünk.
- A biztonsági karbantartási szerződés keretében tartósan átvesszük a havi ciklust, a PHP-frissítésekkel együtt.
Összegzés: A naprakész függőségek nem projekt, hanem rutin. Aki az állományt, a ritmust és a felelősséget egyszer rendesen szabályozza, a következő nagy közleménynél már csak ellenőriznie kell, nem keresgélnie.
Gyakori kérdések
Milyen gyakran kell frissíteni a függőségeket?
A biztonsági frissítéseket az értékelés után a lehető leghamarabb, a rutinfrissítéseket rögzített ritmusban, például havonta. A pontos gyakoriságnál fontosabb, hogy az időpont rögzített legyen, és legyen valaki felelős érte.
Véd egy naprakész bővítmény a PHP2Shell ellen?
Nem. A PHP2Shell magában a PHP-értelmezőben van. Ez ellen csak a PHP-frissítés segít az összes PHP-folyamat újraindításával. A naprakész bővítmények és csomagok ettől még fontosak, mert saját réseket zárnak le.
Mit kezdjek egy bővítménnyel, amelyet már nem gondoznak?
Cserélje le vagy távolítsa el. Egy felhagyott bővítmény nem kap több javítást, még ha ma még működik is. A csere előtt ellenőrizze, hogy a funkcióra valóban szükség van-e, és dokumentálja a döntést.
A frontendet az npm-mel a szerveren is frissíteni kell?
Az npm-csomagok gyakran csak a buildben vannak, és kész fájlokként kerülnek a szerverre. Egy csomag hibája ettől még benne lehet a kiszolgált JavaScriptben. Egy frissítés után ezért újra kell építeni és újra kell kiszolgálni.