Aktuální situace: PHP2Shell. Dvě kritické zranitelnosti PHP (CVSS 9.2) umožňují spustit škodlivý kód bez přihlášení. Záplaty od 21. 10. 2026.Co nyní udělat →

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

Zranitelnosti v PHP se hlásí důvěrně, klasifikují se, opravují ve vydání a zveřejňují jako GitHub Security Advisory. PHP2Shell ukazuje průběh v ostrém případě.

Stav 4 min čteníZnalosti o PHP

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 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í.

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.
  • 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 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

Okamžitý kontakt

Každá hodina se počítá. Napište nám hned.

Stručně popište systém, verzi PHP a pozorování. Ozveme se, vyjasníme situaci a budeme pracovat na dálku, dokud nebude incident uzavřen a zdokumentován.

Okamžitá pomoc