Kort gezegd: Symfony-beveiliging na PHP2Shell betekent: PHP patchen, alle processen inclusief Messenger-workers herstarten en daarna secrets, cache en profiler controleren. De kwetsbaarheid zit in PHP, niet in Symfony; een Symfony-update alleen sluit haar niet.
Waarom PHP2Shell elk Symfony-project raakt
Symfony is de basis van veel bedrijfsapplicaties, API's en portalen en zit bovendien in systemen als Shopware 6 en Contao. De PHP-kwetsbaarheden CVE-2026-109618 en CVE-2026-109619 maken het volgens het PHP-team mogelijk om zonder inloggen schadelijke code uit te voeren. Of de applicatie netjes is geprogrammeerd, speelt daarbij geen rol.
Het PHP-team beoordeelt het risico bij mod_php als het hoogst, maar ook PHP-FPM, php-cgi, FrankenPHP en LiteSpeed zijn getroffen. Symfony-projecten die via Symfony Runtime met FrankenPHP of andere permanent draaiende servers worden bedreven, hebben na de update een volledige herstart of een nieuw image nodig.
Symfony-beveiliging: PHP-versie en processen controleren
php bin/console about toont Symfony-versie, omgeving, debugmodus en de PHP-versie van de opdrachtregel. De webverzoeken lopen echter via PHP-FPM of een applicatieserver, en dat kan een andere versie zijn. Controleer beide wegen of laat ze door de beheerder bevestigen.
Verholpen upstreamversies zijn 8.5.12, 8.4.27, 8.3.36 en 8.2.35; backports van distributies dragen vaak oudere nummers. Welke PHP-versies uw Symfony-versie ondersteunt, controleert u volgens de systeemeisen in de documentatie op symfony.com.
# Omgeving, debugmodus en PHP-versie weergeven
php bin/console about
# Messenger-workers na het huidige bericht laten stoppen
php bin/console messenger:stop-workers
# Bekende kwetsbaarheden in afhankelijkheden
composer audit
Draaien er meerdere instanties achter een load balancer of in containers, dan moet elke afzonderlijke instantie zijn gepatcht en herstart. Een vergeten instantie bedient een deel van de verzoeken nog met oude PHP.
Messenger-workers, cron-opdrachten en andere achtergrondprocessen laden PHP eenmalig bij het starten. Tot ze opnieuw worden gestart, draaien ze met de oude PHP in het geheugen. Een procesmanager moet ze na de stop weer opstarten.
Waar Symfony-applicaties kwetsbaar zijn
| Plek | Inhoud | Controlepunt |
|---|---|---|
.env, .env.local, .env.local.php |
Omgevingsvariabelen, vaak database en API-sleutels | niet in de webroot opvraagbaar, waarden bij vermoeden vernieuwen |
config/secrets/prod/ |
versleutelde secrets | de privé-ontsleutelingssleutel hoort niet in de repository |
public/ |
Documentroot met index.php |
extra PHP-bestanden |
var/cache/prod/ |
gegenereerde container en templates als PHP | bij vermoeden wissen en opnieuw genereren |
var/log/ |
Logbestanden | veiligstellen |
config/packages/security.yaml |
Firewalls, rollen, toegangsregels | onverwachte wijzigingen |
De cache is een onderschatte schuilplaats. Symfony genereert daar PHP-bestanden die bij elk verzoek worden geladen. Een wijziging in die bestanden valt in de repository niet op, omdat de cache niet wordt geversioneerd.
In productie horen APP_ENV=prod en APP_DEBUG=0, en de WebProfilerBundle mag daar niet actief zijn. Een openbaar bereikbare profiler onder /_profiler geeft configuratie en verzoekgegevens prijs.
Beheergedeelten, bundles en afhankelijkheden
Symfony-projecten hebben afhankelijk van de opzet eigen beheergedeelten, vaak met bundles zoals EasyAdmin of Sonata. Controleer in security.yaml welke paden welke rollen vereisen, en in de database wie die rollen heeft. Beheerpaden die alleen intern nodig zijn, moeten op webserverniveau tot bekende netwerken zijn beperkt.
Bundles en Composer-pakketten zijn vreemde code met eigen kwetsbaarheden. composer audit toont bekende problemen; uitgebreider gaat het onder Composer-afhankelijkheden op kwetsbaarheden controleren. Verouderde pakketten zijn bovendien de meest voorkomende reden waarom een PHP-upgrade in Symfony-projecten langer duurt dan gepland.
Wat een Symfony-update wel en niet doet
Een update van Symfony-componenten dicht fouten in het framework. Ze patcht PHP niet, herstart geen workers, vernieuwt geen weggelekte secrets en verwijdert geen gemanipuleerde cache. Of er aanwijzingen voor een aanval zijn, beschrijft Ben ik al gecompromitteerd?. Omdat er geen bevestigde Indicators of Compromise bestaan, helpt vooral het observeren van ongebruikelijk gedrag, zoals onverwachte processen of uitgaande verbindingen.
Wordt het project als container geleverd, dan hoort de nieuwe PHP in het basisimage. Bouw het image opnieuw, ook als er aan de code niets is veranderd, en rol het uit op alle omgevingen. Een blik in het Dockerfile toont welk basisimage wordt gebruikt; een vastgezette oude tag verhindert anders dat de nieuwe build de gepatchte PHP helemaal niet krijgt. Details staan onder PHP in Docker-containers patchen.
Hoe helpt PHP SOS concreet?
- Wij stellen vast welke PHP web, CLI en workers van uw Symfony-project gebruiken en begeleiden de geordende herstart.
- Wij maken een kopie van logs vanaf 20-10-2026 en vergelijken de code op de server met uw repository.
- Wij controleren omgevingsbestanden, secrets, cache, profilerinstellingen en beheerrollen.
- Voor de lopende bewaking van processen en verbindingen bieden wij security-monitoring aan.
Veelgestelde vragen
Is Symfony getroffen door PHP2Shell?
Symfony zelf heeft geen nieuwe kwetsbaarheid. PHP2Shell zit in PHP, dus in de runtime van elke Symfony-applicatie. De kwetsbaarheid wordt gesloten door een PHP-update of een bevestigde backport en de herstart van alle PHP-processen.
Hoe stop ik Messenger-workers na een PHP-update?
Met php bin/console messenger:stop-workers krijgen lopende workers de opdracht zich na het huidige bericht te beëindigen. Een procesmanager zoals Supervisor of systemd start ze daarna met de nieuwe PHP opnieuw.
Waarom is de Symfony-profiler in productie gevaarlijk?
De profiler toont verzoeken, configuratie en vaak omgevingsvariabelen. Is hij op een openbare server actief, dan kan iedereen deze informatie opvragen. Hij hoort alleen in de ontwikkelomgeving.
Wat gebeurt er na een aanval met de cache?
De cache onder var/cache bevat gegenereerde PHP-code. Een aanvaller kan daar code neerleggen die bij elk verzoek meedraait. Na een vermoeden moet de cache worden gewist en uit de gecontroleerde broncode opnieuw worden gegenereerd.