Kort gezegd: Virtueel patchen voor PHP overbrugt de tijd tot de echte update is geïnstalleerd. Daarvoor combineren wij regels van een Web Application Firewall met de overbruggingsmaatregelen die php.net over PHP2Shell heeft gepubliceerd, en leggen we meteen de weg naar de reguliere patch vast. Volledige bescherming biedt dat niet, maar het verkleint het risico in de overgangstijd.
Wanneer virtueel patchen voor PHP zinvol is
Het BSI (de Duitse federale dienst voor informatiebeveiliging) adviseert bij PHP2Shell direct te updaten en, als dat niet kan, de webservers tijdelijk van het netwerk te halen. Voor veel bedrijven is geen van beide direct haalbaar: een shop moet bereikbaar blijven, een maatwerktoepassing heeft vóór de update een test nodig, of de server draait met PHP 8.1 en ouder, waarvoor er geen officiële updates meer zijn.
In die gevallen is virtueel patchen een brug. Het vervangt niet de afweging of offline gaan passender zou zijn. Die afweging maakt u, wij leveren de technische inschatting.
Waarom een WAF alleen niet volstaat
Cloudflare meldde waargenomen aanvalspogingen en heeft beschermingsregels uitgerold, maar waarschuwt dat regels op basis van alleen de verzoekgegevens niet volstaan. De reden ligt in de aard van de kwetsbaarheden. Bij CVE-2026-109618 kan een out-of-memory-toestand PHP onderbreken terwijl verzoekgegevens maar gedeeltelijk zijn geïnitialiseerd. Bij CVE-2026-109619 kan de interne toestand na het vrijgeven van geheugen blijven bestaan en door een later verzoek in dezelfde worker worden gebruikt. Zulke fouten hangen af van de toestand van de server, niet alleen van de inhoud van één verzoek.
Daarom zetten wij in op meerdere lagen: WAF-regels vóór de server, overbruggingsmaatregelen in PHP zelf en een verscherpte bewaking van de server. Elke laag vangt een deel op, geen enkele volstaat alleen. Samen geven ze u de tijd om de update ordelijk te installeren.
De overbruggingsmaatregelen volgens php.net
php.net noemt meerdere instellingen die het risico verlagen, uitdrukkelijk zonder volledige bescherming. Belangrijk is dat toepassingen deze waarden niet kunnen overschrijven. Een voorbeeld voor een PHP-FPM-pool met uploads:
; Overbruggingsmaatregelen PHP2Shell (geen volledige bescherming), daarna alle workers herstarten
php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 32M
php_admin_value[upload_max_filesize] = 30M
php_admin_flag[session.upload_progress.enabled] = off
; alleen PHP 8.5:
php_admin_flag[fatal_error_backtraces] = off
Zonder uploads adviseert php.net post_max_size = 8M. Omdat memory_limit wordt opgeheven, hoort er een geheugengrens op het niveau van container of cgroup bij, niet via RLIMIT_AS of RLIMIT_DATA. De instelling session.upload_progress.enabled=0 hoort in php.ini, FPM-pool of serverconfiguratie, niet in ini_set() of .user.ini. Ze is tegelijk de remedie voor de aanwijzing bij CVE-2026-115560. Alle maatregelen op een rij staan onder Spoedmaatregelen als u nog niet kunt patchen.
Overbruggingsmaatregelen werken pas na een herstart van alle PHP-workers. En ze beschermen alleen tegen toekomstige aanvallen: of er eerder al iemand is binnengedrongen, beantwoorden ze niet.
Wanneer offline gaan de betere keuze is
Virtueel patchen is niet in elke situatie het juiste antwoord. Bij sommige constellaties adviseren wij het BSI te volgen en de webserver tijdelijk van het netwerk te halen tot er is gepatcht:
- de server draait met Apache en mod_php, waar het PHP-team het risico het hoogst inschat en een exploit is getoond voordat er zelfs maar toepassingscode draait
- op de server staan bijzonder te beschermen gegevens, bijvoorbeeld gezondheids-, cliënt- of betaalgegevens
- er is geen mogelijkheid de overbruggingsmaatregelen vast in de serverconfiguratie in te stellen, bijvoorbeeld bij bepaalde shared-hostingpakketten
- er zijn al aanwijzingen dat de server is aangevallen
Tijdelijk offline gaan betekent niet dat uw website is gehackt. Sommige aanbieders hebben websites uit voorzorg offline gehaald. Een korte, zakelijke mededelingenpagina voor bezoekers is dan meestal een betere oplossing dan een onverklaarde storing.
Hoe helpt PHP SOS concreet?
- Situatie controleren: wij leggen PHP-versies, werkwijzen en bestaande beschermingslagen zoals CDN, WAF of reverse proxy vast. Bij mod_php wijzen we op het verhoogde risico dat het PHP-team daar ziet.
- Lagen opbouwen: wij activeren of vullen WAF-regels aan, stellen de overbruggingsmaatregelen vast in de serverconfiguratie in en begrenzen het geheugen via container of cgroup. Voor Nginx-opstellingen oriënteren we ons op Nginx met PHP-FPM beveiligen.
- Herstart en test: alle PHP-processen worden herstart, daarna controleren we uploads, formulieren, login en kassa.
- Bewaken: in de overgangstijd letten we extra op crashes van workers, geheugenpieken en ongebruikelijke processen.
- Patch plannen: wij leggen vast wanneer en hoe de reguliere update komt en voeren die uit via de PHP-patchservice.
Wat u krijgt, wat wij nodig hebben en wat we niet beloven
U krijgt een documentatie van alle ingestelde regels en instellingen met motivering, de testresultaten en een tijd- en maatregelenplan voor de echte patch. Van u hebben wij server- of paneeltoegang nodig, toegang tot CDN of WAF indien aanwezig, een technisch aanspreekpunt en informatie over de uploadfuncties van uw toepassingen.
Wij beloven niet dat virtueel patchen een aanval voorkomt. Het verlaagt het risico voor een beperkte tijd. Bij PHP 8.1 en ouder is het geen blijvende toestand; hier hoort de migratie naar een ondersteunde versie in het plan.
Veelgestelde vragen
Wat is virtueel patchen?
Virtueel patchen betekent een bekend lek vóór de toepassing afschermen in plaats van de code zelf te wijzigen. Dat gebeurt meestal via een Web Application Firewall of configuratiewijzigingen. Het is een overbrugging, geen vervanging van de update.
Volstaat de WAF van mijn CDN-aanbieder tegen PHP2Shell?
Op zichzelf in de regel niet. Cloudflare heeft beschermingsregels uitgerold, maar waarschuwt zelf dat regels op basis van alleen de verzoekgegevens niet volstaan. De WAF is een extra laag naast overbruggingsmaatregelen en patch.
Hoe lang mag ik op virtueel patchen vertrouwen?
Zo kort mogelijk. Het moet de tijd tot de reguliere update overbruggen, bijvoorbeeld tot er een onderhoudsvenster vrij is of een toepassing is getest. Bij PHP 8.1 en ouder hoort daar een migratieplan bij.
Kunnen de overbruggingsmaatregelen mijn website verstoren?
Ja, dat is mogelijk. Kleinere uploadgrenzen kunnen grote bestandsuploads verhinderen, en het uitschakelen van session upload progress raakt voortgangsindicatoren bij het uploaden. Wij testen de belangrijkste functies na elke wijziging.