Kort sagt: En workaround för PHP-sårbarheten PHP2Shell kan sänka risken men ersätter inte uppdateringen. php.net anger fasta minnes- och uppladdningsgränser, avstängning av Session Upload Progress och på PHP 8.5 fatal_error_backtraces=0. Är inte heller det möjligt på kort sikt rekommenderar BSI att tillfälligt ta webbservern från nätet.
Vad en workaround kan göra och inte kan göra
Övergångsåtgärderna från php.net ska försvåra de villkor under vilka sårbarheterna CVE-2026-109618 och CVE-2026-109619 går att utnyttja. De är uttryckligen inget fullständigt skydd. Sårbarheterna är åtgärdade bara i PHP 8.5.12, 8.4.27, 8.3.36 och 8.2.35 eller i en bekräftad backport från er leverantör.
Åtgärderna är meningsfulla när uppdateringen av ett konkret skäl ännu inte går: ett underhållsfönster återstår, en applikation måste först testas, eller ni driver PHP 8.1 eller äldre, för vilket det inte längre finns någon officiell uppdatering. De är då en brygga, inget mål.
Planera därför uppdateringen samtidigt med workarounden: Vem genomför den, i vilket underhållsfönster, och vem kontrollerar därefter att alla workers har startats om? En övergång utan slutdatum riskerar att bli ett permanent tillstånd.
Alternativ 1: ta servern tillfälligt från nätet
BSI (Tysklands federala myndighet för informationssäkerhet) har utlyst varningsnivå 3 (orange) och rekommenderar att tillfälligt ta berörda webbservrar från nätet om uppdateringen inte är möjlig genast. Några leverantörer har gjort det försiktighetsvis; det betyder inte att de sidorna har hackats.
För många företag är ett avbrott i butiken eller portalen dyrt. En avvägning kan vara meningsfull: åtkomst bara via VPN eller godkända IP-adresser, en statisk underhållssida i stället för PHP-applikationen eller avstängning av enskilda webbplatser på servern som inte behövs. Ju mindre PHP som är nåbart utifrån, desto mindre angreppsyta.
Viktigt är att fatta beslutet medvetet och dokumentera det: Vem beslutade när att låta servern vara online, och med vilka skyddsåtgärder? Det hjälper senare gentemot försäkringsgivare, dataskydd och ledning.
Övergångsåtgärderna från php.net
| Åtgärd | Värde | Anmärkning |
|---|---|---|
memory_limit |
-1, ej överskrivbart |
sätt då minnesgränsen via container eller cgroup |
post_max_size |
8M utan uppladdningar, 32M med uppladdningar |
upload_max_filesize under det |
| Minnesgräns | via container/cgroup | inte via RLIMIT_AS eller RLIMIT_DATA |
session.upload_progress.enabled |
0 |
i php.ini, pool eller serverkonfiguration, inte via ini_set() eller .user.ini |
fatal_error_backtraces |
0 |
bara PHP 8.5 |
Inställningen session.upload_progress.enabled=0 är samtidigt åtgärden för sårbarheten CVE-2026-115560 som rapporterades den 23 oktober.
Sätt workarounden för PHP-sårbarheten rätt
Avgörande är platsen. Värdena måste sättas så att en applikation inte kan skriva över dem. Sökvägar och tjänstnamn skiljer sig mellan distributioner; exemplen utgår från PHP 8.3.
PHP-FPM, i poolen (t.ex. /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
; bara 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
Minnesgräns via cgroup, här med systemd för FPM-tjänsten. Värdet anpassar ni till er server:
# sudo systemctl edit php8.3-fpm
[Service]
MemoryMax=2G
Starta därefter om alla workers, annars verkar ingenting av detta: systemctl restart php8.3-fpm eller vid mod_php Apache. Hur ni kontrollerar att ingen gammal process längre körs står under Starta om PHP-FPM och alla workers. Allmän härdning av konfigurationen beskriver Konfigurera php.ini säkert.
Testa uppladdningar och stora formulär efter omställningen. Ett för snävt post_max_size kan blockera beställningar, ansökningsformulär eller mediauppladdningar. Det är ett skäl att inte skjuta upp uppdateringen länge.
Ytterligare skyddslager
En Web Application Firewall eller virtuell patchning kan hjälpa som ett lager till. Cloudflare har rullat ut skyddsregler men varnar själva för att regler baserade enbart på förfrågningsdata inte räcker. En WAF är därför ett komplement, inte en ersättning. Mer om det under WAF och virtuell patchning.
Säkra dessutom serverloggarna från och med den 20 oktober. Enligt mediarapporter observerades ett första angreppsförsök redan den 17 oktober; loggarna är grunden om ni senare måste klarlägga om något hände före patchen.
Hur hjälper PHP SOS konkret?
- Klarlägga läget: Vi kontrollerar om en uppdatering är möjlig på kort sikt eller om en övergång behövs, och går igenom med er alternativet att ta delar från nätet.
- Sätta åtgärderna: Vi lägger in värdena från php.net på rätt ställe, sätter cgroup-gränsen och startar om alla workers.
- Testa funktionen: Formulär, uppladdningar och beställningsflöden kontrollerar vi efter omställningen.
- Leda till patchen: Via PHP-patchtjänsten planerar vi uppdateringen och tar därefter kontrollerat tillbaka övergångsvärdena där de stör.
Vanliga frågor
Skyddar workarounden fullständigt mot PHP2Shell?
Nej. php.net betecknar åtgärderna uttryckligen som en övergång och inte som fullständigt skydd. De minskar risken tills uppdateringen är installerad. BSI rekommenderar att tillfälligt ta servrar utan patch från nätet.
Kan jag sätta inställningarna via .htaccess eller .user.ini?
För session.upload_progress.enabled utesluter php.net uttryckligen ini_set() och .user.ini. Även för memory_limit gäller: Värdet måste sättas så att applikationen inte kan skriva över det. Det lyckas i php.ini, i FPM-poolen med php_admin_value eller i Apache-serverkonfigurationen.
Räcker en Web Application Firewall som workaround?
Som extra lager kan den hjälpa. Cloudflare har rullat ut skyddsregler men påpekar själva att regler baserade enbart på förfrågningsdata inte räcker. En WAF ersätter varken uppdateringen eller övergångsåtgärderna på servern.
Vad gör jag om jag bara har delat webbhotell?
Då ligger php.ini och omstart hos webbhotellet. Fråga konkret om uppdateringen har installerats eller övergångsåtgärderna satts och om alla PHP-processer har startats om.