Jak bezpečně nakonfigurovat php.ini

Stručně: Pro bezpečnost php.ini jsou rozhodující hlavně čtyři oblasti: žádné chybové hlášky navenek, bezpečné cookies session, omezené uploady a zamčené hodnoty, které aplikace nemohou přepsat. Po PHP2Shell přibývají přechodná opatření php.net, především session.upload_progress.enabled=0. Bezpečná konfigurace ale nikdy nenahradí aktualizaci.

Proč je php.ini po PHP2Shell opět v centru pozornosti

Soubor php.ini je ústřední konfigurační soubor PHP. Na mnoha serverech byl jednou nastaven a poté téměř nikdo nesáhl. S PHP2Shell se to změnilo: pro obě zranitelnosti CVE-2026-109618 a CVE-2026-109619 uvádí php.net přechodná opatření, která míří právě sem.

Samotné zranitelnosti sídlí v interpretu PHP. Opraveny jsou v PHP 8.5.12, 8.4.27, 8.3.36 a 8.2.35, vydaných 21. 10. 2026. Dobrá konfigurace přesto pomáhá dvěma způsoby: může zneužití ztížit a omezí škodu, pokud by něco přece jen proniklo.

Mnoho provozovatelů navíc přesně neví, která nastavení na jejich serveru platí. To je první krok.

Která php.ini platí na vašem serveru?

PHP může podle provozního režimu číst různé konfigurační soubory. Příkazová řádka, PHP-FPM a Apache s mod_php mají například v Debianu a Ubuntu každé vlastní složky pod /etc/php/<version>/. Kdo změní jen soubor CLI, na webu nezmění nic.

# Konfigurační soubory příkazové řádky
php --ini
# Konfigurace PHP-FPM (upravte číslo verze)
php-fpm8.3 -i | grep -E "Loaded Configuration|Scan this dir"
# Kontrola jednotlivých hodnot PHP-FPM
php-fpm8.3 -i | grep -E "^(expose_php|display_errors|session.upload_progress.enabled) "

Hodnoty navíc mohou být v poolu FPM, v konfiguraci Apache, v .htaccess (jen mod_php) nebo v .user.ini (FPM a CGI). Jaká verze na serveru skutečně běží a zda je zahrnut backport, vyjasňuje článek Jak správně ověřit verzi PHP a stav záplaty.

Základní nastavení pro vyšší bezpečnost php.ini

Následující hodnoty dávají na většině produkčních serverů smysl. Před nasazením v testovacím prostředí ověřte, zda vaše aplikace se všemi hodnotami funguje.

; Žádný údaj o verzi v hlavičce HTTP
expose_php = Off

; Chyby zaznamenávat, ale nikdy nezobrazovat v prohlížeči
display_errors = Off
display_startup_errors = Off
log_errors = On
error_log = /var/log/php/error.log

; Nevkládat soubory ze vzdálených adres
allow_url_include = Off
; allow_url_fopen nechat zapnuté jen tehdy, když ho aplikace potřebuje
allow_url_fopen = Off

; Session: přísně, jen přes HTTPS, nečitelné pro JavaScript
session.use_strict_mode = 1
session.use_only_cookies = 1
session.cookie_secure = 1
session.cookie_httponly = 1
session.cookie_samesite = Lax

; Omezit dobu běhu a vstupy
max_execution_time = 30
max_input_time = 60
max_input_vars = 1000

allow_url_fopen potřebují některé aplikace pro aktualizace nebo rozhraní. Vypněte ho jen tehdy, pokud jste to předem ověřili. Funkce, které provádějí systémové příkazy, lze navíc zakázat; jak to zvládnout bez vedlejších účinků, vysvětluje příručka Jak správně použít disable_functions.

Přechodná opatření php.net k PHP2Shell

Pokud nemůžete záplatovat ihned, uvádí php.net několik nastavení, která riziko snižují. Výslovně nejsou úplnou ochranou, ale mostem do doby aktualizace.

; Vypnout session upload progress (i kvůli CVE-2026-115560)
session.upload_progress.enabled = 0

