# Doložení čísel CVE v changelogu balíčku > Kontrola CVE v changelogu a doložení záplaty PHP: kde changelogy leží, jak v nich hledat, co znamená chybějící záznam a jak vypadá důkaz. Zdroj: https://phpsos.de/cs/blog/cve-im-changelog-nachweisen/ 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ě:** 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//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//changelog.Debian.gz` | `zgrep` | | Debian, Ubuntu (online) | archiv balíčků distribuce | `apt changelog ` | | RHEL, AlmaLinux, Rocky, Fedora | databáze balíčků RPM | `rpm -q --changelog ` | | 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. ```bash # 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í: 1. **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. 2. **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. 3. **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. 4. **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ý?](https://phpsos.de/cs/blog/debian-ubuntu-paket-gepatcht/), pro rodinu RHEL v článku [RHEL, AlmaLinux a Rocky Linux](https://phpsos.de/cs/blog/rhel-almalinux-rocky-php/). 5. **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](https://phpsos.de/cs/ratgeber/hoster-patch-status-erfragen/). 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 > **Tip:** > 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](https://phpsos.de/cs/php2shell/php-version-pruefen/). ## 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](https://phpsos.de/cs/leistungen/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ě. ## Zdroje - [Debian Security Tracker](https://security-tracker.debian.org/) - [Ubuntu Security Notices](https://ubuntu.com/security/notices) - [Red Hat Customer Portal](https://access.redhat.com/) - [php.net: bezpečnostní oznámení](https://www.php.net/)