Kort sagt: En workaround til PHP-sårbarheden PHP2Shell kan sænke risikoen, men erstatter ikke opdateringen. php.net nævner dertil faste hukommelses- og uploadgrænser, at slukke for session-upload-progress og på PHP 8.5 fatal_error_backtraces=0. Er heller ikke det muligt på kort sigt, anbefaler BSI midlertidigt at tage webserveren af nettet.
Hvad en workaround kan, og hvad den ikke kan
php.nets midlertidige foranstaltninger skal vanskeliggøre de betingelser, hvorunder sårbarhederne CVE-2026-109618 og CVE-2026-109619 kan udnyttes. De er udtrykkeligt ingen fuld beskyttelse. Sårbarhederne er kun rettet i PHP 8.5.12, 8.4.27, 8.3.36 og 8.2.35 eller i en bekræftet backport fra jeres udbyder.
Foranstaltningerne er fornuftige, når opdateringen af en konkret grund endnu ikke kan lade sig gøre: Et vedligeholdelsesvindue mangler endnu, en applikation skal først testes, eller I driver PHP 8.1 eller ældre, hvortil der ikke længere findes en officiel opdatering. De er så en bro, ikke et mål.
Planlæg derfor opdateringen sammen med workarounden: Hvem gennemfører den, i hvilket vedligeholdelsesvindue, og hvem kontrollerer bagefter, at alle workers er genstartet? En overgang uden slutdato risikerer at blive en varig tilstand.
Mulighed 1: tag serveren midlertidigt af nettet
BSI har udsendt advarselsniveau 3 (orange) og anbefaler at tage berørte webservere midlertidigt af nettet, hvis opdateringen ikke er mulig med det samme. Nogle udbydere har gjort det af forsigtighed; det betyder ikke, at disse sider er blevet hacket.
For mange virksomheder er et udfald af webshoppen eller portalen dyrt. En afvejning kan være fornuftig: adgang kun via VPN eller frigivne IP-adresser, en statisk vedligeholdelsesside i stedet for PHP-applikationen eller at slukke enkelte, ikke nødvendige websites på serveren. Jo mindre PHP der er tilgængeligt udefra, desto mindre er angrebsfladen.
Vigtigt er at træffe beslutningen bevidst og fastholde den: Hvem besluttede hvornår at lade serveren være online, og med hvilke beskyttelsesforanstaltninger? Det hjælper senere over for forsikringsselskab, databeskyttelse og direktion.
php.nets midlertidige foranstaltninger
| Foranstaltning | Værdi | Bemærkning |
|---|---|---|
memory_limit |
-1, kan ikke overskrives |
sæt så hukommelsesgrænsen via container eller cgroup |
post_max_size |
8M uden uploads, 32M med uploads |
upload_max_filesize derunder |
| Hukommelsesgrænse | via container/cgroup | ikke via RLIMIT_AS eller RLIMIT_DATA |
session.upload_progress.enabled |
0 |
i php.ini, pool eller serverkonfiguration, ikke via ini_set() eller .user.ini |
fatal_error_backtraces |
0 |
kun PHP 8.5 |
Indstillingen session.upload_progress.enabled=0 er samtidig afhjælpningen af sårbarheden CVE-2026-115560, der blev meldt den 23. oktober.
Sæt workarounden til PHP-sårbarheden korrekt
Afgørende er stedet. Værdierne skal sættes, så en applikation ikke kan overskrive dem. Stier og tjenestenavne afviger fra distribution til distribution; eksemplerne tager udgangspunkt i PHP 8.3.
PHP-FPM, i poolen (f.eks. /etc/php/8.3/fpm/pool.d/www.conf):
php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 8M
php_admin_value[upload_max_filesize] = 6M
php_admin_flag[session.upload_progress.enabled] = off
; kun PHP 8.5:
; php_admin_flag[fatal_error_backtraces] = off
Apache med mod_php, i serverkonfigurationen eller i VirtualHost:
php_admin_value memory_limit -1
php_admin_value post_max_size 32M
php_admin_value upload_max_filesize 24M
php_admin_flag session.upload_progress.enabled off
Hukommelsesgrænse via cgroup, her med systemd for FPM-tjenesten. Værdien tilpasser I jeres server:
# sudo systemctl edit php8.3-fpm
[Service]
MemoryMax=2G
Genstart derefter alle workers, ellers virker intet af det: systemctl restart php8.3-fpm eller ved mod_php Apache. Hvordan I kontrollerer, at ingen gammel proces kører længere, står under Genstart PHP-FPM og alle workers. Almindelig hærdning af konfigurationen beskriver Konfigurér php.ini sikkert.
Test uploads og store formularer efter omstillingen. En for knap post_max_size kan blokere bestillinger, ansøgningsformularer eller medieuploads. Det er en grund til ikke at udskyde opdateringen længe.
Yderligere beskyttelseslag
En Web Application Firewall eller virtuel patching kan hjælpe som yderligere lag. Cloudflare har udrullet beskyttelsesregler, men advarer selv om, at regler baseret på forespørgselsdata alene ikke er nok. En WAF er derfor et supplement, ikke en erstatning. Mere herom under WAF og virtuel patching.
Sikr desuden serverlogs fra og med 20. oktober. Ifølge mediernes rapporter blev et første angrebsforsøg allerede observeret den 17. oktober; logs er grundlaget, hvis I senere skal afklare, om der skete noget før rettelsen.
Hvordan hjælper PHP SOS konkret?
- Afklare situationen: Vi kontrollerer, om en opdatering er mulig på kort sigt, eller om en overgang er nødvendig, og drøfter med jer muligheden for at tage dele af systemet af nettet.
- Sætte foranstaltninger: Vi indfører værdierne fra php.net det rigtige sted, sætter cgroup-grænsen og genstarter alle workers.
- Teste funktion: Formularer, uploads og bestillingsforløb kontrollerer vi efter omstillingen.
- Føre til rettelsen: Via PHP-patch-servicen planlægger vi opdateringen og tager overgangsværdierne kontrolleret tilbage bagefter, hvor de generer.
Ofte stillede spørgsmål
Beskytter workarounden fuldstændigt mod PHP2Shell?
Nej. php.net betegner udtrykkeligt foranstaltningerne som en overgang og ikke som fuld beskyttelse. De mindsker risikoen, indtil opdateringen er indspillet. BSI anbefaler midlertidigt at tage servere uden rettelse af nettet.
Kan jeg sætte indstillingerne via .htaccess eller .user.ini?
For session.upload_progress.enabled udelukker php.net udtrykkeligt ini_set() og .user.ini. Også for memory_limit gælder: Værdien skal sættes, så applikationen ikke kan overskrive den. Det lykkes i php.ini, i FPM-poolen med php_admin_value eller i Apache-serverkonfigurationen.
Er en Web Application Firewall nok som workaround?
Som ekstra lag kan den hjælpe. Cloudflare har udrullet beskyttelsesregler, men påpeger selv, at regler baseret på forespørgselsdata alene ikke er nok. En WAF erstatter hverken opdateringen eller de midlertidige foranstaltninger på serveren.
Hvad gør jeg, hvis jeg kun har shared hosting?
Så ligger php.ini og genstart hos hostingudbyderen. Spørg konkret, om opdateringen er indspillet eller de midlertidige foranstaltninger sat, og om alle PHP-processer er genstartet.