# Hogyan kezeli a PHP-projekt a biztonsági réseket

> Így kezeli a PHP-projekt a biztonsági réseket: bejelentés GitHubon vagy a security@php.net címen, besorolás, javítás a kiadásban, és tanulságok.

Forrás: https://phpsos.de/hu/php/php-sicherheitsprozess/  
Állapot: 2026. 10. 25.  
Szolgáltató: PHP SOS, PHP-vészhelyzeti segítség és szerverbiztonság. Azonnali segítség WhatsAppon: https://wa.me/491736494914?text=%C3%9Cdv%C3%B6zl%C3%B6m%2C%20PHP%20SOS%21%20Seg%C3%ADts%C3%A9gre%20van%20sz%C3%BCks%C3%A9g%C3%BCnk%20a%20PHP-szerver%C3%BCnkkel.%20C%C3%A9g%3A%20%E2%80%A6%20Weboldal%3A%20%E2%80%A6

**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:

1. **Bejelentés:** a `php/php-src` tá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.
2. **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.
3. **Bizalmasság:** A bejelentés a közzétételig privát marad.
4. **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](https://phpsos.de/hu/ratgeber/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](https://phpsos.de/hu/php/release-zyklus/) 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](https://phpsos.de/hu/blog/php-luecke-vorzeitig-bekannt/) 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=0` beállítást ajánlja; a teljes advisory a következő kiadással követi.

## Mit vezethetnek le ebből az üzemeltetők

1. **Források feliratkozása:** a php.net, a `php/php-src` GitHub-advisory-jai és a disztribúciója biztonsági közleményei.
2. **Az ellátási lánc ismerete:** Ki szállítja a PHP-csomagját, és milyen gyorsan érkeznek meg ott a backportok?
3. **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.
4. **Újraindítás betervezése:** A frissítés csak akkor hat, ha az összes PHP-folyamatot újraindították.
5. **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](https://phpsos.de/hu/leistungen/php-patch-service/) á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.

## Források

- [php-src: biztonsági irányelv és advisory-k (GitHub)](https://github.com/php/php-src/security)
- [PHP Wiki: biztonsági irányelv](https://wiki.php.net/security)
- [php.net: közlemények 2026. október 20. és 23. között](https://www.php.net/)
- [php.net: támogatott verziók](https://www.php.net/supported-versions.php)