# Po PHP2Shell: proč jsou další oznámení pravděpodobná

> Po PHP2Shell jsou další oznámení k PHP pravděpodobná. Podle čeho to poznáte, které zdroje sledovat a jak má váš tým připraveně reagovat.

Zdroj: https://phpsos.de/cs/blog/weitere-php-meldungen/  
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ě:** Po PHP2Shell jsou další oznámení k PHP pravděpodobná, protože už dva dny po záplatě přišlo třetí upozornění, úplné advisory stále chybí a distribuce své balíčky dodávají postupně. Kdo nyní zřídí pevný postup pro sledování, vyhodnocení, aktualizaci a restart, zareaguje na příští novou bezpečnostní zranitelnost PHP v hodinách místo v dnech.

## Záplata nebyla koncem příběhu

Dne 21. října 2026 uzavřel projekt PHP obě kritické zranitelnosti CVE-2026-109618 a CVE-2026-109619 verzemi 8.5.12, 8.4.27, 8.3.36 a 8.2.35. Mnozí odpovědní si poté odškrtli položku. O dva dny později, 23. října, ale následovalo další upozornění php.net k CVE-2026-115560.

Toto třetí upozornění se týká jen neobvyklé konfigurace session. Ukazuje ale vzorec, který je u velkých bezpečnostních případů znám: Když se nějaká součást náhle ocitne ve světle reflektorů, dívá se mnoho odborníků současně pozorněji. Zda z toho vzniknou další zranitelnosti, dnes nikdo neví. Pravděpodobné je ale to, že zpravodajství neustane.

