Makers van PHP raden alsnog mitigatie aan voor minder gevaarlijke potentiële bug

De makers van PHP raden aan om naast het patchen van de recente bugs ook een mitigatie door te voeren. Volgens de makers is het in zeldzame gevallen alsnog mogelijk dat een aanvaller de bug uitbuit. Dat is echter dermate ingewikkeld dat PHP dat pas tijdens een komende release officieel aanpast.

De ontwikkelaars achter programmeertaal PHP schrijven dat in een nieuwe advisory. Er zit een potentiële remote code execution-kwetsbaarheid in PHP, die zelfs na de recente bugfixes nog niet helemaal verdwenen is.

Om dat risico te beperken raadt PHP aan om session.upload_progress.enabled=0 in te stellen. Dat was al een mitigatie die PHP voorstelde bij CVE-2026-109619, maar de makers raden ook na het patchen daarvan aan die mitigatie door te voeren.

In 'een ongebruikelijke combinatie van configuratie- en applicatiecode' kan de kwetsbaarheid alsnog worden uitgebuit. De makers zeggen dat daarvoor bepaalde configuraties moeten worden ingesteld, maar dat geldt alleen voor applicaties waarin de serialize-handler niet tijdens runtime wordt veranderd. "Aangezien deze set-up in de praktijk onwaarschijnlijk is, behandelen we dit tijdens een normale releasecyclus", zeggen de ontwikkelaars.

Het nieuwe probleem is dus gerelateerd aan een van de twee bugs die eerder deze week voor problemen zorgden. Door die bugs haalden veel diensten hun websites preventief offline. Ook Tweakers deed dat. Tweakers schreef daarna een achtergrondverhaal over de bug en een tijdlijn.

Reacties (17)

[kuurtjes]

"An application must set session.serialize_handler to php_binary or php_serialize in its configuration and then switch it to php at runtime with ini_set() before calling session_start(). Session upload progress must also still be enabled."

https://www.php.net/index.php#2026-10-23-1

Dit is een zeer zeldzame cofiguratie.

[RoestVrijStaal]

Wat zou een geldige use case zijn om "session.serialize_handler" überhaupt te veranderen, laat staan per arbitraire plek in de codebase?

Als ik zo de documentatie met WayBackMachine vergelijk, lijkt het door die toegevoegde waarschuwing erop dat het vermoeden van een kwetsbaarheid tussen 24 september en 28 september dit jaar bekend is.

[Reactie gewijzigd door RoestVrijStaal op 23 oktober 2026 19:17]

[Deem]

Als je de Nginx Docker container op bijvoorbeeld Unraid gebruikt, kun je deze instelling eenvoudig uitschakelen met het volgende commando:

docker exec Nginx sh -c 'echo "session.upload_progress.enabled=0" >> /config/php/php-local.ini'

Wel even je Nginx docker herstarten en controleren of de instelling daadwerkelijk is uitgeschakeld met:

docker exec Nginx php -i | grep session.upload_progress.enabled

[frackleboom]

Niet direct relevant voor deze mitigatie, maar wel goed om te weten: stel dit bij voorkeur in met php_admin_value of php_admin_flag. Anders kunnen scripts de instelling alsnog aanpassen met ini_set()

Zie ook https://www.php.net/manual/en/configuration.changes.php

[Prince]

Ik raad dit toch niet aan. Dit lost de vulnerability niet op, gewoon de meest voorkomende vorm van het doorsturen van 'eigen' php code.
Dit is nog steeds mogelijk via talloze andere manieren. Denk aan log poisoning, tijdelijke bestanden via php://input, misbruik van php filters, andere php vulnerabilities die een buffer overflow of buffer underflow veroorzaken, argument injection, etc...

Updaten is toch de beste optie.

[Houtenklaas]

Je hebt niet eens de eerste regel van het artikel gelezen denk ik ...

De makers van PHP raden aan om naast het patchen van de recente bugs ook een mitigatie door te voeren. Volgens de makers is het in zeldzame gevallen alsnog mogelijk dat een aanvaller de bug uitbuit.

[Prince]