; Omezit velikost požadavku: 8M bez uploadů, 32M s uploady
post_max_size = 8M
upload_max_filesize = 6M

; Jen PHP 8.5: žádné backtrace při závažných chybách
fatal_error_backtraces = 0

Navíc php.net doporučuje nastavit memory_limit=-1 tak, aby aplikace tuto hodnotu nemohly přepsat, a hranici paměti stanovit raději přes kontejner nebo cgroup, nikoli přes RLIMIT_AS nebo RLIMIT_DATA. Toto opatření patří do poolu FPM nebo konfigurace serveru a mělo by se kombinovat s fungující hranicí cgroup. Úplný přehled najdete v článku Okamžitá opatření, když ještě nemůžete záplatovat.

Zamknout hodnoty proti přepsání

Mnoho aplikací nastavuje vlastní hodnoty, například pro paměť nebo uploady. Pomocí php_admin_value a php_admin_flag nastavení zafixujete tak, že je nemůže změnit ani ini_set(), ani .user.ini. V poolu FPM to vypadá takto:

; /etc/php/8.3/fpm/pool.d/meine-seite.conf (výňatek)
php_admin_flag[display_errors] = off
php_admin_flag[session.upload_progress.enabled] = off
php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 8M
php_admin_value[upload_max_filesize] = 6M
php_admin_value[error_log] = /var/log/php/meine-seite.error.log

U Apache s mod_php platí stejná logika s php_admin_value a php_admin_flag v konfiguraci VirtualHost. Poté službu znovu načtěte a aktivní hodnotu ověřte:

sudo systemctl reload php8.3-fpm
# Čas spuštění procesů: je po provedené změně?
ps -eo pid,lstart,cmd | grep "[p]hp-fpm"

Reload restartuje workery PHP-FPM. Po aktualizaci PHP je naproti tomu nutný úplný restart všech procesů PHP, aby v paměti nadále neběžel starý proces. Při více webech na jednom serveru se navíc vyplatí samostatný pool pro každý web, více v příručce open_basedir a izolace jednotlivých webů.

Časté chyby a krátký kontrolní seznam

Většina problémů s php.ini nevzniká špatnými hodnotami, ale hodnotami na špatném místě. Typické je změněné CLI, zatímco web běží přes PHP-FPM. Stejně často po změně chybí restart, nebo hostingový panel při dalším uložení přepíše vlastní nastavení.

Druhým klasickým problémem jsou viditelné chybové hlášky na živém webu. Prozrazují cesty, názvy databází nebo verze a usnadňují útočníkům orientaci. Právě po přestěhování nebo nové instalaci je display_errors často znovu nastaveno na On.

Tyto body byste měli zkontrolovat po každé změně a po každé aktualizaci PHP:

1. Který konfigurační soubor čte webový provozní režim a obsahuje vaše hodnoty?
2. Jsou display_errors a expose_php vypnuty a je chybový log zapisovatelný?
3. Je session.upload_progress.enabled nastaveno na 0 přes php.ini nebo pool?
4. Jsou velikosti uploadů a požadavků omezeny podle aplikace?
5. Běží všechny procesy PHP s časem spuštění po poslední změně?

Výsledek si poznamenejte s datem. Později tak lze doložit, kdy které nastavení platilo.

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

• Zjistíme, jaká konfigurace je v jakém provozním režimu skutečně aktivní.
• Nasadíme sladěnou základní konfiguraci a přechodná opatření k PHP2Shell, otestovaná s vaší aplikací.
• Bezpečnostně důležité hodnoty zamkneme proti přepsání a řízeně restartujeme všechny workery.
• Nastavení a výsledek kontroly zdokumentujeme, aby pozdější změny zůstaly dohledatelné.

Jak vypadá trvalé zabezpečení, popisuje služba Zabezpečení serveru pro webové servery PHP.

Časté dotazy

Zdroje

• php.net: bezpečnostní oznámení
• PHP 8 ChangeLog
• OWASP Cheat Sheet Series
• BSI IT-Grundschutz