Debian és Ubuntu: javított a PHP-csomagom?

Röviden: Hogy a PHP-csomagja Debianon vagy Ubuntun javított-e a PHP2Shell ellen, a pontos csomagállapotról ismeri fel, nem a PHP-verzióról. Az Ubuntu 2026. október 21-én javított csomagokat tett közzé az összes támogatott kiadáshoz, a régebbiekhez az Ubuntu Pro-n keresztül. A Debian a bookwormban a php8.2-t, a trixie-ben a php8.4-et javította. Hasonlítsa össze a telepített állapotot a dpkg --compare-versions paranccsal, majd indítsa újra az összes PHP-szolgáltatást.

A kérdés mögötti kérdés

A „Javított a PHP-csomagom?” igen-nem kérdésnek hangzik. A gyakorlatban a válasz három dologtól függ: melyik forrásból származik a csomag, melyik állapot van telepítve, és ez az állapot futóképes-e is? Ez az írás az első két pontot válaszolja meg a Debian és az Ubuntu hivatalos csomagjaira. Hogyan ellenőrizheti általában a verziót és a futó folyamatokat, azt a PHP-verzió és javítási állapot helyes ellenőrzése oldal tartalmazza.

Az adatokat az Ubuntu hivatalos biztonsági közleményeiből és a Debian Security Trackerből 2026. október 25-én kérdeztük le. Mindkét CVE, a CVE-2026-109618 és a CVE-2026-109619, ugyanazokkal a javított állapotokkal szerepel ott.

Javított csomagállapotok az Ubuntunál

Az Ubuntu a javításokat két közleménnyel tette közzé. A USN-8948-1 az aktuális kiadásokat fedi le, a USN-8948-2 a régebbieket, amelyek már csak az Ubuntu Pro-n keresztül kapnak biztonsági frissítéseket. A 16.04-nél és a 14.04-nél az Ubuntu emellett a Legacy-Support ajánlatot is megnevezi.

Feltűnő, hogy az összes állapot megtartja az eredeti PHP-verziót. Az Ubuntu 24.04 a 8.3.6-nál marad, noha a javítást a 8.3.36-ból vették át. Hogy ez miért van így és hogyan kezelje, azt a Miért mutat a php -v ugyanazt a számot írás magyarázza. Érintettek egyebek mellett az FPM, a CLI, a CGI és az Apache-modul bináris csomagjai, például a php8.3-fpm és a libapache2-mod-php8.3.

Javított csomagállapotok a Debiannál

A Debian itt más utat jár, és az új upstream verziókat szállítja. A Security Tracker szerint az állapot így néz ki:

A bookwormra vonatkozó közlemény DLA-ként, vagyis a Debian LTS-en keresztül jelent meg. A php8.2-höz az unstable ágban a tracker a lekérdezéskor még nem tüntet fel javított állapotot. Aki unstable ágon üzemeltet tesztrendszereket, tartsa ezt szemmel.

A régebbi Debian-kiadások a két CVE-bejegyzésben a lekérdezéskor nem szerepelnek. Ha egy szerver még ilyen kiadáson fut, például a PHP 7.4-es Debian 11-en, nem hagyatkozhat a hivatalos archívum biztonsági frissítésére. Ilyenkor három út marad: az operációs rendszert egy támogatott kiadásra emelni, egy kereskedelmi hosszú távú ajánlatot használni, amelynek a PHP2Shellre való lefedettségét írásban erősíttesse meg, vagy a szervert a migrációig átmeneti intézkedésekkel biztosítani és az elérhetőségét korlátozni. Hosszú távon csak az első út tartható.

Így hasonlítsa össze pontosan a telepített állapotot

A verziószámra való pillantás nem elég, mert a Debian-verziókat saját szabályok szerint rendezik. A dpkg --compare-versions helyesen hasonlít össze. A következő parancsok kizárólag olvasnak; a csomagneveket és a célállapotot igazítsa a saját kiadásához.

# A csomag telepített állapota és eredete
apt policy php8.3-fpm

# Az összes telepített PHP-csomag verzióval
dpkg-query -W -f='${Package}\t${Version}\n' 'php*' 'libapache2-mod-php*' 2>/dev/null

# Pontos összehasonlítás a javított állapottal (példa: Ubuntu 24.04)
v=$(dpkg-query -W -f='${Version}' php8.3-fpm)
dpkg --compare-versions "$v" ge 8.3.6-0ubuntu0.24.04.13 && echo "korrigiert: $v" || echo "PRÜFEN: $v"

Az apt policy kimenetében figyeljen a csomagforrást tartalmazó sorra. Ha ott nem a disztribúciója biztonsági archívuma áll, hanem például a packages.sury.org vagy egy PPA, a fenti táblázatok nem érvényesek. Akkor ennek a harmadik féltől származó forrásnak az állapota számít, amelyet a A sury.org-tároló írásban tárgyalunk.

Emellett megéri belenézni a mellékelt changelogba. Hogyan találja meg ott a CVE-számokat és rögzítheti igazolásként, azt a CVE-számok igazolása a csomag changelogjában írás írja le.

Tipikus buktatók az ellenőrzésnél

Csak egy csomagot ellenőriztek: A PHP sok bináris csomagból áll. Ha a php8.3-cli aktuális, de a php8.3-fpm nem, a weboldal nyitva marad. Ellenőrizze egy ág összes csomagját, különösen az FPM-et, a CGI-t és az Apache-modult.

Csomag visszatartva: Az apt-mark hold-dal rögzített csomagok a frissítésnél a helyükön maradnak. Az apt-mark showhold megmutatja őket.

Az Ubuntu Pro nem aktív: A 20.04-en és régebbieken a javítások csak akkor érkeznek, ha az Ubuntu Pro be van állítva. Pro nélkül a rendszer a frissítési futás ellenére sebezhető marad.

Elavult tükör: Ha a szerver egy belső tükrön vagy proxyn keresztül tölti le a csomagokat, az új biztonsági frissítéseket csak akkor látja, ha ez frissült. Kétség esetén ellenőrizze, hogy az apt update ténylegesen eléri-e a biztonsági forrást.

Elfelejtett újraindítás: Az új csomagok csak az összes, PHP-t betöltő szolgáltatás újraindítása után hatnak. A needrestart, ha telepítve van, megmutatja az elavult kódú szolgáltatásokat.

Hogyan segít konkrétan a PHP SOS?

• Minden szerverre meghatározzuk az összes PHP-csomag eredetét, és az állapotot összevetjük a hivatalos közleményekkel.
• Telepítjük a frissítéseket, az Ubuntu Pro-n keresztül is, és újraindítjuk az összes érintett szolgáltatást.
• A PHP-javítási szolgáltatással szerverenként igazolást kap csomagállapottal, changelog-találattal és az újraindítás idejével.
• Harmadik féltől származó források vagy régi verziók esetén tisztázzuk, melyik út vezet igazolhatóan javított állapothoz.

Gyakori kérdések

Források

• Ubuntu Security Notice USN-8948-1
• Ubuntu Security Notice USN-8948-2
• Debian Security Tracker: CVE-2026-109618
• Debian Security Tracker: CVE-2026-109619