Kort gezegd: Als php -v na de update dezelfde versie toont, komt dat meestal door een backport: de distributie neemt alleen de beveiligingscorrectie over in haar bestaande PHP-versie, het nummer blijft gelijk. Ubuntu 24.04 meldt zo nog steeds 8.3.6, hoewel het pakket tegen PHP2Shell is gecorrigeerd. Stel de vraag vast via pakketstand en changelog, en controleer bovendien of de website echt met de nieuwe code draait.
Een typisch moment na PHP2Shell
De beheerder heeft de update ingespeeld, alles zonder fouten. Ter controle typt hij php -v en ziet dezelfde versie als eerder. Heeft de update niet gewerkt? Staat de server nog open? Deze vraag hoort sinds 21 oktober 2026 tot de meest gestelde.
Het goede nieuws: in de meeste gevallen is alles in orde. Het slechte: er zijn ook gevallen waarin hetzelfde nummer inderdaad een probleem aanwijst. Deze bijdrage helpt beide te onderscheiden.
Waarom distributies het nummer niet wijzigen
Bedrijfs- en LTS-distributies beloven stabiliteit. Binnen een release moeten gedrag en interfaces zo min mogelijk veranderen. Een sprong van PHP 8.3.6 naar 8.3.36 zou echter talrijke foutherstellingen en kleine gedragswijzigingen meebrengen die toepassingen kunnen storen.
Daarom nemen veel pakketbeheerders alleen de concrete beveiligingscorrectie over in hun bestaande versie. Dit proces heet backport. De upstreamversie, die PHP zelf via php -v meldt, blijft gelijk. Wat verandert, is de pakketstand die de distributie toekent.
Aan het voorbeeld Ubuntu 24.04 ziet dat er zo uit: PHP meldt 8.3.6. De gecorrigeerde pakketstand luidt volgens USN-8948-1 echter 8.3.6-0ubuntu0.24.04.13. Het achterste deel telt. Debian heeft bij PHP2Shell anders gekozen en voor bookworm en trixie de nieuwe upstreamversies 8.2.35 en 8.4.27 uitgeleverd. Het overzicht per release staat in de bijdrage Debian en Ubuntu: is mijn PHP-pakket gepatcht?.
Het loont zo'n pakketversie eenmaal te ontleden. Aan het voorbeeld 8.3.6-0ubuntu0.24.04.13: het deel vóór het streepje is de upstreamversie, dus wat PHP zelf meldt. Daarachter volgt de revisie van de distributie. ubuntu0.24.04 verwijst naar de release, het laatste cijfer telt de herzieningen. Elke beveiligingscorrectie verhoogt dit cijfer. Bij Ubuntu Pro verschijnt bovendien een toevoeging zoals +esm5, bij Debian-beveiligingsupdates een zoals ~deb12u1. Wie deze delen kan lezen, ziet in één oogopslag of een pakket na een beveiligingsmelding is gewijzigd.
Waar het oude nummer overal opduikt
Het ongewijzigde nummer verschijnt niet alleen in php -v. Het staat ook op plekken die van buitenaf zichtbaar zijn of door tools worden geanalyseerd:
| Plek | Wat daar staat | Gevolg |
|---|---|---|
php -v en php -i |
Upstreamversie, builddatum | Beheerders twijfelen aan de update |
| phpinfo-pagina | Upstreamversie | Zelfde effect in de browser |
Header X-Powered-By |
Upstreamversie, als expose_php aan staat |
externe scanners melden een lek |
| Hostingpanelen zoals Plesk | Upstreamversie | Weergave bijvoorbeeld 8.2.34 ondanks patch |
| Kwetsbaarheidsscanners | Vergelijking op nummer | Vals alarm bij backports |
Externe scanners zijn een geval apart. Wie ze gebruikt, krijgt na PHP2Shell mogelijk bevindingen voor servers die allang zijn gecorrigeerd. Negeer deze bevindingen niet algemeen, maar onderbouw voor elke server de pakketstand en noteer de bevinding als gecontroleerd. Een andere reden om versievermeldingen naar buiten te verbergen, staat in de bijdrage expose_php en server-headers.
Wanneer hetzelfde nummer een waarschuwingssignaal is
Er zijn drie situaties waarin het ongewijzigde nummer werkelijk op een probleem wijst:
- De pakketbron levert de upstreamversie. Komt PHP uit een bron die normaal de actuele upstreamversie uitlevert, zoals Debian bij PHP2Shell of externe bronnen als Remi en sury.org, dan moet na de update 8.5.12, 8.4.27, 8.3.36 of 8.2.35 verschijnen. Staat daar nog het oude nummer, dan is het pakket niet bijgewerkt.
- U controleert de verkeerde installatie.
php -vtoont de opdrachtregel. Draait de website via een andere versie, bijvoorbeeld uit een hostingpaneel of een Software Collection, dan zegt de uitvoer niets over de website. - De pakketstand is niet veranderd. Is ook de pakketstand dezelfde als vóór de update, dan is de update voor dit pakket niet aangekomen, bijvoorbeeld omdat het is vastgehouden of de bron ontbreekt.
Voor niet-technici is het zo samen te vatten: het versienummer beschrijft het model, de pakketstand de onderhoudsstatus. Twee servers met dezelfde PHP-versie kunnen in veiligheid aanzienlijk verschillen. Vraag uw IT of dienstverlener daarom niet naar de versie, maar naar het bewijs voor de patch.
Zo helpt u de vraag in vijf minuten op
De volgende opdrachten zijn uitsluitend lezend. De voorbeelden gaan uit van Ubuntu of Debian en PHP 8.3; op RHEL-systemen gebruikt u rpm -q in plaats van dpkg-query.
# 1. Wat meldt PHP zelf, inclusief builddatum?
php -v
# 2. Welke pakketstand is geïnstalleerd, uit welke bron?
apt policy php8.3-fpm
# 3. Bevat de changelog de CVE-nummers?
apt changelog php8.3-fpm 2>/dev/null | grep -E "CVE-2026-10961[89]"
# 4. Sinds wanneer draaien de PHP-processen van de website?
ps -eo pid,lstart,cmd | grep "[p]hp-fpm"
De builddatum in de uitvoer van php -v is een aanwijzing, maar geen bewijs. Het betrouwbare bewijs levert de changelog-vermelding. Hoe u die vindt en vastlegt als ze anders is geformuleerd of ontbreekt, beschrijft de bijdrage CVE-nummers in de pakket-changelog aantonen.
Noteer na elke controle beide nummers: de upstreamversie uit php -v en de pakketstand. Wie later vraagt waarom de server „nog 8.3.6” heeft, krijgt zo een helder antwoord.
De algemene controle via versie, pakket en processen vat de pagina PHP-versie en patchstatus juist controleren samen.
Hoe helpt PHP SOS concreet?
- Wij stellen voor elke server vast of een ongewijzigd versienummer een backport is of een ontbrekende update.
- Wij beoordelen bevindingen uit kwetsbaarheidsscanners en onderbouwen valse alarmen met pakketstand en changelog.
- Wij controleren welke PHP-installatie de website daadwerkelijk gebruikt en of de processen zijn herstart.
- In de PHP-patchservice documenteren wij upstreamversie en pakketstand naast elkaar.
Veelgestelde vragen
Is mijn server ongepatcht als php -v het oude nummer toont?
Niet per se. Veel distributies nemen correcties als backport over in de bestaande versie. Ubuntu 24.04 toont bijvoorbeeld nog steeds 8.3.6, hoewel het pakket volgens USN-8948-1 is gecorrigeerd. Beslissend zijn pakketstand en changelog.
Waarom meldt mijn beveiligingsscanner ondanks de update een lek?
Veel scanners lezen alleen het versienummer, bijvoorbeeld uit de header X-Powered-By. Bij backports leidt dat tot valse alarmen. Controleer de pakketstand en documenteer het resultaat in plaats van de bevinding eenvoudig te negeren.
Kan php -v een nieuw nummer tonen terwijl de website dat niet doet?
Ja. php -v toont de opdrachtregel. De website kan via een andere installatie of via processen draaien die vóór de update zijn gestart. Controleer daarom ook de FPM-service of Apache en hun starttijd.
Helpt de builddatum in de uitvoer van php -v?
Het is een aanwijzing, maar geen bewijs. Een builddatum na 21 oktober 2026 past bij een gecorrigeerd pakket, maar bewijst niet dat de correctie is opgenomen. De changelog-vermelding is het betere bewijs.