Pro vás jako provozovatele to znamená: Počítejte s navazujícími oznámeními, místo abyste byli každým překvapeni. Dosavadní průběh událostí shrnuje naše [chronologie PHP2Shell](https://phpsos.de/cs/ratgeber/php2shell-chronologie/).

## Proč jsou další oznámení pravděpodobná

Následující posouzení vychází z veřejně známých faktů. Není předpovědí konkrétních zranitelností.

1. **Advisory stále chybí.** php.net řeší CVE-2026-115560 v pravidelném cyklu vydávání a ohlásil, že úplné advisory zveřejní s dalším vydáním. Do té doby platí jako náprava `session.upload_progress.enabled=0`.
2. **Podrobnosti byly veřejné brzy.** Podle několika zpráv se podrobnosti staly známými před koncem embarga. Podle zpráv watchTowr podle vlastních údajů CVE-2026-109618 zreprodukoval. Takové práce často vedou k navazujícím otázkám na sousedních místech kódu.
3. **Distribuce dodávají postupně.** Ubuntu 21. října zásobilo aktuální vydání pomocí USN-8948-1 a pomocí USN-8948-2 dodatečně dodalo opravy pro 14.04 až 20.04 přes Ubuntu Pro. Red Hat ve svém bulletinu napsal, že některé aktualizace jsou k dispozici, další jsou rozpracovány.
4. **Vývojová verze je postižena.** Podle php.net obsahuje opravy i PHP 8.6.0 RC4. Kdo testuje předběžné verze, musí dotáhnout i tato prostředí.
5. **Staré verze zůstávají otevřené.** Pro PHP 8.1 a starší existují jen minimální zdrojové backporty. Každý poskytovatel, který takové verze dodává, hlásí svůj stav samostatně a v době, kterou si určí sám.

## Jak se k vám nová bezpečnostní zranitelnost PHP dostane

Oznámení přicházejí různými cestami a s různou spolehlivostí. Pořadí je téměř vždy stejné: nejprve projekt PHP, pak distribuce a poskytovatelé hostingu, poté úřady a média.

| Zdroj | Co se tam dozvíte | Jak spolehlivé |
|---|---|---|
| php.net | Postižené větve, opravené verze, přechodná opatření | primární zdroj |
| Ubuntu, Debian, Red Hat | Stavy balíčků pro každé vydání, čas dodání | primární zdroj pro váš systém |
| Poskytovatelé hostingu a panelů | Stav vlastních buildů PHP | závazné jen písemně |
| BSI, CERT-Bund | Posouzení situace, výstražný stupeň, doporučení | zařazení úřadu |
| Odborný tisk a bezpečnostní firmy | Pozorování útoků, čísla, souvislosti | užitečné, označovat jako zprávu |

Důležitý je rozdíl mezi „záplata existuje“ a „můj systém záplatu má“. První tvrzení stojí na php.net. To druhé musíte doložit u každého serveru sami.

> **Tip:**
> Odebírejte oznámení php.net a své distribuce přes RSS nebo e-mailovou konferenci a směrujte je do společné schránky nebo kanálu, který čte více než jedna osoba. Dovolená a nemoc jsou nejčastějšími důvody opožděných aktualizací.

## Co připravit před příštím oznámením

Zkušenost z PHP2Shell ukazuje, kde se ztrácí čas: při hledání serverů, při vyjasňování odpovědností a při zapomenutém restartu. To všechno lze vyřídit předem.

- **Inventář:** Seznam všech serverů a webů s větví PHP, provozním režimem (PHP-FPM, mod_php, LiteSpeed) a zdrojem balíčků. Bez tohoto seznamu každé oznámení začíná hledáním. Jak se to daří, popisuje článek [Inventář všech webů a serverů](https://phpsos.de/cs/blog/inventar-websites-server/).
- **Odpovědnost:** U každého systému je stanoveno, kdo záplatuje, kdo restartuje a kdo schvaluje. U poskytovatelů hostingu a agentur to patří do smlouvy.
- **Raster hodnocení:** Pro první zařazení stačí tři otázky. Je naše větev postižena? Používáme dotčenou funkci nebo provozní režim? Existuje záplata, nebo jen přechodná opatření?
- **Testovací cesta:** Staging prostředí, ve kterém lze aktualizaci PHP ověřit v krátké době.
- **Doklad:** Pevný formát, ve kterém se zaznamená stav balíčku, nález v changelogu a čas restartu.

Jak takový postup funguje jako rutina místo hasičského zásahu, stojí na stránce [Správa záplat jako proces](https://phpsos.de/cs/blog/patch-management-prozess/). Souvislosti k tomu, jak projekt PHP se zranitelnostmi nakládá, nabízí stránka [Jak projekt PHP zachází s bezpečnostními zranitelnostmi](https://phpsos.de/cs/php/php-sicherheitsprozess/).

## Vlastní konfigurace jako systém včasného varování

Část navazujících oznámení se týká jen určitých nastavení. CVE-2026-115560 je toho příkladem: php.net uvádí jako podmínku, že aplikace za běhu přepne serializer session, zatímco je aktivní upload progress. Aplikace, které to nikdy nedělají, nejsou podle php.net postiženy.

Kdo zná svou účinnou konfiguraci, dokáže taková oznámení rychleji zařadit. Zaznamenejte proto pro každou větev, které hodnoty jsou nastaveny na straně serveru a které aplikace je smějí přepsat. Pomůže už jednoduché porovnání aktivních nastavení:

```bash
# Účinné hodnoty příkazové řádky (webová konfigurace se může lišit)
php -i | grep -E "session.upload_progress.enabled|session.serialize_handler|memory_limit|post_max_size"

# Nastavené hodnoty v poolech FPM (cesta se u distribucí liší)
grep -RhE "php_(admin_)?value" /etc/php/*/fpm/pool.d/ 2>/dev/null
```

Příkazová řádka nemusí ukazovat, co platí ve webovém kontextu. Jasno udělá konfigurace poolu nebo VirtualHostu a, krátkodobě a chráněně, stránka phpinfo.

Další výhoda: Kdo ví, které přechodné hodnoty z týdne PHP2Shell jsou ještě nastaveny, může je po dalším pravidelném vydání vědomě zkontrolovat. Některá nastavení, například vypnutý upload progress, mohou trvale zůstat smysluplná. Jiná, jako velmi těsné limity nahrávání, byste po dohodě s odbornými odděleními měli opět přizpůsobit skutečné potřebě.

## Jak konkrétně pomáhá PHP SOS?

- Sledujeme oznámení php.net, distribucí a BSI a nová upozornění vyhodnocujeme pro vaše konkrétní systémy.
- S vámi sestavujeme inventář všech instalací PHP a stanovujeme odpovědnosti pro každý server.
- V rámci [bezpečnostní servisní smlouvy](https://phpsos.de/cs/leistungen/security-wartungsvertrag/) nasazujeme aktualizace, restartujeme všechny procesy a dokumentujeme stav.
- U oznámení bez záplaty nastavujeme přechodná opatření tak, aby je nešlo přepsat, a následně je kontrolujeme.


## Časté dotazy

**Existuje po PHP2Shell už nová bezpečnostní zranitelnost PHP?**  
Dne 23. října 2026 zveřejnil php.net upozornění k CVE-2026-115560. Spuštění kódu je podle něj možné jen při neobvyklé konfiguraci session. Úplné advisory má následovat s dalším pravidelným vydáním.

**Musím po každém novém oznámení okamžitě jednat?**  
Ne každé oznámení vyžaduje stejný spěch. Rozhodující jsou závažnost, dotčenost vaší konfigurace a otázka, zda je k dispozici záplata. Pevně stanovený postup pomáhá to vyhodnotit v minutách místo v dnech.

**Kde se o nových zranitelnostech PHP dozvím první?**  
Primárními zdroji jsou oznámení na php.net a bezpečnostní upozornění vaší distribuce, například Ubuntu Security Notices, Debian Security Tracker nebo Red Hat. BSI (německý Spolkový úřad pro informační bezpečnost) informuje prostřednictvím varování. Mediální zprávy jsou užitečné, ale často pozdější a méně přesné.

**Proč distribuce někdy hlásí o dny později než php.net?**  
Distribuce musí opravu převzít do svých vlastních balíčků, sestavit je a otestovat. U starších vydání to může trvat déle nebo jít jen přes doplňkové nabídky. Proto se vyplatí sledovat oba zdroje odděleně.

## Zdroje

- [php.net: oznámení a bezpečnostní upozornění](https://www.php.net/)
- [Ubuntu Security Notice USN-8948-2](https://ubuntu.com/security/notices/USN-8948-2)
- [Red Hat: CVE-2026-109618](https://access.redhat.com/security/cve/CVE-2026-109618)
- [BSI](https://www.bsi.bund.de/)
