# Akutåtgärder om ni ännu inte kan patcha

> Workaround för PHP-sårbarheten PHP2Shell: övergångsåtgärderna från php.net, rätt inställda, med gränser och anvisningar för vägen till patchen.

Källa: https://phpsos.de/sv/php2shell/sofortmassnahmen-ohne-patch/  
Aktualitet: 2026-10-25  
Leverantör: PHP SOS, PHP-nödhjälp och serversäkerhet. Omedelbar hjälp via WhatsApp: https://wa.me/491736494914?text=Hej%20PHP%20SOS%2C%20vi%20beh%C3%B6ver%20hj%C3%A4lp%20med%20v%C3%A5r%20PHP-server.%20F%C3%B6retag%3A%20%E2%80%A6%20Webbplats%3A%20%E2%80%A6

**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](https://phpsos.de/sv/php2shell/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`):

```ini
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:

```apache
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:

```ini
# 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](https://phpsos.de/sv/php2shell/php-fpm-neustart/). Allmän härdning av konfigurationen beskriver [Konfigurera php.ini säkert](https://phpsos.de/sv/ratgeber/php-ini-sicher-konfigurieren/).

> **Viktigt:**
> 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](https://phpsos.de/sv/leistungen/waf-virtuelles-patching/).

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](https://phpsos.de/sv/leistungen/php-patch-service/) 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.

## Källor

- [php.net: säkerhetsmeddelanden](https://www.php.net/)
- [BSI: Tysklands federala myndighet för informationssäkerhet](https://www.bsi.bund.de/)
- [OWASP Cheat Sheets](https://cheatsheetseries.owasp.org/)