# Nebezpečné falešné rady k PHP2Shell, které právě kolují

> Rady k PHP2Shell v kontrole faktů: které kolující rady nechrání nebo dokonce škodí a co místo nich doporučují php.net, BSI a odborní autoři.

Zdroj: https://phpsos.de/cs/blog/gefaehrliche-falschtipps/  
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ě:** Mnoho rad k PHP2Shell, které právě kolují na fórech a sociálních sítích, nechrání nebo dokonce škodí: blokovat požadavky se session cookie, skrývat chybová hlášení, nastavovat hodnoty přes `.user.ini` nebo aktualizovat jen CMS. php.net je jednoznačný: Úplná přechodná opatření neexistují, aktualizace PHP s restartem všech procesů je jedinou bezpečnou cestou.

## Proč jsou falešné rady v této situaci nebezpečné

U kritické zranitelnosti s velkou pozorností vzniká trh s rychlými řešeními. Rady se sdílejí, zkracují a předávají dál, často bez omezení původního zdroje. U PHP2Shell k tomu přistupuje, že se podle zpráv podrobnosti staly známými už před oficiálním termínem a situace byla v prvních dnech nepřehledná.

Falešná rada škodí dvojnásob. Nechává zranitelnost otevřenou a vyvolává pocit, že se něco udělalo. Právě tento pocit způsobuje, že vlastní aktualizace zůstane ležet. Některé rady navíc ochromí vlastní web.

## Devět rad v kontrole faktů

Následující tabulka shrnuje, co jsme v posledních dnech často četli, a proti tomu klade tvrzení primárních zdrojů.

| Kolující rada | Proč neobstojí | Co platí místo toho |
|---|---|---|
| Blokovat všechny požadavky s `PHPSESSID` | Odborní autoři výslovně odmítají; ochromí přihlášení a nákupní košíky | aktualizovat PHP |
| `session.upload_progress.enabled=0` stačí | Podle odborných zpráv neuzavírá obě zranitelnosti | smysluplné přechodné opatření, aktualizace zůstává povinná |
| Hodnoty nastavovat přes `ini_set()` nebo `.user.ini` | php.net to výslovně nedoporučuje | na straně serveru v php.ini, poolu FPM nebo konfiguraci serveru |
| Skrývat chybová hlášení | Podle php.net nepomáhají `error_reporting`, `display_errors` ani `@` | aktualizace; výstup chyb přesto veřejně neukazovat |
| Omezit paměť přes `RLIMIT_AS` nebo `RLIMIT_DATA` | php.net varuje, že právě to může vyvolat zranitelnou situaci | limit přes kontejner nebo cgroup |
| Aktualizovat WordPress nebo pluginy | Zranitelnost je v interpretu PHP, ne v CMS | aktualizovat běhové prostředí PHP |
| Stačí Cloudflare nebo jiný WAF | Ochrana jen pro provoz přes službu; přímo dostupné servery zůstávají otevřené | WAF jako dodatečná vrstva, ne jako náhrada |
| Službu znovu načíst místo restartovat | Podle Red Hat reload nestačí, stávající workery si mohou ponechat starý stav | všechny workery kompletně restartovat |
| Záplatováno znamená čisté | Záplata neodstraní dříve vložený škodlivý software | zajistit logy od 20. 10. a hledat stopy |

## Tři nejčastější omyly podrobněji

### Zákaz cookies

Rada odmítat všechny požadavky se session cookie `PHPSESSID` zní technicky a rozhodně. Odborní autoři ji výslovně odmítají. V praxi rozbije všechno, co potřebuje relaci: zákaznické účty, nákupní košíky, administrátorské sekce, formuláře s ochranou proti padělání. Ochranou proti zranitelnosti není.

### Jedno nastavení, které vyřeší všechno

`session.upload_progress.enabled=0` stojí v doporučeních php.net a je uvedenou nápravou pro CVE-2026-115560. V některých příspěvcích se z toho stalo „PHP2Shell vypnuto“. Podle odborných zpráv však toto nastavení samo o sobě neuzavírá obě zranitelnosti. Ani `memory_limit=-1` podle php.net neodstraní nic víc než ovladatelnou spouštěcí podmínku; chyba paměti na hlubší úrovni může zranitelnou cestu stále dosáhnout. U PHP 8.5 blokuje `fatal_error_backtraces=0` podle php.net jen potvrzenou cestu přes backtraces.

