Kort sagt: För att kontrollera en CVE i changelog söker ni i det installerade PHP-paketets ändringslogg efter CVE-2026-109618 och CVE-2026-109619: under Debian och Ubuntu i /usr/share/doc/<paket>/changelog.Debian.gz, på RPM-system med rpm -q --changelog. En träff tillsammans med paketnivå, avstämning mot det officiella säkerhetsmeddelandet och omstartstid ger ett hållbart bevis. En utebliven träff är ännu inget bevis på en öppen sårbarhet.
Varför ett bevis är mer än ”vi har patchat”
Efter PHP2Shell vill många veta om deras servrar är säkra: ledningen, dataskyddsombudet, kunder med personuppgiftsbiträdesavtal, ibland cyberförsäkringsgivaren. ”Vi har patchat” räcker inte för dem. Det som efterfrågas är ett underlag som en utomstående kan följa.
Versionsnumret duger ofta inte för detta, eftersom distributioner för in rättningar som backport och numret förblir detsamma. Paketets changelog är en bättre grund. Den skrivs av paketansvarig och listar vid säkerhetsuppdateringar i regel de åtgärdade CVE-numren.
Var changelogs finns
Varje paketformat har sin egen plats. Översikten nedan hjälper er att snabbt hitta rätt.
| System | Changelogens plats | Kommando för sökning |
|---|---|---|
| Debian, Ubuntu | /usr/share/doc/<paket>/changelog.Debian.gz |
zgrep |
| Debian, Ubuntu (online) | distributionens paketarkiv | apt changelog <paket> |
| RHEL, AlmaLinux, Rocky, Fedora | RPM-paketdatabasen | rpm -q --changelog <paket> |
| Containerimages | i imagen, som i grundsystemet | kör kommandot i containern |
Under Debian och Ubuntu pekar dokumentationskatalogen för vissa binärpaket via en symbolisk länk på ett gemensamt paket, till exempel php8.3-common. Hittar zgrep inte filen, titta i katalogen med ls -l /usr/share/doc/ | grep php.
Kontrollera CVE i changelog: så går ni tillväga
Kommandona nedan är rent läsande. Anpassa paketnamnen till er installation.
# Debian/Ubuntu: lokalt, utan nätverk
zgrep -n -E "CVE-2026-10961[89]|CVE-2026-115560" /usr/share/doc/php8.3-common/changelog.Debian.gz
# Debian/Ubuntu: rubrikraden för den senaste posten med paketnivå och datum
zcat /usr/share/doc/php8.3-common/changelog.Debian.gz | head -20
# RHEL-familjen: post med datum och paketnivå
rpm -q --changelog php-common | grep -n -B3 -E "CVE-2026-10961[89]"
Hos Debian och Ubuntu står paketnivån i rubrikraden för varje post och datumet i slutraden. Hos RPM står båda i raden ovanför posterna. Då ser ni inte bara om CVE-numret nämns, utan också med vilken paketnivå. Jämför den nivån med den installerade, till exempel via dpkg-query -W eller rpm -q. Stämmer båda överens ingår rättningen i det paket som körs.
Panelpaket och containrar
Hostingpaneler levererar egna PHP-paket, till exempel Plesk eller cPanel. Även dessa är vanliga DEB- eller RPM-paket, och deras changelog kan läsas med samma verktyg. Om leverantörerna nämner CVE-nummer där eller bara den nya PHP-versionen varierar. Anger paketet upstream-versionen 8.5.12, 8.4.27, 8.3.36 eller 8.2.35 räcker det som bevis; vid backports med gammalt nummer behöver ni leverantörens besked.
För containrar hör beviset till imagen, inte till värden. Kontrollera paketen i den image som den körande containern startades från, och notera dessutom image-digest. Då går det senare att följa vilken nivå som verkligen kördes, även om imagen under samma tagg har byggts om i mellantiden.
Om CVE-numret saknas i changelog
En saknad post kan ha flera möjliga orsaker. Gå igenom dem i den här ordningen:
- Fel paket genomsökt: Vid flera PHP-grenar eller källor på en server finns svaret ofta i ett annat pakets changelog.
- Upstream-version i stället för CVE: Levererar källan den nya upstream-versionen, till exempel 8.4.27, står det i changelog under vissa omständigheter bara ”New upstream version”. Då är versionsnumret självt beviset, eftersom php.net anger versionerna 8.5.12, 8.4.27, 8.3.36 och 8.2.35 som rättade.
- Annan formulering: Vissa paketansvariga nämner buggnummer eller advisory-beteckningar som GHSA-w8hw-w9fx-j79w och GHSA-6wmf-4rv5-p3rp i stället för CVE-numret.
- Avstämning mot säkerhetsmeddelandet: Om distributionens officiella meddelande, till exempel ett USN eller Debian Security Tracker, anger en rättad paketnivå och den eller en nyare är installerad, är det också ett bevis. För Debian och Ubuntu hittar ni nivåerna i inlägget Är mitt PHP-paket patchat?, för RHEL-familjen under RHEL, AlmaLinux och Rocky Linux.
- Fråga leverantören: Vid panelpaket, hosterns egna byggen eller tredjepartskällor hjälper bara ett skriftligt besked. En mall finns i guiden Fråga hostern om patchstatus.
Finns inget bevis kvar efter dessa steg, behandla servern som opatchad och sätt in övergångsåtgärder tills frågan är klarlagd.
Från träff till bevis
En träff i changelog visar att paketet innehåller rättningen. Den visar inte att de körande processerna använder den. Ett fullständigt bevis innehåller därför fem uppgifter per server och PHP-installation:
- server, PHP-gren och driftläge, till exempel PHP-FPM eller mod_php
- installerad paketnivå och paketkälla
- fyndställe i changelog eller hänvisning till det officiella säkerhetsmeddelandet
- tidpunkt för uppdateringen och starttid för de körande PHP-processerna
- namn på den som har kontrollerat och datum för kontrollen
Spara kommandonas råutskrifter som textfil bredvid beviset. De är lättare att följa senare än en sammanfattning ur minnet.
Ett bevis besvarar bara frågan om sårbarheten var stängd från en viss tidpunkt. För tiden dessförinnan behöver ni loggarna från och med den 20 oktober 2026 och i förekommande fall en spårsökning. Det allmänna förloppet för versionskontrollen beskrivs på sidan Kontrollera PHP-version och patchnivå på rätt sätt.
Hur hjälper PHP SOS konkret?
- Vi söker igenom changelogs för alla PHP-paket på era servrar och stämmer av dem mot de officiella säkerhetsmeddelandena.
- Där changelogs tiger klarlägger vi nivån med distributionen, panelleverantören eller hostern.
- Vi kontrollerar att de körande processerna har startats om efter uppdateringen.
- Med PHP-patchtjänsten får ni beviset per server i en form som ni kan lämna vidare till utomstående.
Vanliga frågor
Varför räcker inte PHP-versionen som bevis?
Många distributioner för in säkerhetsrättningar som backport utan att ändra PHP-versionen. Versionsnumret säger då ingenting om patchen. Det installerade paketets changelog nämner däremot de åtgärdade CVE-numren.
Vad betyder det om CVE-numret saknas i changelog?
Det kan betyda att rättningen saknas. Men det kan också vara så att paketansvarig har formulerat sig annorlunda, till exempel med ett buggnummer eller en upstream-version. Då stämmer ni av paketnivån mot det officiella säkerhetsmeddelandet eller frågar leverantören.
Hur länge bör jag spara beviset?
Så länge det kan vara relevant för interna granskningar, försäkringsbolag eller möjliga dataskyddsfrågor. Förvara det tillsammans med loggarna från och med den 20 oktober 2026. Konkreta tidsfrister klarlägger ni med dataskyddsombudet eller juridisk rådgivning.
Kan jag kontrollera changelog även utan internetanslutning?
Ja. Debian och Ubuntu lägger varje pakets changelog lokalt under /usr/share/doc, RPM-system lagrar den i paketdatabasen. Båda går att läsa utan nätverk.