Ik bedoel met mijn post dat -gezien het gevaar- duidelijk moet zijn dat je primair moet updaten en dat die mitigatie een schijngevoel van veiligheid geeft. Dit is wat CERT-EU, CICA, SANS, etc.. ook aangeven.

Het kan inderdaad geen kwaad om het te doen maar veilig is het hierna zeker niet.

[RobertMe]

Volgens de PHP developers is het hiermee wel degelijk veilig. Updaten naar de nieuwste versie, met patch, en vervolgens is er in uitzonderlijke gevallen nog een kans op een lek/misbruik en dat is, volgens de PHP devs, 100% opgelost als je upload_progress uit zet.

(En ja, bij een niet gepatchte versie is upload_progress maar een halve schijnoplossing die niet alles oplost)

[Gemeni]

Maar updaten kan (nog) niet…

[phray]

Maar alleen updaten is dus ook niet genoeg.

[Deem]

De makers van PHP raden aan om naast het patchen van de recente bugs ook een mitigatie door te voeren. Mijn advies is dan ook niet om deze instelling als vervanging voor een update te gebruiken, maar juist als aanvullende beveiligingsmaatregel bovenop de update.

[DvanRaai89]

docker exec Nginx [...]

Dit hangt volledig af van de naam van de service. De nginx container kan bv. een pure losstaande reverse proxy zijn, en iemands PHP-FPM in een container van een ander, totaal gescheiden (mogelijk ook nginx) project draait.

[...] 'echo "session.upload_progress.enabled=0" >> /config/php/php-local.ini'

Dit is standaard shell output redirection en het aan een bestand appenden; heeft eigenlijk niets met containers te maken.

'echo "session.upload_progress.enabled=0" >> /config/php/php-local.ini' kan iedereen (LXC/Docker/ander OCI/bare-metal/whatever) gebruiken. (Mits 't .ini-pad klopt.)


Verder is docker exec gebruiken niet echt de ideale manier; dat zou je enkel doen als je geen bind mount (volume: [<host>:<container>] in docker-compose.yaml, indien je Docker Compose gebruikt) van je config map hebt. (Dan kun je simpelweg het .ini-bestand buiten de container aanpassen.)
Config'jes "docker exec"-en past niet echt binnen het "IaC"-principe; zodra je de container wipet (docker compose down) of image updatet ben je namelijk je configs kwijt.

Wel even je Nginx docker herstarten [...]

Dat (en het "docker exec nginx"-gebeuren) is enkel relevant indien je zo'n AIO image gebruikt, wat voor veel anderen mogelijk niet het geval is; anders heeft het herstarten van de nginx container weinig zin. In dat geval moet PHP-FPM op een andere manier worden herladen, bijvoorbeeld door een andere container (waar PHP-FPM draait, i.p.v. de webserver) te herstarten.

[Reactie gewijzigd door DvanRaai89 op 23 oktober 2026 17:48]

[Mitchelllll]

Kunstenaars zijn jullie codeurs.

[martyblock]

dit als eerste regel in je .htaccess zetten:

php_flag session.upload_progress.enabled off

[AW_Bos]

De setting in php.ini instellen is nog doeltreffender....

[Servowire]

Wederom een patch die dus niet 100% de boel dekt? Of is dit een storm in een glas water?

Vraag me af of de "hackers" (een zwerm van AI bots) niet ook de backdoor achter zich dicht hebben getrokken tijdens de exploit. En hoeveel hosts zijn nu "backdoored"

Of zijn we nu TE achterdochtig geworden en loopt het allemaal wel los?

[Bedge85]

Nee we zijn niet te achterdochtig geweest, maar het klopt wel dat er nog geen wijdverbreide meldingen zijn over misbruik van het PHP2Shell lek.

LiveOverflow heeft een POC gemaakt om te laten zien dat de lekken daadwerkelijk misbruikt kunnen worden. Hij heeft hier op youtube een video geplaatst. Ik vermoed dat hackers nog geen efficiënte methode hebben gevonden om het lek in grote getallen te misbruiken. Maar ik vermoed dat dit wel in de loop van de tijd komt.