# Jak projekt PHP řeší bezpečnostní zranitelnosti

> Jak projekt PHP řeší zranitelnosti: hlášení přes GitHub nebo security@php.net, klasifikace, oprava ve vydání a co z toho plyne pro provozovatele.

Zdroj: https://phpsos.de/cs/php/php-sicherheitsprozess/  
Stav: 25.10.2026  
Poskytovatel: PHP SOS, Nouzová pomoc pro PHP a bezpečnost serverů. Okamžitá pomoc přes WhatsApp: https://wa.me/491736494914?text=Dobr%C3%BD%20den%2C%20PHP%20SOS%2C%20pot%C5%99ebujeme%20pomoc%20s%20na%C5%A1%C3%ADm%20PHP%20serverem.%20Firma%3A%20%E2%80%A6%20Web%3A%20%E2%80%A6

**Stručně:** Zranitelnosti v PHP se hlásí důvěrně, přednostně přes soukromý formulář Advisory v repozitáři GitHub `php/php-src`, případně na security@php.net. Vývojáři PHP nález klasifikují jako vysoký, střední nebo nízký; závažné chyby se opravují v odděleném bezpečnostním repozitáři a zveřejňují se teprve s vydáním spolu s GitHub Security Advisory a většinou s číslem CVE. U PHP2Shell proběhl tento proces ve zrychleném tempu: předběžné oznámení 20. 10. 2026, záplaty 21. 10. 2026, doplňující upozornění 23. 10. 2026.

## Kdo se v PHP stará o bezpečnost?

PHP je open-source projekt. Bezpečnostní politika na wiki jej popisuje jako projekt dobrovolníků bez rozpočtu na odměny. Pro každou verzi existují release manažeři, kteří odpovídají za vydání. K tomu přistupuje PHP Foundation, která podle vlastního vyjádření financuje tým vývojářů na částečný i plný úvazek, jenž pracuje na údržbě, bezpečnosti a nových funkcích PHP.

Pro firmy to znamená: neexistuje výrobce se smlouvou, horkou linkou nebo zaručenými reakčními dobami. Kdo potřebuje závazné záruky, získá je od své distribuce Linuxu, svého poskytovatele hostingu nebo dodavatele dlouhodobé podpory, ne od samotného projektu PHP. Tento dodavatelský řetězec byste měli znát.

## Jak se zranitelnost hlásí

Cesta je popsána v bezpečnostní politice na GitHubu:

1. **Nahlásit:** přes soukromý formulář pro Security Advisories v repozitáři `php/php-src`. Kdo jej nemůže použít nebo chce probrat téma, které není hlášením chyby, píše na security@php.net.
2. **Popsat stručně:** žádoucí je krátký příklad, který chybu ukazuje, ne dlouhá zpráva o možných dopadech. Tým tak může rychleji třídit.
3. **Důvěrnost:** hlášení zůstává do zveřejnění soukromé.
4. **Uvedení jména:** hlásící jsou podle systému credit organizace MITRE uvedeni jako přispěvatelé.

Starší stránka wiki navíc uvádí klasický tracker chyb s typem „Security“. Rozhodující je dnes cesta přes GitHub.

## Co projekt PHP považuje za bezpečnostní zranitelnost

Ne každý pád je bezpečnostní zranitelnost. Wiki uvádí čtyři kritéria: chyba umožňuje neoprávněné akce, překračuje bezpečnostní hranice, otevírá přístup k cizím datům nebo závažně narušuje dostupnost či výkon. Klasifikuje se ve třech stupních:

| Stupeň | Význam podle politiky | Číslo CVE |
|---|---|---|
| Vysoký | třetí strany mohou ohrozit většinu instalací, spouštět kód nebo číst soubory | zpravidla ano |
| Střední | podobný dopad, ale jen za vzácnějších podmínek, například u vzácného rozšíření nebo konfigurace | většinou ano |
| Nízký | teoreticky možné, prakticky velmi obtížně zneužitelné | většinou ne |

