Kort sagt: Ved en PHP-sårbarhed som PHP2Shell er det ved webhosting udbyderen, der er ansvarlig for PHP-opdateringen, ikke I. Jeres opgave er at indhente en skriftlig bekræftelse, vælge en understøttet PHP-version i kundemenuen og gennemgå websitet for spor af et angreb. En patch hos udbyderen fjerner ikke skadelig software, som tidligere er kommet ind på jeres website.
Situationen i enkle ord
PHP er det programmeringssprog, som de fleste websites, shops og CMS'er som WordPress kører på. PHP2Shell betegner to kritiske fejl i PHP selv (CVE-2026-109618 og CVE-2026-109619). Angribere kan via dem uden adgangskode køre egen kode på serveren. BSI (det tyske forbundsagentur for informationssikkerhed) har udråbt advarselsniveau 3 (orange) og anbefaler en øjeblikkelig opdatering.
Ved shared hosting deler mange kunder én server. Teknikken nedenunder, altså operativsystem, webserver og PHP, drives af udbyderen. I administrerer selv kun jeres website, database og adgange. Derfor kan I ikke selv indspille PHP-opdateringen, og I behøver det heller ikke.
Webhosting og PHP-sårbarhed: hvem er ansvarlig?
Fordelingen fremgår af jeres kontrakt. I de fleste abonnementer gælder groft følgende fordeling:
| Opgave | Udbyder | I som kunde |
|---|---|---|
| Opdatere PHP-pakker | ja | nej |
| Genstarte PHP-processer | ja | nej |
| Sætte serverdækkende midlertidige værdier | ja | nej |
| Vælge websitets PHP-version | stiller til rådighed | vælger |
| Opdatere CMS, plugins, temaer | nej | ja |
| Adgangsdata og administratorkonti | nej | ja |
| Gennemgå website for skadelig kode | delvist | ja |
| Databeskyttelsesretlig vurdering | nej | ja |
Den sidste linje er vigtig: Opstår der på jeres website en hændelse med personoplysninger, er det som regel I som driftsansvarlig, der er ansvarlig, ikke udbyderen. Mere herom under GDPR-anmeldelsespligt.
Det bør I gøre selv nu
1. Indhent bekræftelse. Spørg jeres udbyder skriftligt, om PHP-versionerne i jeres pakke er sikret mod begge CVE'er, siden hvornår, og om alle PHP-processer er genstartet. En færdig skabelon finder I under Spørg hostingudbyderen om patch-status. Bliv ikke forundret, hvis der i kundemenuen fortsat står et ældre versionsnummer som 8.2.34: Nogle udbydere leverer rettelser som backport uden at ændre nummeret.
2. Kontrollér PHP-versionen. Se i kundemenuen, hvilken PHP-version jeres website bruger. PHP 8.1 og ældre får ikke længere officielle opdateringer fra PHP-projektet. PHP 8.2 når den 31.12.2026 enden af supporten. Om jeres CMS kan klare en nyere version, kontrollerer I ifølge producentens systemkrav, f.eks. på wordpress.org.
3. Gennemgå websitet. Vær opmærksom på ukendte administratorkonti, uventede omdirigeringer, fremmede filer i FTP-adgangen og advarsler i Google Search Console. En liste over typiske tegn står under Er jeg allerede kompromitteret?.
4. Opret en sikkerhedskopi. Hent en aktuel sikkerhedskopi af filer og database, og opbevar den adskilt. Bed desuden udbyderen om at gemme adgangsloggene for jeres pakke fra og med 20.10.2026.
Skift efter udbyderens bekræftelse forebyggende adgangskoderne til kundemenu, FTP/SFTP, database og CMS-administratorer, og aktivér to-faktor-login, hvor det er muligt.
Hvad I ikke selv kan løse ved shared hosting
De af php.net anbefalede midlertidige foranstaltninger, f.eks. session.upload_progress.enabled=0, virker kun, hvis de sættes i serverkonfigurationen. En post i .user.ini eller via ini_set() i koden er ifølge php.net ikke nok. Også hukommelsesgrænser på cgroup-niveau og genstarten af PHP-processerne ligger hos udbyderen.
Svarer jeres udbyder ikke eller kun undvigende, har I tre muligheder: følg op og sæt en frist, sæt websitet midlertidigt i vedligeholdelsestilstand, eller skift til en udbyder med en klar udmelding. BSI anbefaler at tage webservere midlertidigt af nettet, hvis en opdatering ikke kan gennemføres med det samme.
Kontrollér desuden, om jeres abonnement stadig er tidssvarende. Pakker, der har kørt uændret i mange år, ligger nogle gange på ældre servergenerationer med ældre PHP-versioner, som udbyderen kun vedligeholder i begrænset omfang. Et skift til et aktuelt abonnement hos samme udbyder kræver ofte kun lidt arbejde og medfører nyere PHP-versioner. Spørg efter det, hvis svaret om patch-status er utilfredsstillende.
Hvis websitet allerede er påfaldende
En patch hos udbyderen lukker sårbarheden for fremtiden. Den fjerner imidlertid ikke en bagdør, som angribere har indbygget tidligere, og beviser ikke, at intet er sket før. Finder I noget påfaldende, så slet ikke filer på må og få. Sikr først tilstanden, så årsagen senere kan spores.
Hvordan hjælper PHP SOS konkret?
- Vi formulerer sammen med jer forespørgslen til udbyderen og vurderer dens svar teknisk.
- Vi gennemgår jeres website for webshells, fremmede konti og manipulerede filer og renser det ved fund via vores fjernelse af malware.
- Ved akut mistanke overtager vi nødhjælp til hackede websites med bevissikring.
- Vi hjælper med valget af en passende PHP-version og tester websitet bagefter.
Ofte stillede spørgsmål
Skal jeg som hostingkunde selv opdatere PHP?
Som regel ikke, for ved shared hosting hører PHP til udbyderens platform. I kan dog ofte vælge PHP-versionen i kundemenuen. Står der en version uden officielle opdateringer, bør I skifte eller spørge udbyderen, hvordan den sikres.
Mit website er offline. Er jeg blevet hacket?
Ikke nødvendigvis. Nogle udbydere har forebyggende taget websites af nettet for at lukke sårbarheden. Spørg udbyderen om årsagen, og få bekræftet, om der er tegn på et angreb mod jeres pakke.
Kan jeg selv sætte de midlertidige foranstaltninger i .user.ini?
For session.upload_progress.enabled angiver php.net udtrykkeligt, at .user.ini og ini_set() ikke er tilstrækkelige. Denne indstilling skal udbyderen sætte i serverkonfigurationen.
Hvad bør jeg have skriftligt fra udbyderen?
En bekræftelse på, at PHP-versionerne i jeres pakke er sikret mod CVE-2026-109618 og CVE-2026-109619, fra hvilket tidspunkt det gælder, og at PHP-processerne er genstartet. Gem svaret sammen med jeres øvrige dokumenter.