Stručně: Chcete-li v changelogu zkontrolovat CVE, prohledejte protokol změn nainstalovaného balíčku PHP na CVE-2026-109618 a CVE-2026-109619: u Debianu a Ubuntu v /usr/share/doc/<paket>/changelog.Debian.gz, na systémech RPM příkazem rpm -q --changelog. Nález spolu se stavem balíčku, porovnáním s oficiálním bezpečnostním oznámením a časem restartu tvoří důvěryhodný důkaz. Chybějící nález ještě není důkazem otevřené zranitelnosti.
Proč je důkaz víc než „zaplatovali jsme“
Po PHP2Shell chce mnoho lidí vědět, zda jsou jejich servery bezpečné: vedení firmy, pověřenec pro ochranu osobních údajů, zákazníci se zpracováním na základě smlouvy, někdy kyberpojišťovna. „Zaplatovali jsme“ je k tomu málo. Požaduje se doklad, který může třetí strana ověřit.
Číslo verze se k tomu často nehodí, protože distribuce zavádějí opravy jako backport a číslo zůstává stejné. Lepším podkladem je changelog balíčku. Píše ho správce balíčku a u bezpečnostních aktualizací v něm zpravidla vyjmenovává opravená čísla CVE.
Kde changelogy leží
Každý formát balíčků má své místo. Následující přehled pomůže rychle najít to správné.
| Systém | Umístění changelogu | Příkaz pro hledání |
|---|---|---|
| Debian, Ubuntu | /usr/share/doc/<paket>/changelog.Debian.gz |
zgrep |
| Debian, Ubuntu (online) | archiv balíčků distribuce | apt changelog <paket> |
| RHEL, AlmaLinux, Rocky, Fedora | databáze balíčků RPM | rpm -q --changelog <paket> |
| Image kontejnerů | v image, stejně jako u základního systému | spustit příkaz v kontejneru |
U Debianu a Ubuntu odkazuje adresář s dokumentací některých binárních balíčků symbolickým odkazem na společný balíček, například php8.3-common. Pokud zgrep soubor nenajde, prohlédněte si adresář příkazem ls -l /usr/share/doc/ | grep php.
Kontrola CVE v changelogu: postup
Následující příkazy jsou čistě čtecí. Názvy balíčků upravte podle své instalace.
# Debian/Ubuntu: lokálně, bez sítě
zgrep -n -E "CVE-2026-10961[89]|CVE-2026-115560" /usr/share/doc/php8.3-common/changelog.Debian.gz
# Debian/Ubuntu: úvodní řádek nejnovějšího záznamu se stavem balíčku a datem
zcat /usr/share/doc/php8.3-common/changelog.Debian.gz | head -20
# Rodina RHEL: záznam včetně data a stavu balíčku
rpm -q --changelog php-common | grep -n -B3 -E "CVE-2026-10961[89]"
U Debianu a Ubuntu je stav balíčku v úvodním řádku každého záznamu, datum v závěrečném řádku. U RPM je obojí v řádku nad záznamy. Uvidíte tak nejen to, zda je CVE zmíněno, ale i s jakým stavem balíčku. Tento stav porovnejte s nainstalovaným, například pomocí dpkg-query -W nebo rpm -q. Pokud se shodují, je oprava v běžícím balíčku obsažena.
Balíčky panelů a kontejnery
Hostingové panely, například Plesk nebo cPanel, přinášejí vlastní balíčky PHP. I ty jsou běžnými balíčky DEB nebo RPM a jejich changelog lze číst stejnými nástroji. Zda v něm poskytovatelé uvádějí čísla CVE, nebo jen novou verzi PHP, se liší. Pokud balíček uvádí upstreamovou verzi 8.5.12, 8.4.27, 8.3.36 nebo 8.2.35, stačí to jako doklad; u backportů se starým číslem potřebujete vyjádření poskytovatele.
U kontejnerů patří důkaz k image, ne k hostiteli. Zkontrolujte balíčky v image, ze kterého byl běžící kontejner spuštěn, a navíc si poznamenejte digest image. Pozdější dohledání pak ukáže, jaký stav skutečně běžel, i když byl image pod stejným tagem mezitím sestaven znovu.
Když CVE v changelogu chybí
Chybějící záznam může mít několik příčin. Projděte je v tomto pořadí:
- Prohledán špatný balíček: U více větví PHP nebo zdrojů na jednom serveru bývá odpověď často v changelogu jiného balíčku.
- Verze upstreamu místo CVE: Pokud zdroj dodává novou verzi upstreamu, například 8.4.27, může v changelogu stát jen „New upstream version“. Pak je důkazem samotné číslo verze, protože php.net uvádí jako opravené verze 8.5.12, 8.4.27, 8.3.36 a 8.2.35.
- Jiná formulace: Někteří správci uvádějí místo CVE čísla chyb nebo označení advisory, například GHSA-w8hw-w9fx-j79w a GHSA-6wmf-4rv5-p3rp.
- Porovnání s bezpečnostním oznámením: Uvádí-li oficiální oznámení vaší distribuce, například USN nebo Debian Security Tracker, opravený stav balíčku a je nainstalován tento nebo novější, je to rovněž doklad. Stavy pro Debian a Ubuntu najdete v článku Je můj balíček PHP zaplatovaný?, pro rodinu RHEL v článku RHEL, AlmaLinux a Rocky Linux.
- Zeptat se poskytovatele: U balíčků panelů, buildů hostera nebo zdrojů třetích stran pomůže jen písemné vyjádření. Vzor nabízí průvodce Zeptejte se hostera na stav záplat.
Pokud po těchto krocích žádný doklad nezbývá, považujte server za nezaplatovaný a do vyjasnění použijte přechodná opatření.
Od nálezu k důkazu
Nález v changelogu dokládá, že balíček opravu obsahuje. Nedokládá, že ji používají běžící procesy. Úplný důkaz proto obsahuje pět údajů pro každý server a instalaci PHP:
- server, větev PHP a provozní režim, například PHP-FPM nebo mod_php
- nainstalovaný stav balíčku a zdroj balíčku
- místo nálezu v changelogu nebo odkaz na oficiální bezpečnostní oznámení
- čas aktualizace a čas spuštění běžících procesů PHP
- jméno kontrolující osoby a datum kontroly
Uložte si surové výstupy příkazů jako textový soubor vedle důkazu. Později se s nimi pracuje snáze než se shrnutím z paměti.
Důkaz odpovídá jen na otázku, zda byla zranitelnost od určitého okamžiku uzavřena. Pro dobu před tím potřebujete logy od 20. října 2026 a případně pátrání po stopách. Obecný postup kontroly verze popisuje stránka Správná kontrola verze PHP a stavu záplat.
Jak konkrétně pomáhá PHP SOS?
- Prohledáváme changelogy všech balíčků PHP na vašich serverech a porovnáváme je s oficiálními bezpečnostními oznámeními.
- Tam, kde changelogy mlčí, vyjasňujeme stav s distribucí, poskytovatelem panelu nebo hosterem.
- Kontrolujeme, zda byly běžící procesy po aktualizaci restartovány.
- S PHP Patch Service získáte důkaz pro každý server ve formě, kterou můžete předat třetím stranám.
Časté dotazy
Proč číslo verze PHP jako důkaz nestačí?
Mnoho distribucí přebírá bezpečnostní opravy formou backportu, aniž by se změnila verze PHP. Číslo verze pak o záplatě nic neříká. Changelog nainstalovaného balíčku naproti tomu uvádí opravená čísla CVE.
Co znamená, když CVE v changelogu chybí?
Může to znamenat, že oprava chybí. Může se ale také stát, že správce balíčku formuluje jinak, například číslem chyby nebo verzí upstreamu. Pak porovnáte stav balíčku s oficiálním bezpečnostním oznámením nebo se zeptáte poskytovatele.
Jak dlouho mám důkaz uchovávat?
Dokud může být relevantní pro interní kontroly, pojišťovny nebo případné dotazy k ochraně osobních údajů. Uložte ho společně s logy od 20. října 2026. Konkrétní lhůty si ujasněte s pověřencem pro ochranu osobních údajů nebo právním poradcem.
Mohu changelog zkontrolovat i bez přístupu k internetu?
Ano. Debian a Ubuntu ukládají changelog každého balíčku lokálně v /usr/share/doc, systémy RPM ho mají v databázi balíčků. Obojí lze číst bez sítě.