Jak nastavení přesto správně a trvale provést, popisuje článek [Vypnutí session.upload_progress](https://phpsos.de/cs/blog/session-upload-progress-abschalten/). Úplný seznam přechodných opatření stojí na stránce [Okamžitá opatření bez záplaty](https://phpsos.de/cs/php2shell/sofortmassnahmen-ohne-patch/).

### Ochranný štít před dveřmi

Cloudflare má podle vlastních údajů od 21. října aktivní ochranná pravidla, i pro zákazníky v bezplatném tarifu. Cloudflare sám ale upozorňuje na hranice: Ochrana působí jen na provoz, který prochází přes Cloudflare. Pokud je origin server dostupný přímo, je obejita. Cloudflare navíc kontroluje i odpověď serveru, protože samotný požadavek ne vždy stačí. Proč WAF aktualizaci nenahrazuje, vysvětluje článek [WAF, nebo aktualizace](https://phpsos.de/cs/blog/waf-oder-update/).

## Rada s rizikem: filtrovat požadavky na nahrávání na okraji

Ne každá nepohodlná rada je chybná. Odborní autoři navrhují jako dočasné, neoficiální opatření blokovat požadavky `multipart/form-data` mimo skutečné cesty nahrávání na proxy nebo ve WAF. Může to zmenšit plochu pro útok, ale rozbije formuláře a nahrávání, pokud je seznam povolených cest neúplný.

Kdo touto cestou jde, měl by ji předem vyzkoušet v testovacím prostředí, dohodnout s odbornými odděleními a zdokumentovat jako dočasné opatření. Ani ona aktualizaci nenahrazuje.

Mnoho řešení WAF nabízí pozorovací režim, ve kterém pravidla zprvu jen protokolují místo blokování. Nechte nové pravidlo několik dní takto běžet a vyhodnoťte, které legitimní požadavky by byly dotčeny. Teprve poté přepněte na blokování. Tak předejdete tomu, aby formuláře pro uchazeče, zákaznické portály nebo nahrávání obrázků v obchodě nepozorovaně přestaly fungovat.

## Jak radu ověřit, než ji uplatníte

Čtyři otázky oddělují použitelné rady od nebezpečných:

1. **Zdroj:** Pochází doporučení z php.net, od vaší distribuce, BSI nebo od jmenovaného odborného autora?
2. **Nárok:** Je opatření popsáno jako přechod, nebo jako řešení? U PHP2Shell je řešením jen aktualizace.
3. **Vedlejší účinek:** Co se rozbije, když opatření zabere? Rada bez upozornění na vedlejší účinky je neúplná.
4. **Místo provedení:** Nastavuje se na straně serveru způsobem, který nelze přepsat, s následným restartem všech workerů?

> **Důležité:**
> Zaznamenejte si, která přechodná opatření jste kdy nastavili. Tak je můžete později cíleně zkontrolovat a poznat, zda domnělá ochrana nezdržela skutečnou aktualizaci.

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

- Kontrolujeme opatření, která u vás již byla provedena, a oddělujeme účinná od neúčinných.
- Nasazujeme aktualizaci PHP, restartujeme všechny procesy a doložíme stav.
- Kde aktualizace ještě není možná, nastavujeme přechodná opatření podle php.net na straně serveru a zdokumentovaně.
- Pomocí [WAF a virtuálního záplatování](https://phpsos.de/cs/leistungen/waf-virtuelles-patching/) doplňujeme ochranu na okraji, aniž bychom nahradili aktualizaci.


## Časté dotazy

**Chrání blokování požadavků s PHPSESSID?**  
Ne. Odborní autoři tuto kolující radu výslovně odmítají. Ochromí přihlášení, nákupní košíky a formuláře, aniž by uzavřela zranitelnost v interpretu.

**Stačí session.upload_progress.enabled=0 proti PHP2Shell?**  
Ne. Nastavení je jedním z několika přechodných opatření a podle odborných zpráv neuzavírá obě zranitelnosti. Je smysluplné, ale aktualizaci PHP nenahrazuje.

**Pomůže vypnout display_errors?**  
Pro PHP2Shell ne. php.net upozorňuje, že skrývání diagnostiky přes error_reporting, display_errors nebo operátor @ nepomáhá. V produkci by display_errors přesto mělo být vypnuto z jiných důvodů.

**Podle čeho poznám seriózní radu?**  
Seriózní rada uvádí svůj zdroj, popisuje hranice a označuje přechodná opatření jako taková. Kdo slibuje, že jediné nastavení činí aktualizaci zbytečnou, se u PHP2Shell mýlí.

## Zdroje

- [php.net: bezpečnostní oznámení](https://www.php.net/)
- [Red Hat: CVE-2026-109618](https://access.redhat.com/security/cve/CVE-2026-109618)
- [Dr. Web: PHP2Shell und PHP-Versionen](https://www.drweb.de/php2shell-update-php-versionen/)
- [Cloudflare-Blog](https://blog.cloudflare.com/)