Kort gezegd: Om in de changelog een CVE te controleren, doorzoekt u het wijzigingsprotocol van het geïnstalleerde PHP-pakket op CVE-2026-109618 en CVE-2026-109619: onder Debian en Ubuntu in /usr/share/doc/<paket>/changelog.Debian.gz, op RPM-systemen met rpm -q --changelog. Een treffer, samen met de pakketstand, de vergelijking met de officiële beveiligingsmelding en het tijdstip van de herstart, levert een deugdelijk bewijs op. Een ontbrekende treffer is nog geen bewijs van een openstaand lek.
Waarom een bewijs meer is dan "wij hebben gepatcht"
Na PHP2Shell willen velen weten of hun servers veilig zijn: de directie, de functionaris voor gegevensbescherming, klanten met een verwerkersovereenkomst, soms de cyberverzekeraar. "Wij hebben gepatcht" is daarvoor te weinig. Gevraagd wordt een bewijs dat een derde kan nagaan.
Het versienummer is hiervoor vaak ongeschikt, omdat distributies correcties als backport inspelen en het nummer gelijk blijft. De pakket-changelog is de betere basis. Hij wordt geschreven door de pakketbeheerder en vermeldt bij beveiligingsupdates in de regel de verholpen CVE-nummers.
Waar de changelogs staan
Elk pakketformaat heeft zijn eigen plek. Het onderstaande overzicht helpt u snel op de juiste plaats te komen.
| Systeem | Plaats van de changelog | Opdracht om te doorzoeken |
|---|---|---|
| Debian, Ubuntu | /usr/share/doc/<paket>/changelog.Debian.gz |
zgrep |
| Debian, Ubuntu (online) | Pakketarchief van de distributie | apt changelog <paket> |
| RHEL, AlmaLinux, Rocky, Fedora | RPM-pakketdatabase | rpm -q --changelog <paket> |
| Container-images | in de image, zoals bij het basissysteem | Opdracht in de container uitvoeren |
Onder Debian en Ubuntu verwijst de documentatiemap van sommige binaire pakketten via een symbolische link naar een gedeeld pakket, bijvoorbeeld php8.3-common. Vindt zgrep het bestand niet, bekijk dan de map met ls -l /usr/share/doc/ | grep php.
Changelog CVE controleren: zo gaat u te werk
De onderstaande opdrachten zijn uitsluitend lezend. Pas de pakketnamen aan uw installatie aan.
# Debian/Ubuntu: lokaal, zonder netwerk
zgrep -n -E "CVE-2026-10961[89]|CVE-2026-115560" /usr/share/doc/php8.3-common/changelog.Debian.gz
# Debian/Ubuntu: kopregel van de nieuwste vermelding met pakketstand en datum
zcat /usr/share/doc/php8.3-common/changelog.Debian.gz | head -20
# RHEL-familie: vermelding met datum en pakketstand
rpm -q --changelog php-common | grep -n -B3 -E "CVE-2026-10961[89]"
Bij Debian en Ubuntu staat de pakketstand in de kopregel van elke vermelding, de datum in de slotregel. Bij RPM staan beide in de regel boven de vermeldingen. Zo ziet u niet alleen of de CVE genoemd wordt, maar ook bij welke pakketstand. Vergelijk die stand met de geïnstalleerde, bijvoorbeeld via dpkg-query -W of rpm -q. Komen beide overeen, dan zit de correctie in het draaiende pakket.
Paneelpakketten en containers
Hostingpanelen brengen eigen PHP-pakketten mee, zoals Plesk of cPanel. Ook dit zijn gewone DEB- of RPM-pakketten, hun changelog is met dezelfde hulpmiddelen te lezen. Of de aanbieders daarin CVE-nummers noemen of alleen de nieuwe PHP-versie, verschilt. Noemt het pakket de upstreamversie 8.5.12, 8.4.27, 8.3.36 of 8.2.35, dan volstaat dat als bewijs; bij backports met een oud nummer hebt u de opgave van de aanbieder nodig.
Bij containers hoort het bewijs bij de image, niet bij de host. Controleer de pakketten in de image waaruit de draaiende container is gestart, en leg bovendien de image-digest vast. Zo is later na te gaan welke stand er werkelijk draaide, ook als de image onder dezelfde tag inmiddels opnieuw is gebouwd.
Als de CVE in de changelog ontbreekt
Een ontbrekende vermelding kan meerdere oorzaken hebben. Loop ze in deze volgorde na:
- Verkeerd pakket doorzocht: Bij meerdere PHP-takken of bronnen op één server staat het antwoord vaak in de changelog van een ander pakket.
- Upstreamversie in plaats van CVE: Levert de bron de nieuwe upstreamversie uit, bijvoorbeeld 8.4.27, dan staat er in de changelog mogelijk alleen "New upstream version". Dan is het versienummer zelf het bewijs, omdat php.net de versies 8.5.12, 8.4.27, 8.3.36 en 8.2.35 als gecorrigeerd noemt.
- Andere formulering: Sommige beheerders noemen bugnummers of advisory-kenmerken zoals GHSA-w8hw-w9fx-j79w en GHSA-6wmf-4rv5-p3rp in plaats van de CVE.
- Vergelijking met de beveiligingsmelding: Noemt de officiële melding van uw distributie, bijvoorbeeld een USN of de Debian Security Tracker, een gecorrigeerde pakketstand, en is die of een nieuwere geïnstalleerd, dan is ook dat een bewijs. Voor Debian en Ubuntu vindt u de standen in het artikel Is mijn PHP-pakket gepatcht?, voor de RHEL-familie onder RHEL, AlmaLinux en Rocky Linux.
- De aanbieder vragen: Bij paneelpakketten, hosterbuilds of bronnen van derden helpt alleen een schriftelijke opgave. Een sjabloon vindt u in de gids De hoster naar de patchstatus vragen.
Blijft er na deze stappen geen bewijs over, behandel de server dan als ongepatcht en neem overbruggingsmaatregelen totdat de vraag is opgehelderd.
Van treffer naar bewijs
Een treffer in de changelog bewijst dat het pakket de correctie bevat. Hij bewijst niet dat de draaiende processen haar gebruiken. Een volledig bewijs bevat daarom vijf gegevens per server en PHP-installatie:
- server, PHP-tak en bedrijfsmodus, bijvoorbeeld PHP-FPM of mod_php
- geïnstalleerde pakketstand en pakketbron
- vindplaats in de changelog of verwijzing naar de officiële beveiligingsmelding
- tijdstip van de update en starttijd van de draaiende PHP-processen
- naam van de controlerende persoon en datum van de controle
Sla de ruwe uitvoer van de opdrachten op als tekstbestand naast het bewijs. Die is later gemakkelijker na te gaan dan een samenvatting uit het geheugen.
Een bewijs beantwoordt alleen de vraag of het lek vanaf een bepaald moment gesloten was. Voor de tijd daarvoor hebt u de logs vanaf 20 oktober 2026 nodig en zo nodig een sporenonderzoek. De algemene werkwijze voor de versiecontrole beschrijft de pagina PHP-versie en patchstand correct controleren.
Hoe helpt PHP SOS concreet?
- Wij doorzoeken de changelogs van alle PHP-pakketten op uw servers en vergelijken ze met de officiële beveiligingsmeldingen.
- Waar changelogs zwijgen, stellen wij de stand vast met distributie, paneelaanbieder of hoster.
- Wij controleren dat de draaiende processen na de update opnieuw zijn gestart.
- Met de PHP-patchservice ontvangt u het bewijs per server in een vorm die u aan derden kunt doorgeven.
Veelgestelde vragen
Waarom volstaat de PHP-versie niet als bewijs?
Veel distributies nemen beveiligingscorrecties als backport over zonder het PHP-versienummer te wijzigen. Het versienummer zegt dan niets over de patch. De changelog van het geïnstalleerde pakket noemt daarentegen de verholpen CVE-nummers.
Wat betekent het als de CVE niet in de changelog staat?
Het kan betekenen dat de correctie ontbreekt. Het kan ook dat de pakketbeheerder het anders formuleert, bijvoorbeeld met een bugnummer of upstreamversie. Vergelijk dan de pakketstand met de officiële beveiligingsmelding of vraag het de leverancier.
Hoe lang moet ik het bewijs bewaren?
Zolang het relevant kan zijn voor interne controles, verzekeraars of mogelijke privacyvragen. Bewaar het samen met de logs vanaf 20 oktober 2026. Concrete termijnen stemt u af met de functionaris voor gegevensbescherming of juridisch advies.
Kan ik de changelog ook zonder internettoegang controleren?
Ja. Debian en Ubuntu slaan de changelog van elk pakket lokaal op onder /usr/share/doc, RPM-systemen bewaren hem in de pakketdatabase. Beide zijn zonder netwerk te lezen.