Kort sagt: Virtuel patching til PHP overbryder tiden, indtil den rigtige opdatering er indspillet. Vi kombinerer dertil regler fra en Web Application Firewall med de midlertidige foranstaltninger, som php.net har offentliggjort om PHP2Shell, og fastlægger straks vejen til den ordinære rettelse. Fuld beskyttelse giver det ikke, men det mindsker risikoen i overgangsperioden.
Hvornår virtuel patching til PHP er fornuftig
BSI (det tyske forbundsagentur for informationssikkerhed) anbefaler ved PHP2Shell en øjeblikkelig opdatering og, hvis det ikke kan lade sig gøre, midlertidigt at tage webserverne af nettet. For mange virksomheder er ingen af delene gennemførlig med det samme: En webshop skal forblive tilgængelig, en egenudvikling skal testes før opdateringen, eller serveren kører med PHP 8.1 og ældre, hvortil der ikke længere findes officielle opdateringer.
I disse tilfælde er virtuel patching en bro. Den erstatter ikke afvejningen af, om offlinedrift ville være mere passende. Den afvejning træffer I, vi leverer den tekniske vurdering.
Hvorfor en WAF alene ikke er nok
Cloudflare har meldt om observerede angrebsforsøg og har udrullet beskyttelsesregler, men advarer om, at regler baseret på forespørgselsdata alene ikke er nok. Årsagen ligger i sårbarhedernes art. Ved CVE-2026-109618 kan en out-of-memory-tilstand afbryde PHP, mens forespørgselsdata kun er delvis initialiseret. Ved CVE-2026-109619 kan intern tilstand bestå efter frigivelsen af hukommelsen og udnyttes af en senere forespørgsel i samme worker. Den slags fejl afhænger af serverens tilstand, ikke kun af indholdet i en enkelt forespørgsel.
Derfor satser vi på flere lag: WAF-regler foran serveren, midlertidige foranstaltninger i selve PHP og en skærpet overvågning af serveren. Hvert lag opfanger en del, intet alene er nok. Sammen skaffer de jer tiden til at indspille opdateringen ordnet.
De midlertidige foranstaltninger efter php.net
php.net nævner flere indstillinger, som sænker risikoen, udtrykkeligt uden fuld beskyttelse. Vigtigt er, at applikationer ikke kan overskrive disse værdier. Et eksempel på en PHP-FPM-pool med uploads:
; Midlertidige foranstaltninger PHP2Shell (ingen fuld beskyttelse), genstart derefter alle workers
php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 32M
php_admin_value[upload_max_filesize] = 30M
php_admin_flag[session.upload_progress.enabled] = off
; kun PHP 8.5:
php_admin_flag[fatal_error_backtraces] = off
Uden uploads anbefaler php.net post_max_size = 8M. Fordi memory_limit ophæves, hører en hukommelsesgrænse på niveau med container eller cgroup med, ikke via RLIMIT_AS eller RLIMIT_DATA. Indstillingen session.upload_progress.enabled=0 hører hjemme i php.ini, FPM-pool eller serverkonfiguration, ikke i ini_set() eller .user.ini. Den er samtidig afhjælpningen i henvisningen til CVE-2026-115560. Alle foranstaltninger i overblik står under Akutforanstaltninger, hvis I endnu ikke kan rette.
Midlertidige foranstaltninger virker først efter en genstart af alle PHP-workers. Og de beskytter kun mod fremtidige angreb: Om nogen allerede var trængt ind før, besvarer de ikke.
Hvornår offlinedrift er det bedre valg
Virtuel patching er ikke i enhver situation det rigtige svar. Ved visse konstellationer anbefaler vi at følge BSI og midlertidigt tage webserveren af nettet, til der er rettet:
- serveren kører med Apache og mod_php, hvor PHP-teamet vurderer risikoen som højest, og en exploit er vist, før applikationskode overhovedet kører
- på serveren ligger særligt beskyttelsesværdige data, f.eks. sundheds-, klient- eller betalingsdata
- der er ingen mulighed for at sætte de midlertidige foranstaltninger fast i serverkonfigurationen, f.eks. ved visse shared hosting-pakker
- der er allerede tegn på, at serveren er blevet angrebet
En midlertidig offlinedrift betyder ikke, at jeres website er blevet hacket. Nogle udbydere har af forsigtighed taget websites offline. En kort, saglig henvisningsside til de besøgende er så som regel en bedre løsning end et uforklaret udfald.
Hvordan hjælper PHP SOS konkret?
- Kontrollere situationen: Vi registrerer PHP-versioner, driftsformer og eksisterende beskyttelseslag som CDN, WAF eller reverse proxy. Ved mod_php gør vi opmærksom på den forhøjede risiko, som PHP-teamet ser dér.
- Opbygge lag: Vi aktiverer eller supplerer WAF-regler, sætter de midlertidige foranstaltninger fast i serverkonfigurationen og begrænser hukommelsen via container eller cgroup. Til Nginx-opsætninger orienterer vi os efter Sikr Nginx med PHP-FPM.
- Genstart og test: Alle PHP-processer genstartes, bagefter kontrollerer vi uploads, formularer, login og kasse.
- Overvåge: I overgangsperioden holder vi skærpet øje med workernedbrud, hukommelsestoppe og usædvanlige processer.
- Planlægge rettelsen: Vi fastlægger, hvornår og hvordan den ordinære opdatering kommer, og gennemfører den via PHP-patch-servicen.
Hvad I får, hvad vi har brug for, og hvad vi ikke lover
I får en dokumentation af alle satte regler og indstillinger med begrundelse, testresultaterne og en tids- og handlingsplan for den rigtige rettelse. Fra jer har vi brug for server- eller panel-adgang, adgang til CDN eller WAF, hvis der er et, en teknisk kontaktperson og oplysninger om jeres applikationers upload-funktioner.
Vi lover ikke, at virtuel patching forhindrer et angreb. Det sænker risikoen i en begrænset periode. Ved PHP 8.1 og ældre er det ikke en varig tilstand; her hører migreringen til en understøttet version med på planen.
Ofte stillede spørgsmål
Hvad er virtuel patching?
Virtuel patching betyder at afskærme en kendt sårbarhed foran applikationen i stedet for at ændre selve koden. Det sker som regel via en Web Application Firewall eller konfigurationsændringer. Det er en overbygning, ikke en erstatning for opdateringen.
Er min CDN-udbyders WAF nok mod PHP2Shell?
Alene som regel ikke. Cloudflare har udrullet beskyttelsesregler, men advarer selv om, at regler baseret på forespørgselsdata alene ikke er nok. WAF'en er et ekstra lag ved siden af midlertidige foranstaltninger og rettelse.
Hvor længe må jeg stole på virtuel patching?
Så kort som muligt. Det skal overbryde tiden til den ordinære opdatering, f.eks. til et vedligeholdelsesvindue er ledigt, eller en applikation er testet. Ved PHP 8.1 og ældre hører en migreringsplan med.
Kan de midlertidige foranstaltninger forstyrre mit website?
Ja, det er muligt. Mindre upload-grænser kan forhindre store filuploads, og deaktivering af session-upload-progress berører statusvisninger ved upload. Vi tester de vigtigste funktioner efter hver ændring.