Kort sagt: Symfony-säkerhet efter PHP2Shell innebär: patcha PHP, starta om alla processer inklusive Messenger-workers och därefter kontrollera secrets, cache och profiler. Sårbarheten finns i PHP, inte i Symfony; en Symfony-uppdatering ensam stänger den inte.
Varför PHP2Shell berör varje Symfony-projekt
Symfony är grunden för många företagsapplikationer, API:er och portaler och finns dessutom i system som Shopware 6 och Contao. PHP-sårbarheterna CVE-2026-109618 och CVE-2026-109619 gör det enligt PHP-teamet möjligt att köra skadlig kod utan inloggning. Om applikationen är rent programmerad spelar ingen roll för detta.
PHP-teamet bedömer risken som högst vid mod_php, men även PHP-FPM, php-cgi, FrankenPHP och LiteSpeed berörs. Symfony-projekt som drivs via Symfony Runtime med FrankenPHP eller andra ständigt körande servrar behöver efter uppdateringen en fullständig omstart eller en ny image.
Symfony-säkerhet: kontrollera PHP-version och processer
php bin/console about visar Symfony-versionen, miljön, felsökningsläget och kommandoradens PHP-version. Webbanropen går dock via PHP-FPM eller en applikationsserver, och det kan vara en annan version. Kontrollera båda vägarna eller låt driftansvariga bekräfta dem.
Åtgärdade upstream-versioner är 8.5.12, 8.4.27, 8.3.36 och 8.2.35; distributionernas backports bär ofta äldre nummer. Vilka PHP-versioner er Symfony-version stöder kontrollerar ni enligt systemkraven i dokumentationen på symfony.com.
# Visa miljö, felsökningsläge och PHP-version
php bin/console about
# Låt Messenger-workers avsluta sig efter det aktuella meddelandet
php bin/console messenger:stop-workers
# Kända sårbarheter i beroenden
composer audit
Körs flera instanser bakom en lastbalanserare eller i containrar måste varje enskild vara patchad och omstartad. En bortglömd instans fortsätter att betjäna en del av förfrågningarna med gammalt PHP.
Messenger-workers, cron-kommandon och andra bakgrundsprocesser laddar PHP en gång vid start. Tills de har startats om körs de med det gamla PHP i minnet. En processhanterare måste starta upp dem igen efter stoppet.
Var Symfony-applikationer är sårbara
| Plats | Innehåll | Kontrollpunkt |
|---|---|---|
.env, .env.local, .env.local.php |
Miljövariabler, ofta databas och API-nycklar | inte åtkomliga i webroot, förnya värden vid misstanke |
config/secrets/prod/ |
krypterade secrets | den privata dekrypteringsnyckeln hör inte hemma i repositoryt |
public/ |
Dokumentrot med index.php |
ytterligare PHP-filer |
var/cache/prod/ |
genererad container och mallar som PHP | radera och bygg om vid misstanke |
var/log/ |
Loggar | säkra |
config/packages/security.yaml |
Brandväggar, roller, åtkomstregler | oväntade ändringar |
Cachen är ett underskattat gömställe. Symfony genererar där PHP-filer som laddas vid varje förfrågan. En ändring i de filerna syns inte i repositoryt, eftersom cachen inte versionshanteras.
I produktion ska APP_ENV=prod och APP_DEBUG=0 gälla, och WebProfilerBundle får inte vara aktivt där. En offentligt nåbar profiler under /_profiler avslöjar konfiguration och förfrågningsdata.
Administrationsområden, bundles och beroenden
Symfony-projekt har beroende på uppbyggnad egna administrationsområden, ofta med bundles som EasyAdmin eller Sonata. Kontrollera i security.yaml vilka sökvägar som kräver vilka roller, och i databasen vem som har dessa roller. Administratörssökvägar som bara behövs internt bör begränsas till kända nät på webbserversnivå.
Bundles och Composer-paket är främmande kod med egna sårbarheter. composer audit visar kända problem; en utförligare genomgång finns under Kontrollera Composer-beroenden för sårbarheter. Föråldrade paket är dessutom den vanligaste orsaken till att en PHP-uppgradering tar längre tid än planerat i Symfony-projekt.
Vad en Symfony-uppdatering klarar och inte klarar
En uppdatering av Symfony-komponenter stänger fel i ramverket. Den patchar inte PHP, startar inga workers om, förnyar inga läckta secrets och tar inte bort en manipulerad cache. Om det finns tecken på en attack beskriver Är jag redan komprometterad?. Eftersom det inte finns några bekräftade kompromissindikatorer (Indicators of Compromise) hjälper framför allt observation av ovanligt beteende, till exempel oväntade processer eller utgående anslutningar.
Levereras projektet som container hör det nya PHP hemma i basimagen. Bygg om imagen även om koden inte har ändrats, och rulla ut den i alla miljöer. En titt i Dockerfile visar vilken basimage som används; en fast satt gammal tagg förhindrar annars att ombyggnaden över huvud taget får det patchade PHP. Detaljer finns under Patcha PHP i Docker-containrar.
Hur hjälper PHP SOS konkret?
- Vi fastställer vilket PHP webb, CLI och workers i ert Symfony-projekt använder och följer med vid den ordnade omstarten.
- Vi säkrar loggar från och med den 20 oktober 2026 och jämför koden på servern med ert repository.
- Vi kontrollerar miljöfiler, secrets, cache, profilerinställningar och administratörsroller.
- För den löpande övervakningen av processer och anslutningar erbjuder vi säkerhetsövervakning.
Vanliga frågor
Berörs Symfony av PHP2Shell?
Symfony självt har ingen ny sårbarhet. PHP2Shell finns i PHP, alltså i körmiljön för varje Symfony-applikation. Sårbarheten stängs av en PHP-uppdatering eller en bekräftad backport och omstart av alla PHP-processer.
Hur stoppar jag Messenger-workers efter en PHP-uppdatering?
Med php bin/console messenger:stop-workers får körande workers beskedet att avsluta sig efter det aktuella meddelandet. En processhanterare som Supervisor eller systemd startar sedan om dem med det nya PHP.
Varför är Symfony-profilern farlig i produktion?
Profilern visar förfrågningar, konfiguration och ofta miljövariabler. Är den aktiv på en offentlig server kan vem som helst hämta uppgifterna. Den hör bara hemma i utvecklingsmiljön.
Vad händer med cachen efter en attack?
Cachen under var/cache innehåller genererad PHP-kod. En angripare kan lägga kod där som körs vid varje förfrågan. Vid misstanke bör cachen raderas och byggas om från den kontrollerade källkoden.