Kort sagt: For at kontrollere et CVE-nummer i changelog gennemsøger I ændringsloggen for den installerede PHP-pakke efter CVE-2026-109618 og CVE-2026-109619: under Debian og Ubuntu i /usr/share/doc/<paket>/changelog.Debian.gz, på RPM-systemer med rpm -q --changelog. Et fund sammen med pakkestatus, afstemning med den officielle sikkerhedsmeddelelse og genstartstidspunkt giver et pålideligt bevis. Et manglende fund er endnu ikke bevis for en åben sårbarhed.
Hvorfor et bevis er mere end „vi har patchet“
Efter PHP2Shell vil mange vide, om deres servere er sikre: ledelsen, databeskyttelsesrådgiveren, kunder med databehandleraftale, nogle gange cyberforsikringsselskabet. „Vi har patchet“ er for lidt hertil. Der kræves et bevis, som en tredjepart kan efterprøve.
Versionsnummeret egner sig ofte ikke hertil, fordi distributioner indspiller rettelser som backport, og nummeret forbliver det samme. Pakkens changelog er det bedre grundlag. Den skrives af pakkevedligeholderen og opregner ved sikkerhedsopdateringer som regel de rettede CVE-numre.
Hvor changelogs ligger
Hvert pakkeformat har sit eget sted. Følgende oversigt hjælper med hurtigt at nå det rigtige.
| System | Changelogs placering | Kommando til søgning |
|---|---|---|
| Debian, Ubuntu | /usr/share/doc/<paket>/changelog.Debian.gz |
zgrep |
| Debian, Ubuntu (online) | Distributionens pakkearkiv | apt changelog <paket> |
| RHEL, AlmaLinux, Rocky, Fedora | RPM-pakkedatabasen | rpm -q --changelog <paket> |
| Container-images | i imaget, som i basissystemet | kør kommandoen i containeren |
Under Debian og Ubuntu peger dokumentationsmappen for nogle binære pakker via et symbolsk link på en fælles pakke, f.eks. php8.3-common. Finder zgrep ikke filen, så se mappen igennem med ls -l /usr/share/doc/ | grep php.
Kontrollér CVE i changelog: sådan gør I
Følgende kommandoer er rent læsende. Tilpas pakkenavnene til jeres installation.
# Debian/Ubuntu: lokalt, uden netværk
zgrep -n -E "CVE-2026-10961[89]|CVE-2026-115560" /usr/share/doc/php8.3-common/changelog.Debian.gz
# Debian/Ubuntu: overskriftslinje for den nyeste post med pakkestatus og dato
zcat /usr/share/doc/php8.3-common/changelog.Debian.gz | head -20
# RHEL-familien: post med dato og pakkestatus
rpm -q --changelog php-common | grep -n -B3 -E "CVE-2026-10961[89]"
Hos Debian og Ubuntu står pakkestatus i overskriftslinjen for hver post, datoen i slutlinjen. Hos RPM står begge dele i linjen over posterne. Så ser I ikke kun, om CVE-nummeret er nævnt, men også med hvilken pakkestatus. Sammenlign denne status med den installerede, f.eks. via dpkg-query -W eller rpm -q. Stemmer begge overens, er rettelsen indeholdt i den pakke, der kører.
Panel-pakker og containere
Hostingpaneler medbringer egne PHP-pakker, f.eks. Plesk eller cPanel. Også disse er almindelige DEB- eller RPM-pakker, deres changelog kan læses med de samme værktøjer. Om udbyderne deri nævner CVE-numre eller kun den nye PHP-version, er forskelligt. Nævner pakken upstream-versionen 8.5.12, 8.4.27, 8.3.36 eller 8.2.35, er det tilstrækkeligt som bevis; ved backports med gammelt nummer har I brug for udbyderens svar.
Ved containere hører beviset til imaget, ikke til værten. Kontrollér pakkerne i det image, som den kørende container blev startet fra, og notér desuden image-digestet. Så kan det senere efterprøves, hvilken status der faktisk kørte, selv om imaget er bygget om under samme tag i mellemtiden.
Hvis CVE-nummeret mangler i changelog
En manglende post har flere mulige årsager. Gå dem igennem i denne rækkefølge:
- Forkert pakke gennemsøgt: Ved flere PHP-grene eller kilder på en server ligger svaret ofte i en anden pakkes changelog.
- Upstream-version i stedet for CVE: Leverer kilden den nye upstream-version ud, f.eks. 8.4.27, står der i changelog måske kun „New upstream version“. Så er versionsnummeret selv beviset, fordi php.net nævner versionerne 8.5.12, 8.4.27, 8.3.36 og 8.2.35 som rettede.
- Anden formulering: Nogle vedligeholdere nævner fejlnumre eller advisory-betegnelser som GHSA-w8hw-w9fx-j79w og GHSA-6wmf-4rv5-p3rp i stedet for CVE-nummeret.
- Afstemning med sikkerhedsmeddelelsen: Nævner jeres distributions officielle meddelelse, f.eks. en USN eller Debian Security Tracker, en rettet pakkestatus, og er denne eller en nyere installeret, er det ligeledes et bevis. For Debian og Ubuntu finder I statusserne i indlægget Er min PHP-pakke patchet?, for RHEL-familien under RHEL, AlmaLinux og Rocky Linux.
- Spørg udbyderen: Ved panel-pakker, hosterbuilds eller tredjepartskilder hjælper kun et skriftligt svar. En skabelon findes i vejledningen Spørg hosteren om patch-status.
Er der efter disse skridt stadig intet bevis, så behandl serveren som upatchet, og sæt overgangsforanstaltninger, til spørgsmålet er afklaret.
Fra fund til bevis
Et fund i changelog beviser, at pakken indeholder rettelsen. Det beviser ikke, at de kørende processer bruger den. Et fuldstændigt bevis indeholder derfor fem oplysninger pr. server og PHP-installation:
- server, PHP-gren og driftsform, f.eks. PHP-FPM eller mod_php
- installeret pakkestatus og pakkekilde
- fundsted i changelog eller henvisning til den officielle sikkerhedsmeddelelse
- tidspunkt for opdateringen og starttidspunkt for de kørende PHP-processer
- navn på den person, der har kontrolleret, og dato for kontrollen
Gem kommandoernes rå output som tekstfil ved siden af beviset. De er senere lettere at efterprøve end et resumé fra hukommelsen.
Et bevis besvarer kun spørgsmålet, om sårbarheden var lukket fra et bestemt tidspunkt. For tiden før har I brug for logs fra og med den 20. oktober 2026 og om nødvendigt en sporsøgning. Det generelle forløb for versionskontrol beskriver siden Kontrollér PHP-version og patchstatus korrekt.
Hvordan hjælper PHP SOS konkret?
- Vi gennemsøger changelogs for alle PHP-pakker på jeres servere og afstemmer dem med de officielle sikkerhedsmeddelelser.
- Hvor changelogs tier, afklarer vi statussen med distributionen, panel-udbyderen eller hosteren.
- Vi kontrollerer, at de kørende processer er genstartet efter opdateringen.
- Med PHP-patchservice får I beviset pr. server i en form, som I kan give videre til tredjeparter.
Ofte stillede spørgsmål
Hvorfor er PHP-versionen ikke nok som bevis?
Mange distributioner overtager sikkerhedsrettelser som backport uden at ændre PHP-versionen. Versionsnummeret siger så intet om patchen. Den installerede pakkes changelog nævner derimod de rettede CVE-numre.
Hvad betyder det, hvis CVE-nummeret mangler i changelog?
Det kan betyde, at rettelsen mangler. Men det kan også være, at pakkevedligeholderen har formuleret sig anderledes, f.eks. med et fejlnummer eller en upstream-version. Så afstemmer I pakkestatus med den officielle sikkerhedsmeddelelse eller spørger udbyderen.
Hvor længe bør jeg opbevare beviset?
Så længe det kan være relevant for interne kontroller, forsikringsselskaber eller mulige databeskyttelsesspørgsmål. Gem det sammen med logs fra og med den 20. oktober 2026. Konkrete frister afklarer I med databeskyttelsesrådgiveren eller juridisk rådgivning.
Kan jeg også kontrollere changelog uden internetadgang?
Ja. Debian og Ubuntu lægger hver pakkes changelog lokalt under /usr/share/doc, RPM-systemer gemmer den i pakkedatabasen. Begge dele kan læses uden netværk.