Kort sagt: Efter PHP2Shell beviser den viste PHP-version alene kun lidt, fordi hostingudbydere ofte indspiller rettelser som backport. Kræv derfor en skriftlig bekræftelse af hosterens PHP-opdatering: pakkestatus pr. PHP-gren, tidspunkt for installationen og genstart af alle PHP-processer. En skabelon til kopiering finder I nedenfor.
Hvorfor en skriftlig bekræftelse tæller netop nu
Den 21.10.2026 offentliggjorde PHP-projektet rettelserne til to kritiske sårbarheder, der er kendt under navnet PHP2Shell. Begge muliggør kørsel af skadelig kode på afstand uden login. BSI (det tyske forbundskontor for informationssikkerhed) har udråbt varslingsniveau 3 / orange og anbefaler øjeblikkelig opdatering.
Den, der driver sit website hos en hoster, kan ofte ikke selv indspille opdateringen. Samtidig bærer I som driftsansvarlige ansvaret for jeres kunders data. En skriftlig, konkret bekræftelse fra hosteren er derfor mere end en formsag. Den er en byggesten i jeres dokumentation, f.eks. over for databeskyttelsesansvarlige, forsikringsselskaber eller ledelsen.
Dertil kommer: En patch fjerner ikke skadelig software, der blev smuttet ind tidligere. Ifølge medierapporter blev der allerede den 17.10. observeret et første angrebsforsøg. Det præcise tidspunkt, hvor jeres server var beskyttet, er derfor vigtigt for spørgsmålet om, hvorvidt I skal undersøge videre.
Hvorfor den viste PHP-version ikke er nok
Rettet er PHP 8.5.12, 8.4.27, 8.3.36 og 8.2.35. Mange distributioner og hostingudbydere overtager dog rettelsen som backport i deres egen pakke. Så viser en flade som Plesk fortsat 8.2.34, selv om serveren er patchet.
Omvendt kan et korrekt versionsnummer vildlede. Nye filer alene beskytter ikke, så længe gamle PHP-processer kører i hukommelsen. Først efter en genstart af alle workere er den nye status aktiv. Mere om det i indlægget Kontrollér PHP-version og patchstatus korrekt.
| Udbyderens udsagn | Hvad det dokumenterer | Hvad der mangler |
|---|---|---|
| „Alle systemer er opdaterede.“ | lidt | Version eller pakkestatus, dato, genstart |
| „PHP 8.3.36 er installeret.“ | Version | Dato, genstart, berørte servere |
| „Backport i pakken xy, genstart den …“ | Patch og aktivering | evt. oplysninger om PHP 8.1 og ældre |
Hvilke oplysninger I har brug for fra hosteren
Bed om svar på disse punkter, helst pr. website eller aftale:
- Hvilke PHP-grene og versioner er aktive for jeres websites, også ældre, der kun kører for enkelte mapper?
- Er rettelserne til CVE-2026-109618 og CVE-2026-109619 indeholdt, som officiel version eller som backport?
- Hvornår blev opdateringen installeret, og hvornår blev alle PHP-processer (FPM-pools, Apache, LiteSpeed) genstartet?
- Er
session.upload_progress.enableddeaktiveret på grund af CVE-2026-115560? - Hvilken driftsform bruger jeres abonnement, f.eks. PHP-FPM eller Apache med mod_php? Ved mod_php ser PHP-teamet den højeste risiko.
- Hvilke adgangs- og fejllogs fra og med 20.10.2026 opbevares, og hvordan får I dem udleveret?
Kører et website stadig på PHP 8.1 eller ældre, så spørg særskilt. For disse grene findes der ikke længere officielle opdateringer, kun minimale kildekode-backports til 7.4, 8.0 og 8.1.
Skabelon: anmod om bekræftelse af hosterens PHP-opdatering
Kopiér teksten ind i en supportsag eller en e-mail til jeres hoster. Udfyld oplysningerne i kantede parenteser.
Emne: Anmodning om bekræftelse af PHP-patchstatus (PHP2Shell, CVE-2026-109618 / CVE-2026-109619)
Goddag,
vi driver følgende websites / aftaler hos jer:
[Kundenummer, aftale, domæner]
I forbindelse med PHP-sårbarhederne CVE-2026-109618 og
CVE-2026-109619 (PHP2Shell, rettelser fra 21.10.2026) samt meddelelsen
om CVE-2026-115560 fra 23.10.2026 beder vi om en skriftlig
bekræftelse af følgende punkter:
1. Hvilke PHP-versioner eller pakkestatusser er aktive for vores websites?
2. Indeholder de rettelserne (officiel version eller backport)?
3. Dato og klokkeslæt for installationen.
4. Dato og klokkeslæt for genstart af alle PHP-processer (FPM, Apache,
LiteSpeed eller lign.).
5. Er session.upload_progress.enabled deaktiveret på serversiden?
6. Hvilken PHP-driftsform bruges (f.eks. PHP-FPM, mod_php)?
7. Opbevares adgangs- og fejllogs fra og med 20.10.2026, og
hvordan kan vi få dem udleveret?
8. Hvis et website stadig bruger PHP 8.1 eller ældre: Hvilken sikring
findes dér, og hvilket skifte anbefaler I?
Vi har brug for oplysningerne til vores interne dokumentation.
På forhånd tak og venlig hilsen
[Navn, firma, funktion]
Bedøm svaret rigtigt og kontrollér selv
Et godt svar nævner konkrete statusser, datoer og klokkeslæt. Almindelige formuleringer som „vi har reageret“ er ikke nok til jeres sagsmappe. Spørg i så fald venligt efter de manglende punkter.
Hvis jeres abonnement tillader det, så kontrollér desuden selv. Med SSH-adgang er disse kommandoer som regel nok:
# Kommandolinjens version (kan afvige fra webversionen)
php -v
# Pakkestatus under Debian/Ubuntu
dpkg -l | grep -E "php[0-9.]*-(fpm|cli|common)"
# Pakkestatus under RHEL, Alma, Rocky
rpm -qa | grep -i php
# Siden hvornår kører PHP-FPM-processerne?
ps -eo pid,lstart,cmd | grep "[p]hp-fpm"
Ligger starttidspunktet for PHP-processerne før den bekræftede installationsdato, var genstarten ikke fuldstændig.
Hvis hosteren ikke svarer eller kun svarer undvigende
Udebliver et svar, eller mangler de afgørende oplysninger, bør I ikke betragte situationen som afklaret. BSI anbefaler midlertidigt at tage webserverne af nettet, hvis en opdatering ikke er mulig med det samme. Om det er forholdsmæssigt for jeres website, afgør ledelsen, ideelt skriftligt og med dato.
Det kan samtidig betale sig at se efter mulige spor af et angreb, for patchtidspunktet forbliver åbent. Holdepunkter giver indlægget Er jeg allerede kompromitteret?. Uden SSH-adgang forbliver den skriftlige bekræftelse jeres vigtigste bevis. Hvilke pligter der ligger hos hosteren, og hvilke hos jer, forklarer siden Shared hosting: hvad hosteren gør; for administrerede servere hjælper Managed server: afklar ansvaret.
Læg henvendelse, svar og egne kontrolresultater med dato i en mappe. Denne sagsmappe hjælper senere ved spørgsmål fra forsikringsselskaber eller databeskyttelsesansvarlige.
Hvordan hjælper PHP SOS konkret?
- Vi formulerer sammen med jer henvendelsen til hosteren og vurderer svaret fagligt.
- Hvor der er adgang, kontrollerer vi selv pakkestatus, aktiv driftsform og genstart af PHP-processerne.
- Hvis der er huller tilbage, sætter vi overgangsforanstaltninger i værk eller planlægger skiftet til en understøttet version.
- Vi fastholder resultat og tidspunkter i et bevis, som I kan give videre internt.
Hvordan opdateringen med genstart og bevis forløber, beskriver vores PHP-patchservice.
Ofte stillede spørgsmål
Er det nok, at min hoster skriver, at alt er opdateret?
Til jeres dokumentation er det som regel ikke nok. Bed om konkrete oplysninger: pakkestatus eller version pr. PHP-gren, dato for installationen og dato for genstart af alle PHP-processer. Først dermed kan I afgrænse tidsvinduet for sårbarheden.
Hvorfor viser min hostingflade stadig PHP 8.2.34?
Distributioner og hostingudbydere indspiller til tider sikkerhedsrettelser som backport uden at ændre versionsnummeret. Plesk kan så fortsat vise 8.2.34, selv om serveren er patchet. Klarhed skaber kun udbyderens bekræftelse af pakkestatus.
Hvad gør jeg, hvis hosteren ikke svarer?
Dokumentér jeres henvendelse med dato, og spørg igen efter rimelig tid. Undersøg samtidig, om I selv kan sætte overgangsforanstaltninger, og aftal med ledelsen, om websitet skal tages af nettet, til sagen er afklaret, som BSI (det tyske forbundskontor for informationssikkerhed) anbefaler for ikke-patchede servere.
Lukker en WordPress- eller shopopdatering også sårbarheden?
Nej. PHP2Shell sidder i selve PHP. En opdatering af CMS'et eller shopsoftwaren ændrer intet ved den PHP-fortolker, der kører på serveren.