PHP2Shell-workarounds uitgelegd: wat session.upload_progress, memory_limit en een firewall werkelijk doen

Het beveiligingsadvies van PHP van 21 oktober 2026 is in één opzicht ongebruikelijk: naast de gepatchte releases noemt het een reeks tussentijdse maatregelen, en het zegt ronduit dat die de blootstelling verkleinen maar een installatie niet veilig maken. Sindsdien zijn de maatregelen in talloze blogposts en supporttickets overgenomen, vaak zonder de voorwaarden die ze laten werken.

Dit artikel loopt ze een voor een langs. De bron is het advies op php.net zelf; we voegen niets toe wat daar niet staat.

Twee lekken, twee soorten workaround

PHP2Shell bestaat uit twee kwetsbaarheden met een verschillend mechanisme, en de workarounds horen elk bij één daarvan.

• CVE-2026-109619 gaat over interne status van een verzoek die kan blijven bestaan nadat het geheugen is vrijgegeven, met de sessiefunctie voor upload progress als bereikbare route. Een later verzoek dat door dezelfde worker wordt afgehandeld, kan die verouderde status dan gebruiken.
• CVE-2026-109618 gaat over situaties waarin het geheugen opraakt. Als PHP een verzoek afbreekt omdat het geheugen op is, kan verzoekgeheugen deels ongeïnitialiseerd achterblijven en kan de opruimcode die foute data als geldig behandelen.

Instellingen die tegen het ene helpen, doen niets tegen het andere, dus je hebt beide groepen nodig.

Workarounds voor CVE-2026-109619

session.upload_progress.enabled = 0. Dit schakelt de functie uit waar de bekende aanvalsroute doorheen loopt. Drie voorwaarden zijn belangrijk:

1. Zet het in php.ini, in de PHP-FPM-poolconfiguratie of in de PHP-configuratie van de webserver. Het advies is expliciet dat ini_set() in applicatiecode en .user.ini-bestanden niet volstaan, omdat de functie draait voordat die code aan de beurt komt.
2. Herstart daarna elke PHP-worker. Configuratie die bij het opstarten is geladen, verandert niet voor draaiende processen.
3. Controleer dat niets in je applicatie op voortgangsbalken voor uploads vertrouwt. Weinig moderne applicaties doen dat.

Op PHP 8.5: fatal_error_backtraces = 0, en daarna de workers herstarten. Deze instelling bestaat niet op oudere reeksen.

Verwijder ongeldige of verouderde instellingen per verzoek die meldingen geven vóór de initialisatie, bijvoorbeeld achterhaalde directieven in .htaccess of .user.ini. De meldingen onderdrukken met error_reporting, display_errors of @ helpt niet; de instelling moet weg.

Los fatale fouten en time-outs op die een aanvaller kan uitlokken. Elke verzoekroute die betrouwbaar eindigt in een fatale fout of een time-out is een kandidaat voor de aanval, dus dit is een goed moment om het foutlogboek van terugkerende fatale fouten te ontdoen.

Workarounds voor CVE-2026-109618

memory_limit = -1. Tegen de intuïtie in, maar het punt is dat de gevaarlijke situatie ontstaat als PHP halverwege een verzoek zijn eigen geheugenlimiet raakt. De limiet weghalen haalt die route weg. Zet hem met php_admin_value in de FPM-pool of in de Apache-configuratie, zodat de applicatie geen eindige limiet kan terugzetten, en controleer dat geen andere configuratielaag er een instelt.

Zonder geheugenlimiet verschuift het beteugelen van een op hol geslagen verzoek naar de laag om PHP heen:

• post_max_size: 8M als de site geen uploads aanneemt, 32M als dat wel zo is, met upload_max_filesize onder post_max_size.
• Verzoeklimieten bij de webserver of proxy, ook voor verzoeken zonder bruikbare Content-Length. In Nginx is dat client_max_body_size; in Apache LimitRequestBody.
• Een geheugenlimiet per container of cgroup die alleen de betrokken worker afbreekt als die zich misdraagt. Het advies waarschuwt specifiek tegen RLIMIT_AS en RLIMIT_DATA, omdat die precies de geheugentekortsituatie binnen het proces veroorzaken die het lek nodig heeft.

Wat een web application firewall toevoegt

Een WAF vóór de site kan de verzoekpatronen blokkeren waarvan bekend is dat ze de lekken uitlokken, en leveranciers hebben regels uitgebracht. Dat is nuttig als tweede laag. Het is geen oplossing: regels herkennen bekende patronen, en het onderliggende lek blijft aanwezig voor elk patroon dat de regels niet dekken. Beschouw een WAF-regel als iets dat uren of dagen koopt, niet als reden om de update uit te stellen.

Het vervolgadvies van 23 oktober

Op 23 oktober voegde PHP een informatief advies toe (CVE-2026-115560). Applicaties die session.serialize_handler tijdens runtime wisselen, van php_binary of php_serialize naar php, moeten session.upload_progress.enabled = 0 aanhouden tot de volgende bugfixrelease. Doet je applicatie dit, wat zeldzaam is, houd de workaround dan ook na het updaten in stand.

Waarom niets hiervan de update vervangt

Elk punt hierboven verkleint de routes die een aanvaller kan gebruiken. Geen enkel punt verwijdert het lek. De formulering van het advies is dat alleen een update een volledige oplossing is, en dat blijft zo nadat elke workaround is toegepast. Gebruik de maatregelen om de periode tot het onderhoudsmoment te overbruggen; laat ze niet het plan worden.

Voor sites op PHP 8.1 of ouder, waar geen release bestaat, kopen de workarounds tijd voor een upgrade naar een ondersteunde reeks. Die upgrade staat beschreven in ons end-of-life-artikel.

Wil je deze instellingen op je eigen hosting laten nakijken, of de update laten uitvoeren, stuur ons dan je websiteadres en hostingprovider.