Röviden: A PHP biztonsági réseit bizalmasan jelentik be, lehetőleg a php/php-src GitHub-tároló privát Advisory-űrlapján, vagy a security@php.net címen. A PHP-fejlesztők magasnak, közepesnek vagy alacsonynak minősítik a leletet; a súlyos hibákat egy különálló biztonsági tárolóban javítják ki, és csak a kiadással együtt hozzák nyilvánosságra egy GitHub Security Advisoryvel és többnyire CVE-számmal. A PHP2Shellnél ez a folyamat sebesen zajlott: előzetes bejelentés 2026. október 20-án, javítások 2026. október 21-én, kiegészítő közlemény 2026. október 23-án.
Ki foglalkozik a PHP-nál a biztonsággal?
A PHP nyílt forráskódú projekt. A wikiben lévő biztonsági irányelv önkéntesek projektjeként írja le, jutalmakra szánt költségvetés nélkül. Minden verzióhoz vannak kiadásmenedzserek, akik a megjelenésekért felelnek. Ehhez jön a PHP Foundation, amely saját bemutatása szerint részmunkaidős és teljes munkaidős fejlesztők csapatát bízza meg, akik a PHP karbantartásán, biztonságán és új funkcióin dolgoznak.
A vállalatok számára ez azt jelenti: nincs szerződéses gyártó, ügyfélvonal vagy garantált reakcióidő. Aki kötelező vállalásokra szorul, azokat a Linux-disztribúciójától, a tárhelyszolgáltatójától vagy egy hosszú távú támogatást nyújtó szolgáltatótól kapja, nem a PHP-projekttől. Ezt az ellátási láncot érdemes ismernie.
Így jelentenek be egy rést
Az utat a GitHubon lévő biztonsági irányelv írja le:
- Bejelentés: a
php/php-srctároló Security Advisory privát űrlapján. Aki ezt nem tudja használni, vagy olyan témát akar megbeszélni, amely nem hibajelentés, a security@php.net címre ír. - Tömör leírás: Egy rövid példát kérnek, amely megmutatja a hibát, nem hosszú beszámolót a lehetséges hatásokról. Így a csapat gyorsabban átnézheti.
- Bizalmasság: A bejelentés a közzétételig privát marad.
- Megnevezés: A bejelentőket a MITRE credit-rendszere szerint közreműködőként megnevezik.
A régebbi wiki-oldal emellett megnevezi a klasszikus hibakövetőt a „Security” típussal. Ma a GitHubon át vezető út a mérvadó.
Mit sorol a PHP-projekt biztonsági rések közé
Nem minden összeomlás biztonsági rés. A wiki négy szempontot nevez meg: egy hiba jogosulatlan műveleteket tesz lehetővé, átlépi a biztonsági határokat, hozzáférést nyit idegen adatokhoz, vagy súlyosan rontja a rendelkezésre állást vagy a teljesítményt. A besorolás három fokozatú:
| Fokozat | Jelentés az irányelv szerint | CVE-szám |
|---|---|---|
| Magas | Harmadik felek a legtöbb telepítést kompromittálhatják, kódot hajthatnak végre vagy fájlokat olvashatnak | általában igen |
| Közepes | hasonló hatás, de csak ritkább feltételek mellett, például egy ritka bővítménynél vagy konfigurációnál | többnyire igen |
| Alacsony | elméletileg lehetséges, a gyakorlatban nagyon nehezen kihasználható | többnyire nem |
Ugyanolyan tanulságos annak a listája, ami kifejezetten nem biztonsági rés: szándékosan végrehajtott rosszindulatú kód, az open_basedir és a disable_functions megkerülése, rosszindulatú bemenetek az unserialize()-nak, az FFI használata, valamint egy szokásos memória miatti megszakítás, amelyben a memory_limit érvényesül, és csak az aktuális kérés ér véget. Az üzemeltetők számára ez azt jelenti: a disable_functions értelmes keményítés, de nem védőfal.
A javítástól a közzétételig
A magas és közepes rések javításait a wiki szerint egy különálló biztonsági tárolóban vezetik át, mielőtt a kiadás elkészül. Az alacsonynak minősített hibák normál hibajavításként futnak. A rést a felelős közzététel elve szerint hozzák nyilvánosságra: először a javítás, aztán a részletek. A kiadások a wiki szerint többnyire csütörtökön jelennek meg, gyakran a rendszeres havi kiadások keretében.
A kiadással egy GitHub Security Advisory is megjelenik saját azonosítóval (GHSA) és súlyossági fokkal. A tárolóban például 2026. szeptember 24-én több advisory jelent meg a stream wrapperekről, a FastCGI-ról és a szűrőkről, az alacsonytól a magasig terjedő súlyossági fokokkal. A php.net-en lévő forráscsomagokat SHA-256-ellenőrzőösszegekkel és a kiadásmenedzserek GPG-aláírásaival kínálják; a Git-tagek alá vannak írva. Hogy mely verzióágak kapnak egyáltalán még biztonsági javításokat, azt a PHP-verziók és a kiadási ciklus oldal mutatja.
A PHP2Shell mint példa az éles helyzetre
A PHP2Shell megmutatja, hogyan zajlik a folyamat nyomás alatt:
- 2026. október 20.: a php.net kritikus biztonsági kiadást jelent be 2026. október 21-re 14:00 UTC-re, és fenntartja a jogot a korábbi közzétételre, ha részletek válnának nyilvánossá vagy támadások jelennének meg. Több beszámoló szerint a részletek valóban a zárolási idő lejárta előtt váltak ismertté; a hátteret a Miért vált ismertté a PHP-rés a javítás előtt cikk világítja meg.
- 2026. október 21.: megjelenik a PHP 8.5.12, 8.4.27, 8.3.36 és 8.2.35, hozzájuk a GHSA-w8hw-w9fx-j79w (CVE-2026-109618) és a GHSA-6wmf-4rv5-p3rp (CVE-2026-109619) advisory, mindkettő kritikusnak minősítve. A php.net szerint a Linux-disztribúciók és a hosszú távú támogatást nyújtó szolgáltatók a javításokat előre megkapták. A 7.4-hez, 8.0-hoz és 8.1-hez minimális backportok léteznek.
- 2026. október 23.: egy tájékoztató közlemény a CVE-2026-115560-ról a
session.upload_progress.enabled=0beállítást ajánlja; a teljes advisory a következő kiadással követi.
Mit vezethetnek le ebből az üzemeltetők
- Források feliratkozása: a php.net, a
php/php-srcGitHub-advisory-jai és a disztribúciója biztonsági közleményei. - Az ellátási lánc ismerete: Ki szállítja a PHP-csomagját, és milyen gyorsan érkeznek meg ott a backportok?
- Időablak tervezése: A kritikus kiadások a megszokott ritmuson kívül is jöhetnek; a javítási ablaknak rövid határidővel is lehetségesnek kell lennie.
- Újraindítás betervezése: A frissítés csak akkor hat, ha az összes PHP-folyamatot újraindították.
- Igazolás biztosítása: A verziót, a csomagállapotot és az időpontot dokumentálni kell.
Hogyan segít konkrétan a PHP SOS?
A PHP-javítási szolgáltatással átvesszük azt a részt, amely Önnél van:
- Közlemények követése: Figyeljük a php.net-et, az advisory-kat és a disztribúciók közleményeit, és értékeljük, érintettek-e az Ön rendszerei.
- A javítás megvalósítása: Frissítés a megfelelő forrásból, az összes folyamat újraindítása, a futó verzió ellenőrzése.
- Az átmenet biztosítása: Ahol a frissítés elakad, a hivatalos átmeneti intézkedéseket alkalmazzuk.
- Dokumentálás: Igazolást kap a verziókról, a csomagállapotokról és az időpontokról.
Gyakori kérdések
Hogyan jelentünk be biztonsági rést a PHP-ban?
Lehetőleg a php/php-src GitHub-tárolóban lévő privát Security Advisory bejelentő űrlapon keresztül. Aki ezt nem tudja használni, a security@php.net címre ír. A bejelentés a közzétételig bizalmas marad.
Fizet jutalmat a PHP-projekt a megtalált résekért?
Nem. A biztonsági irányelv szerint a PHP önkéntesek projektje, bug bounty-ra nincs pénz. A bejelentőket azonban közreműködőként megnevezik.
Biztonsági rés a disable_functions megkerülése?
A PHP-projekt irányelve szerint nem. Az open_basedir és a disable_functions megkerülése nem számít a PHP biztonsági problémájának. A beállítások keményítést jelentenek, de nem megbízható biztonsági határt.
Hol értesülök az új PHP-rések ről?
A php.net kezdőlapján a kiadási közleményekből és a php/php-src GitHub-tároló Security Advisory-jaiban. Aki a PHP-t a disztribúcióból szerzi be, emellett annak biztonsági közleményeit is követi.
Miért szerdán tették közzé a PHP2Shellt?
A kiadások a wiki szerint többnyire csütörtökön jelennek meg. A PHP2Shellhez a php.net 2026. október 20-án szerdára, 2026. október 21-re 14:00 UTC-re jelentett be biztonsági kiadást, és fenntartotta a jogot a korábbi közzétételre, ha részletek nyilvánosságra kerülnének.