Stejně poučný je seznam toho, co výslovně bezpečnostní zranitelností není: škodlivý kód, který se spouští záměrně, obejití `open_basedir` a `disable_functions`, škodlivé vstupy do `unserialize()`, používání FFI a běžné ukončení kvůli paměti, při kterém zabere `memory_limit` a skončí jen aktuální požadavek. Pro provozovatele to znamená: [disable_functions](https://phpsos.de/cs/ratgeber/disable-functions/) je smysluplné zpevnění, ale ne ochranný val.

## Od opravy k zveřejnění

Opravy pro vysoké a střední zranitelnosti se podle wiki zanášejí do odděleného bezpečnostního repozitáře, než se vytvoří vydání. Chyby s nízkým stupněm se řeší jako běžné opravy chyb. Zranitelnost se zveřejňuje podle principu odpovědného zveřejnění: nejdřív oprava, potom podrobnosti. Vydání vycházejí podle wiki většinou ve čtvrtek, často v rámci pravidelných měsíčních vydání.

S vydáním se objeví GitHub Security Advisory s vlastním identifikátorem (GHSA) a stupněm závažnosti. V repozitáři se například 24. 9. 2026 objevilo několik advisories k stream wrapperům, FastCGI a filtrům se stupni závažnosti od nízkého po vysoký. Zdrojové balíčky na php.net se nabízejí s kontrolními součty SHA-256 a podpisy GPG release manažerů; tagy v Gitu jsou podepsané. Které větve verzí vůbec ještě dostávají bezpečnostní opravy, ukazuje stránka o [verzích PHP a cyklu vydávání](https://phpsos.de/cs/php/release-zyklus/).

## PHP2Shell jako příklad ostrého případu

PHP2Shell ukazuje, jak proces probíhá pod tlakem:

- **20. 10. 2026:** php.net oznamuje kritické bezpečnostní vydání na 21. 10. 2026 ve 14:00 UTC a vyhrazuje si zveřejnit dříve, pokud by se podrobnosti dostaly na veřejnost nebo se objevily útoky. Podle několika zpráv se podrobnosti skutečně staly známými před uplynutím lhůty; souvislosti osvětluje článek [Proč se zranitelnost PHP stala známou před záplatou](https://phpsos.de/cs/blog/php-luecke-vorzeitig-bekannt/).
- **21. 10. 2026:** vycházejí PHP 8.5.12, 8.4.27, 8.3.36 a 8.2.35, k tomu advisories GHSA-w8hw-w9fx-j79w (CVE-2026-109618) a GHSA-6wmf-4rv5-p3rp (CVE-2026-109619), obě klasifikované jako kritické. Podle php.net obdržely distribuce Linuxu a dodavatelé dlouhodobé podpory opravy předem. Pro 7.4, 8.0 a 8.1 existují minimální backporty.
- **23. 10. 2026:** informativní upozornění k CVE-2026-115560 doporučuje `session.upload_progress.enabled=0`; úplné advisory bude následovat s dalším vydáním.

## Co z toho plyne pro provozovatele

1. **Odebírat zdroje:** php.net, GitHub advisories `php/php-src` a bezpečnostní oznámení vaší distribuce.
2. **Znát dodavatelský řetězec:** kdo dodává váš balíček PHP a jak rychle tam backporty dorazí?
3. **Plánovat časové okno:** kritická vydání mohou vyjít mimo obvyklý rytmus; okno pro záplatování musí být možné krátkodobě.
4. **Počítat s restartem:** aktualizace je účinná, teprve když jsou restartovány všechny procesy PHP.
5. **Zajistit doklad:** zdokumentovat verzi, stav balíčku a čas.

## Jak konkrétně pomáhá PHP SOS?

Prostřednictvím [služby záplatování PHP](https://phpsos.de/cs/leistungen/php-patch-service/) přebíráme tu část, která leží na vás:

- **Sledovat oznámení:** Sledujeme php.net, advisories a oznámení distribucí a posuzujeme, zda jsou vaše systémy dotčeny.
- **Provést záplatu:** Aktualizace z vhodného zdroje, restart všech procesů, kontrola běžící verze.
- **Zajistit přechodné období:** Kde aktualizace váznou, zavedeme oficiální přechodná opatření.
- **Zdokumentovat:** Obdržíte doklad s verzemi, stavy balíčků a časy.


## Časté dotazy

**Jak se hlásí bezpečnostní zranitelnost v PHP?**  
Přednostně přes soukromý formulář pro Security Advisories v repozitáři GitHub php/php-src. Kdo jej nemůže použít, píše na security@php.net. Hlášení zůstává do zveřejnění důvěrné.

**Vyplácí projekt PHP odměnu za nalezené zranitelnosti?**  
Ne. Podle bezpečnostní politiky je PHP projekt dobrovolníků bez peněz na bug bounty. Hlásící jsou ale uvedeni jako přispěvatelé.

**Je obejití disable_functions bezpečnostní zranitelností?**  
Podle politiky projektu PHP ne. Obejití open_basedir a disable_functions se nepovažuje za bezpečnostní problém PHP. Tato nastavení jsou zpevněním, ale ne spolehlivou bezpečnostní hranicí.

**Kde se dozvím o nových bezpečnostních zranitelnostech PHP?**  
Na úvodní stránce php.net v oznámeních o vydáních a v Security Advisories repozitáře GitHub php/php-src. Kdo získává PHP z distribuce, sleduje navíc její bezpečnostní oznámení.

**Proč byla PHP2Shell zveřejněna ve středu?**  
Vydání vycházejí podle wiki většinou ve čtvrtek. Pro PHP2Shell oznámil php.net dne 20. 10. 2026 bezpečnostní vydání na středu 21. 10. 2026, 14:00 UTC, a vyhradil si zveřejnit dříve, pokud by se podrobnosti dostaly na veřejnost.

## Zdroje

- [php-src: bezpečnostní politika a advisories (GitHub)](https://github.com/php/php-src/security)
- [PHP Wiki: bezpečnostní politika](https://wiki.php.net/security)
- [php.net: oznámení z 20. až 23. 10. 2026](https://www.php.net/)
- [php.net: Podporované verze](https://www.php.net/supported-versions.php)