# Symfony-sikkerhed efter PHP2Shell: sådan sikrer I projekter og workers

> Sikr Symfony-projekter efter PHP2Shell: kontrollér PHP med bin/console about, genstart Messenger-workers, og gennemgå secrets, cache og profiler.

Kilde: https://phpsos.de/da/plattformen/symfony/  
Status: 25.10.2026  
Udbyder: PHP SOS, PHP-nødhjælp og serversikkerhed. Akut hjælp på WhatsApp: https://wa.me/491736494914?text=Hej%20PHP%20SOS%2C%20vi%20har%20brug%20for%20hj%C3%A6lp%20med%20vores%20PHP-server.%20Firma%3A%20%E2%80%A6%20Website%3A%20%E2%80%A6

**Kort sagt:** Symfony-sikkerhed efter PHP2Shell betyder: patch PHP, genstart alle processer inklusive Messenger-workers, og kontrollér derefter secrets, cache og profiler. Sårbarheden ligger i PHP, ikke i Symfony; en Symfony-opdatering alene lukker den ikke.

## Hvorfor PHP2Shell berører ethvert Symfony-projekt

Symfony er grundlaget for mange virksomhedsapplikationer, API'er og portaler og sidder desuden i systemer som Shopware 6 og Contao. PHP-sårbarhederne CVE-2026-109618 og CVE-2026-109619 gør det ifølge PHP-teamet muligt at køre skadelig kode uden login. Om applikationen er programmeret rent, spiller ingen rolle for det.

PHP-teamet vurderer risikoen som højest ved mod_php, men også PHP-FPM, php-cgi, FrankenPHP og LiteSpeed er berørt. Symfony-projekter, der via Symfony Runtime drives med FrankenPHP eller andre vedvarende kørende servere, kræver efter opdateringen en fuldstændig genstart eller et nyt image.

## Symfony-sikkerhed: kontrollér PHP-version og processer

`php bin/console about` viser Symfony-version, miljø, debug-tilstand og kommandolinjens PHP-version. Webforespørgslerne kører dog via PHP-FPM eller en applikationsserver, og det kan være en anden version. Kontrollér begge veje, eller lad dem bekræfte af driftsleverandøren.

Rettede upstream-versioner er 8.5.12, 8.4.27, 8.3.36 og 8.2.35; distributioners backports bærer ofte ældre numre. Hvilke PHP-versioner jeres Symfony-version understøtter, kontrollerer I ifølge systemkravene i dokumentationen på symfony.com.

```bash
# Vis miljø, debug-tilstand og PHP-version
php bin/console about
# Lad Messenger-workers afslutte efter den aktuelle besked
php bin/console messenger:stop-workers
# Kendte sårbarheder i afhængigheder
composer audit
```

Kører der flere instanser bag en load balancer eller i containere, skal hver enkelt være patchet og genstartet. En glemt instans betjener fortsat en del af forespørgslerne med gammelt PHP.

Messenger-workers, cron-kommandoer og andre baggrundsprocesser indlæser PHP én gang ved start. Indtil de genstartes, kører de med det gamle PHP i hukommelsen. En proceshåndtering skal starte dem op igen efter stoppet.

## Hvor Symfony-applikationer er sårbare

| Sted | Indhold | Kontrolpunkt |
|---|---|---|
| `.env`, `.env.local`, `.env.local.php` | Miljøvariabler, ofte database og API-nøgler | ikke tilgængelige i webroden, forny værdier ved mistanke |
| `config/secrets/prod/` | krypterede secrets | den private dekrypteringsnøgle hører ikke hjemme i repositoryet |
| `public/` | Dokumentrod med `index.php` | ekstra PHP-filer |
| `var/cache/prod/` | genereret container og skabeloner som PHP | slet ved mistanke og genskab |
| `var/log/` | Logfiler | sikres |
| `config/packages/security.yaml` | Firewalls, roller, adgangsregler | uventede ændringer |

Cachen er et undervurderet skjulested. Symfony genererer dér PHP-filer, som indlæses ved hver forespørgsel. En ændring i disse filer opdages ikke i repositoryet, fordi cachen ikke er versioneret.

