Kort sagt: Om php -v visar samma version efter uppdateringen beror det oftast på en backport: distributionen för bara in säkerhetsrättningen i sin befintliga PHP-version, numret förblir detsamma. Ubuntu 24.04 anger så fortfarande 8.3.6, fast paketet är rättat mot PHP2Shell. Klargör frågan via paketnivå och changelog, och kontrollera dessutom om webbplatsen verkligen körs med den nya koden.
Ett typiskt ögonblick efter PHP2Shell
Admin har installerat uppdateringen, allt utan fel. För kontroll skriver hen php -v och ser samma version som förut. Fungerade inte uppdateringen? Är servern fortfarande öppen? Den frågan hör till de vanligaste sedan den 21 oktober 2026.
Det goda beskedet: i de flesta fall är allt i sin ordning. Det dåliga: det finns också fall där samma nummer faktiskt anger ett problem. Det här inlägget hjälper att skilja mellan de två.
Varför distributioner inte ändrar numret
Företags- och LTS-distributioner lovar stabilitet. Inom en release ska beteende och gränssnitt helst inte ändras. Ett hopp från PHP 8.3.6 till 8.3.36 skulle dock medföra talrika felrättningar och små beteendeförändringar som kunde störa applikationer.
Därför för många paketunderhållare bara in den konkreta säkerhetsrättningen i sin befintliga version. Den processen kallas backport. Upstream-versionen, som PHP självt rapporterar via php -v, förblir densamma. Det som ändras är paketnivån som distributionen tilldelar.
Med Ubuntu 24.04 som exempel ser det ut så här: PHP rapporterar 8.3.6. Den rättade paketnivån lyder enligt USN-8948-1 dock 8.3.6-0ubuntu0.24.04.13. Den bakre delen räknas. Debian beslutade vid PHP2Shell annorlunda och levererade för bookworm och trixie de nya upstream-versionerna 8.2.35 och 8.4.27. Översikten per release står i inlägget Debian och Ubuntu: är mitt PHP-paket patchat?.
Det lönar sig att en gång dela upp en sådan paketversion. Med 8.3.6-0ubuntu0.24.04.13 som exempel: delen före bindestrecket är upstream-versionen, alltså det PHP självt rapporterar. Därefter följer distributionens revision. ubuntu0.24.04 hänvisar till releasen, den sista siffran räknar omarbetningarna. Varje säkerhetsrättning höjer den siffran. Vid Ubuntu Pro tillkommer ett tillägg som +esm5, vid Debians säkerhetsuppdateringar ett som ~deb12u1. Den som kan läsa de delarna ser direkt om ett paket har förändrats efter ett säkerhetsmeddelande.
Var det gamla numret dyker upp överallt
Det oförändrade numret visas inte bara i php -v. Det står också på ställen som är synliga utifrån eller utvärderas av verktyg:
| Plats | Vad som står där | Följd |
|---|---|---|
php -v och php -i |
upstream-version, byggdatum | admins tvivlar på uppdateringen |
| phpinfo-sida | upstream-version | samma effekt i webbläsaren |
Header X-Powered-By |
upstream-version, om expose_php är på |
externa skannrar rapporterar en sårbarhet |
| Webbhotellspaneler som Plesk | upstream-version | visning som 8.2.34 trots patch |
| Sårbarhetsskannrar | jämförelse efter nummer | falsklarm vid backports |
Externa skannrar är ett eget fall. Den som använder dem får efter PHP2Shell kanske fynd för servrar som sedan länge är rättade. Ignorera inte dessa fynd rakt av, utan styrk paketnivån för varje server och notera fyndet som kontrollerat. Ytterligare ett skäl att dölja versionsuppgifter utåt står i inlägget expose_php och server-headers.
När samma nummer är en varningssignal
Det finns tre situationer där det oförändrade numret faktiskt tyder på ett problem:
- Paketkällan levererar upstream-versionen. Kommer PHP från en källa som normalt levererar den aktuella upstream-versionen, till exempel Debian vid PHP2Shell eller tredjepartskällor som Remi och sury.org, bör 8.5.12, 8.4.27, 8.3.36 eller 8.2.35 visas efter uppdateringen. Står där fortfarande det gamla numret uppdaterades inte paketet.
- Ni kontrollerar fel installation.
php -vvisar kommandoraden. Körs webbplatsen via en annan version, till exempel från en webbhotellspanel eller en Software Collection, säger utskriften ingenting om webbplatsen. - Paketnivån har inte ändrats. Är även paketnivån densamma som före uppdateringen har uppdateringen inte kommit fram för det paketet, till exempel för att det hölls fast eller källan saknas.
För icke-tekniker kan det sammanfattas så: versionsnumret beskriver modellen, paketnivån underhållsläget. Två servrar med samma PHP-version kan skilja sig tydligt i säkerhet. Fråga därför er IT eller leverantör inte efter versionen utan efter beviset för patchen.
Så klargör ni frågan på fem minuter
Följande kommandon är rent läsande. Exemplen utgår från Ubuntu eller Debian och PHP 8.3; på RHEL-system använder ni rpm -q i stället för dpkg-query.
# 1. Vad rapporterar PHP självt, inklusive byggdatum?
php -v
# 2. Vilken paketnivå är installerad, från vilken källa?
apt policy php8.3-fpm
# 3. Innehåller changelogen CVE-numren?
apt changelog php8.3-fpm 2>/dev/null | grep -E "CVE-2026-10961[89]"
# 4. Sedan när har webbplatsens PHP-processer körts?
ps -eo pid,lstart,cmd | grep "[p]hp-fpm"
Byggdatumet i utskriften från php -v är en fingervisning men inget bevis. Det hållbara beviset levererar changelog-posten. Hur ni hittar och dokumenterar den när den är formulerad annorlunda eller saknas beskriver inlägget Styrka CVE-nummer i paketets changelog.
Anteckna efter varje kontroll båda numren: upstream-versionen från php -v och paketnivån. Den som senare frågar varför servern ”fortfarande har 8.3.6” får då ett tydligt svar.
Den allmänna kontrollen via version, paket och processer sammanfattar sidan Kontrollera PHP-version och patchnivå rätt.
Hur hjälper PHP SOS konkret?
- Vi klargör för varje server om ett oförändrat versionsnummer är en backport eller en saknad uppdatering.
- Vi värderar fynd från sårbarhetsskannrar och styrker falsklarm med paketnivå och changelog.
- Vi kontrollerar vilken PHP-installation webbplatsen faktiskt använder och om dess processer har startats om.
- I PHP-patchtjänsten dokumenterar vi upstream-version och paketnivå sida vid sida.
Vanliga frågor
Är min server opatchad om php -v visar det gamla numret?
Inte nödvändigtvis. Många distributioner för in rättningar som backport i den befintliga versionen. Ubuntu 24.04 visar till exempel fortfarande 8.3.6, fast paketet enligt USN-8948-1 är rättat. Avgörande är paketnivå och changelog.
Varför rapporterar min säkerhetsskanner en sårbarhet trots uppdateringen?
Många skannrar läser bara versionsnumret, till exempel ur headern X-Powered-By. Vid backports leder det till falsklarm. Kontrollera paketnivån och dokumentera resultatet i stället för att bara ignorera fyndet.
Kan php -v visa ett nytt nummer fast webbplatsen inte gör det?
Ja. php -v visar kommandoraden. Webbplatsen kan köras via en annan installation eller via processer som startades före uppdateringen. Kontrollera därför även FPM-tjänsten eller Apache och deras starttid.
Hjälper byggdatumet i utskriften från php -v?
Det är en fingervisning men inget bevis. Ett byggdatum efter den 21 oktober 2026 passar till ett rättat paket men visar inte att rättningen ingår. Changelog-posten är det bättre beviset.