Hvorfor php -v viser det samme nummer efter opdateringen

Kort sagt: Når php -v viser den samme version efter opdateringen, skyldes det oftest en backport: Distributionen overtager kun sikkerhedsrettelsen i sin eksisterende PHP-version, nummeret forbliver det samme. Ubuntu 24.04 melder således fortsat 8.3.6, selv om pakken er rettet mod PHP2Shell. Afklar spørgsmålet via pakkestatus og changelog, og kontrollér desuden, om websitet virkelig kører med den nye kode.

Et typisk øjeblik efter PHP2Shell

Administratoren har indspillet opdateringen, alt uden fejl. Til kontrol skriver han php -v og ser den samme version som før. Virkede opdateringen ikke? Er serveren fortsat åben? Dette spørgsmål hører til de hyppigste siden den 21. oktober 2026.

Den gode nyhed: I de fleste tilfælde er alt i orden. Den dårlige: Der findes også tilfælde, hvor det samme nummer faktisk viser et problem. Dette indlæg hjælper med at skelne mellem de to.

Hvorfor distributioner ikke ændrer nummeret

Virksomheds- og LTS-distributioner lover stabilitet. Inden for en udgivelse skal adfærd og grænseflader helst ikke ændre sig. Et spring fra PHP 8.3.6 til 8.3.36 ville dog bringe talrige fejlrettelser og små adfærdsændringer med, som kunne forstyrre applikationer.

Derfor overtager mange pakkevedligeholdere kun den konkrete sikkerhedsrettelse i deres eksisterende version. Denne proces kalder man backport. Upstream-versionen, som PHP selv melder via php -v, forbliver den samme. Det, der ændrer sig, er pakkestatus, som distributionen tildeler.

Ved eksemplet Ubuntu 24.04 ser det sådan ud: PHP melder 8.3.6. Den rettede pakkestatus lyder dog ifølge USN-8948-1 8.3.6-0ubuntu0.24.04.13. Den bageste del tæller. Debian har ved PHP2Shell besluttet anderledes og leveret de nye upstream-versioner 8.2.35 og 8.4.27 til bookworm og trixie. Oversigten pr. udgivelse står i indlægget Debian og Ubuntu: Er min PHP-pakke patchet?.

Det er umagen værd at skille sådan en pakkeversion ad én gang. Ved eksemplet 8.3.6-0ubuntu0.24.04.13: Delen før bindestregen er upstream-versionen, altså det, PHP selv melder. Bagved følger distributionens revision. ubuntu0.24.04 henviser til udgivelsen, det sidste tal tæller revisionerne. Hver sikkerhedsrettelse forhøjer dette tal. Ved Ubuntu Pro kommer desuden et tillæg som +esm5, ved Debian-sikkerhedsopdateringer et som ~deb12u1. Den, der kan læse disse dele, ser med det samme, om en pakke er ændret efter en sikkerhedsmeddelelse.

Hvor det gamle nummer overalt dukker op

Det uændrede nummer optræder ikke kun i php -v. Det står også på steder, der er synlige udefra eller analyseres af værktøjer:

Eksterne scannere er et særtilfælde. Den, der bruger dem, får efter PHP2Shell muligvis fund for servere, som for længst er rettet. Ignorér ikke disse fund generelt, men dokumentér pakkestatus for hver server, og notér fundet som kontrolleret. En yderligere grund til at skjule versionsoplysninger udadtil står i indlægget expose_php og server-headere.

Hvornår det samme nummer er et advarselstegn

Der er tre situationer, hvor det uændrede nummer faktisk peger på et problem:

1. Pakkekilden leverer upstream-versionen. Kommer PHP fra en kilde, der normalt leverer den aktuelle upstream-version, f.eks. Debian ved PHP2Shell eller tredjepartskilder som Remi og sury.org, bør der efter opdateringen stå 8.5.12, 8.4.27, 8.3.36 eller 8.2.35. Står der fortsat det gamle nummer, er pakken ikke opdateret.
2. I kontrollerer den forkerte installation. php -v viser kommandolinjen. Kører websitet via en anden version, f.eks. fra et hostingpanel eller en Software Collection, siger outputtet intet om websitet.
3. Pakkestatus har ikke ændret sig. Er også pakkestatus den samme som før opdateringen, er opdateringen ikke nået frem for denne pakke, f.eks. fordi den blev fastholdt, eller kilden mangler.

For ikke-teknikere kan det opsummeres sådan: Versionsnummeret beskriver modellen, pakkestatus vedligeholdelsesstatus. To servere med den samme PHP-version kan adskille sig tydeligt i sikkerhed. Spørg derfor jeres it eller serviceudbyder ikke om versionen, men om dokumentationen for patchen.

Sådan afklarer I spørgsmålet på fem minutter

Følgende kommandoer er rent læsende. Eksemplerne tager udgangspunkt i Ubuntu eller Debian og PHP 8.3; på RHEL-systemer bruger I rpm -q i stedet for dpkg-query.

# 1. Hvad melder PHP selv, inklusive build-dato?
php -v

# 2. Hvilken pakkestatus er installeret, fra hvilken kilde?
apt policy php8.3-fpm

# 3. Indeholder changelog CVE-numrene?
apt changelog php8.3-fpm 2>/dev/null | grep -E "CVE-2026-10961[89]"

# 4. Siden hvornår har websitets PHP-processer kørt?
ps -eo pid,lstart,cmd | grep "[p]hp-fpm"

Build-datoen i outputtet fra php -v er et fingerpeg, men ikke et bevis. Det holdbare bevis leverer posten i changelog. Hvordan I finder og fastholder den, hvis den er formuleret anderledes eller mangler, beskriver indlægget Dokumentér CVE-numre i pakkens changelog.

Den generelle kontrol via version, pakke og processer opsummerer siden Kontrollér PHP-version og patchstatus korrekt.

Hvordan hjælper PHP SOS konkret?

• Vi afklarer for hver server, om et uændret versionsnummer er en backport eller en manglende opdatering.
• Vi vurderer fund fra sårbarhedsscannere og dokumenterer falske alarmer med pakkestatus og changelog.
• Vi kontrollerer, hvilken PHP-installation websitet faktisk bruger, og om dens processer er genstartet.
• I PHP-patchservice dokumenterer vi upstream-version og pakkestatus side om side.

Ofte stillede spørgsmål

Kilder

• Ubuntu Security Notice USN-8948-1
• Debian Security Tracker: CVE-2026-109618
• php.net: Sikkerhedsmeddelelser