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.
# 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.
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. 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?. 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.
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.
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.