> **Vigtigt:**
> I produktion hører `APP_ENV=prod` og `APP_DEBUG=0` hjemme, og WebProfilerBundle må ikke være aktivt dér. En offentligt tilgængelig profiler under `/_profiler` afslører konfiguration og forespørgselsdata.

## Admin-områder, bundles og afhængigheder

Symfony-projekter har afhængigt af opbygningen egne admin-områder, ofte med bundles som EasyAdmin eller Sonata. Kontrollér i `security.yaml`, hvilke stier der kræver hvilke roller, og i databasen, hvem der har disse roller. Admin-stier, der kun bruges internt, bør være begrænset til kendte netværk på webserverniveau.

Bundles og Composer-pakker er fremmed kode med egne sårbarheder. `composer audit` viser kendte problemer; mere udførligt står det under [Kontrollér Composer-afhængigheder for sårbarheder](https://phpsos.de/da/ratgeber/composer-abhaengigkeiten-pruefen/). Forældede pakker er desuden den hyppigste grund til, at en PHP-opgradering i Symfony-projekter tager længere end planlagt.

## Hvad en Symfony-opdatering kan, og hvad den ikke kan

En opdatering af Symfony-komponenter lukker fejl i frameworket. Den patcher ikke PHP, genstarter ikke workers, fornyer ikke udsivede secrets og fjerner ikke en manipuleret cache. Om der er tegn på et angreb, beskriver [Er jeg allerede kompromitteret?](https://phpsos.de/da/php2shell/bin-ich-gehackt-anzeichen/). Da der ikke findes bekræftede Indicators of Compromise, hjælper især observation af usædvanlig adfærd, f.eks. uventede processer eller udgående forbindelser.

Leveres projektet som container, hører det nye PHP hjemme i basis-imaget. Byg imaget på ny, selv om der ikke er ændret noget i koden, og udrul det i alle miljøer. Et blik i Dockerfilen viser, hvilket basis-image der bruges; et fast sat gammelt tag forhindrer ellers, at det nye build overhovedet får det patchede PHP. Enkeltheder står under [Patch PHP i Docker-containere](https://phpsos.de/da/php2shell/docker-container-patchen/).

## Hvordan hjælper PHP SOS konkret?

- Vi fastslår, hvilket PHP web, CLI og workers i jeres Symfony-projekt bruger, og følger den ordnede genstart.
- Vi sikrer logs fra 20.10.2026 og afstemmer koden på serveren med jeres repository.
- Vi kontrollerer miljøfiler, secrets, cache, profiler-indstillinger og admin-roller.
- Til den løbende observation af processer og forbindelser tilbyder vi [sikkerhedsovervågning](https://phpsos.de/da/leistungen/security-monitoring/).


## Ofte stillede spørgsmål

**Er Symfony berørt af PHP2Shell?**  
Symfony har ikke selv en ny sårbarhed. PHP2Shell sidder i PHP, altså i kørselsmiljøet for enhver Symfony-applikation. Sårbarheden lukkes af en PHP-opdatering eller en bekræftet backport og genstart af alle PHP-processer.

**Hvordan stopper jeg Messenger-workers efter en PHP-opdatering?**  
Med php bin/console messenger:stop-workers bliver kørende workers bedt om at afslutte efter den aktuelle besked. En proceshåndtering som Supervisor eller systemd genstarter dem så med det nye PHP.

**Hvorfor er Symfony-profileren farlig i produktion?**  
Profileren viser forespørgsler, konfiguration og ofte miljøvariabler. Er den aktiv på en offentlig server, kan enhver hente disse oplysninger. Den hører kun hjemme i udviklingsmiljøet.

**Hvad sker der med cachen efter et angreb?**  
Cachen under var/cache indeholder genereret PHP-kode. En angriber kan lægge kode dér, som kører med ved hver forespørgsel. Ved mistanke bør cachen slettes og genskabes fra den kontrollerede kildekode.

## Kilder

- [php.net: Sikkerhedsmeddelelser](https://www.php.net/)
- [Symfony](https://symfony.com/)
- [OWASP Cheat Sheets](https://cheatsheetseries.owasp.org/)
- [Understøttede PHP-versioner](https://www.php.net/supported-versions.php)