Aktuális helyzet: PHP2Shell. Két kritikus PHP-rés (CVSS 9,2) lehetővé teszi kártékony kód futtatását bejelentkezés nélkül. Javítások 2026. 10. 21. óta.Mi a teendő most →

PHP-verzióváltás vagy backport? A döntés régi rendszereknél

A régi PHP-verziókhoz a PHP2Shell után több út van: disztribúciós backport, harmadik fél forrás, forráskód-javítás, hosszú távú támogatás vagy verzióváltás. Mit ér az egyes út, és meddig hord.

Állapot 5 perc olvasási időDöntéstámogatás

Röviden: Hogy a PHP-verzióváltás vagy a backport a helyes választás, azon múlik, mennyi ideig kell még futnia a rendszernek, és mennyire jól igazolt a backport. A saját disztribúció backportja egy támogatott operációs rendszeren teljes értékű út. A forráskód-backportok, a harmadik fél források és a PHP 8.1-hez és régebbiekhez szóló kereskedelmi hosszú távú támogatás lejárati dátummal rendelkező hidak. Hosszú távon csak az olyan PHP-verzióra való átállás segít, amelyet a PHP-projekt még hivatalosan támogat.

Miért sürgős a kérdés a PHP2Shell után

    1. 21-én a PHP-projekt kijavította a PHP2Shellt a 8.5.12, 8.4.27, 8.3.36 és 8.2.35 verziókban. A PHP 8.1-hez és régebbiekhez már nincsenek hivatalos kiadások, csak minimális forráskód-backportok a 7.4, 8.0 és 8.1 verziókhoz. A szakmai sajtó szerint szinte az összes verzió érintett egészen a PHP 5.4-ig visszamenőleg.

Ezzel a régi rendszerek sok üzemeltetője ugyanazzal a kérdéssel áll szemben: elég-e valahogyan befoltozni a rést, vagy most kell az évek óta halogatott verzióváltás? Hogy mit jelent a gyakorlatban a verzióváltás, azt a PHP 8.1 és régebbi verziók migrációjára szóló ajánlatunk írja le. Hogy mi érvényes hivatalos frissítés nélkül, az a PHP 8.1 és régebbi: mi érvényes most oldalon áll. Ez a cikk a kettő közötti mérlegelésben segít.

Milyen fajta backportok léteznek

A „backport” gyűjtőfogalom. Mindig azt jelenti, hogy egy újabb verzió javítását átveszik egy régebbibe. Hogy ki teszi ezt, és mennyire jól ellenőrzött, az azonban nagyon eltér.

  1. Disztribúciós backport: A Debian, az Ubuntu, a Red Hat és mások átveszik a biztonsági javításokat a támogatott kiadásaik PHP-csomagjaiba. A verziószám ilyenkor gyakran ugyanaz marad; a beszámolók szerint például az Ubuntu 24.04 a frissítés után is 8.3.6-ot mutat. A javítást a csomag changelogja és a disztribúció biztonsági közleményei igazolják.
  2. Harmadik fél forrás: Ondřej Surý sury.org repositoryja a beszámolók szerint buildeket biztosított az 5.6-tól a 8.5-ig minden ághoz. Nem a Debian biztonsági archívuma. A részleteket a A sury.org repository tartalmazza.
  3. A PHP-projekt forráskód-backportja: A 7.4, 8.0 és 8.1 verziókhoz vannak minimális javítások a forráskódban, de kész kiadások nincsenek. Aki használja őket, annak magának kell a PHP-t felépítenie, tesztelnie és a jövőben gondoznia.
  4. Kereskedelmi hosszú távú támogatás: Az olyan szolgáltatók, mint a TuxCare ELS vagy a Zend/HeroDevs, régi verziók gondozását kínálják. Hogy lefedik-e a PHP2Shellt, és mikortól, azt írásban meg kell erősíttetni; az ismert forrásokban ez nem volt igazolva. Többet erről a Hosszú távú támogatás régi PHP-verziókhoz tartalmaz.

PHP-verzióváltás vagy backport: az összehasonlítás

Szempont Váltás támogatott verzióra Backport (fajtától függően)
Védelem a PHP2Shell ellen Igen, a 8.2.35, 8.3.36, 8.4.27 vagy 8.5.12 verzióval Igen, ha teljes és igazolt
Jövőbeli biztonsági frissítések Hivatalosan a verzió támogatásának végéig Csak amíg az adott szolgáltató gondozza
Igazolás Verziószám plusz újraindítás Csomag changelogja CVE-számokkal, a szolgáltató megerősítése
Ráfordítás most Közepes vagy magas, kompatibilitási tesztek szükségesek Alacsony a disztribúciónál, magas saját építésnél
Ráfordítás később Alacsony a következő verzióugrásig Minden új réssel nő
Kockázat az alkalmazásra Inkompatibilitások a régi kóddal és bővítményekkel Alacsony, a viselkedés nagyjából változatlan marad
Alkalmasság tartós megoldásnak Igen Csak a disztribúciós backport egy támogatott operációs rendszer keretében

A „Ráfordítás később” sor a legfontosabb. A PHP2Shell nem lesz az utolsó rés. Minden hónap egy hivatalos támogatás nélküli verzión azt jelenti, hogy a következő közlemény ismét ugyanazt a kérdést veti fel.

Melyik célverzió a verzióváltásnál?

A php.net szerint minden PHP-ágra érvényes: két év aktív támogatás, utána két évig csak biztonsági javítások. Ebből adódnak a biztonsági támogatás következő végdátumai:

Verzió Biztonsági támogatás eddig
PHP 8.2 2026. 12. 31.
PHP 8.3 2027. 12. 31.
PHP 8.4 2028. 12. 31.
PHP 8.5 2029. 12. 31.

A 8.2-re való váltás ezért már csak rövid köztes állomás. Aki amúgy is migrál, annak hosszabb időhorizontú verziót érdemes célba vennie, feltéve, hogy a CMS, a webshop és a bővítmények támogatják. Ezt a gyártó rendszerkövetelményeiben ellenőrizze, ne emlékezetből. Hogyan működik a kiadási ciklus, azt a PHP-verziók és a kiadási ciklus magyarázza el.

Fontos

Bármelyik utat választja: a telepítés után az összes PHP-folyamatot újra kell indítani. Egy backport, amely csak a merevlemezen van, nem véd, amíg régi workerek futnak a memóriában.

Pragmatikus sorrend régi rendszerekhez

  1. Azonnal: A php.net szerinti átmeneti intézkedéseket beállítani, vagy a rendszert átmenetileg levenni a hálózatról, ha nincs elérhető igazolt javítás.
  2. A következő napokban: Igazolt backportot telepíteni, lehetőleg a saját disztribúcióból vagy a szolgáltató írásbeli megerősítésével.
  3. Párhuzamosan: Ellenőrizni az alkalmazás kompatibilitását egy támogatott verzióval, és ütemtervet rögzíteni.
  4. A következő hónapokban: Verzióváltás a célverzióra, tesztmásolatban előkészítve, visszaesési tervvel.

Az a döntő gondolat, hogy a backportot hídnak tekintse, nem célnak.

Mikor nincs ehhez szüksége szolgáltatóra

Ha a szervere támogatott Debianon, Ubuntun vagy RHEL-en fut, és a disztribúció szállítja a backportot, elég egy szokásos frissítés újraindítással és egy pillantás a changelogba. Ezt egy tapasztalt admin egyedül is megoldja. Segítség saját építéseknél, harmadik fél forrásoknál, nagyon régi verzióknál vagy olyan alkalmazásnál éri meg, amelynek kompatibilitását már senki sem látja át.

Hogyan segít konkrétan a PHP SOS?

  • Megvizsgáljuk, mely PHP-verziók és csomagforrások futnak a szerverein, és van-e igazolt javítás.
  • Backportokat telepítünk, újraindítunk, és a changelogon keresztül dokumentáljuk az igazolást.
  • Egy másolatban teszteljük az alkalmazását a célverzióval szemben, és megnevezzük az inkompatibilitásokat.
  • Megtervezzük és kísérjük a verzióváltást a PHP 8.1 és régebbi migrációja keretében.

Összegzés

A disztribúció backportja teljes értékű út, az összes többi backport híd. Aki PHP 8.1-en vagy régebbin ragadt, a backportot arra használja, hogy időt nyerjen a verzióváltáshoz, ne arra, hogy tovább halogassa.

Gyakori kérdések

Ugyanolyan biztonságos a backport, mint a verzióváltás?

A konkrétan kijavított résre a backport egyenértékű lehet, ha teljes és igazolt. De csak azt javítja, amit visszaportoltak. A támogatott verzióra való váltás ezenfelül az összes jövőbeli hivatalos biztonsági frissítést is hozza.

Miről ismerem fel, hogy a backportom lefedi a PHP2Shellt?

A csomag changelogjáról: ott szerepelnie kell a CVE-2026-109618 és CVE-2026-109619 számoknak. Debianon és Ubuntun az apt-get changelog mutatja, az RHEL-családban az rpm -q --changelog. A verziószám önmagában nem bizonyíték.

Meddig kap még biztonsági frissítést a PHP 8.2?

A php.net szerint a PHP 8.2 biztonsági támogatása 2026. 12. 31-én ér véget. Aki ma 8.2-re frissít, annak a következő lépést is rögtön be kell terveznie.

Megéri a kereskedelmi hosszú távú támogatás régi PHP-verzióknál?

Híd lehet, ha a verzióváltás rövid távon lehetetlen. Erősítse meg írásban, hogy lefedi-e a PHP2Shellt, és mikortól. A eddig ismert forrásokban ez nem volt igazolva.

Források

Azonnali kapcsolat

Minden óra számít. Írjon nekünk most.

Ismertesse röviden a rendszert, a PHP-verziót és a megfigyelését. Jelentkezünk, tisztázzuk a helyzetet, és távolról dolgozunk, amíg az incidens le nem zárul és dokumentálva nem lesz.

Azonnali segítség