Je kunt de twee kritieke PHP-zwakheden die bekendstaan als PHP2Shell niet volledig blokkeren vóór de fix van vandaag, en de ene instelling die als tijdelijke oplossing rondgaat is op zichzelf niet voldoende, zegt nu het beveiligingsbedrijf dat die instelling heeft voorgesteld.
PHP brengt de patch uit om 14:00 UTC op 21 oktober voor twee kwetsbaarheden die het beoordeelt met een 9,2 van 10, en heeft geen eigen workaround gegeven. Totdat je die kunt installeren, verklein je je risico door blootgestelde PHP-instanties van internet te halen of achter toegangscontroles te plaatsen, te beperken wat een gecompromitteerde server kan bereiken, en de update klaar te hebben om toe te passen zodra die beschikbaar is.
Cloudflare meldt vroege pogingen tot misbruik en heeft noodregels uitgerold voor sites die via hun dienst lopen; die noemt het een tussenoplossing totdat je patched. Er is geen compromis bevestigd, de publieke exploitcode die rondgaat is niet getoond als werkend, en geen van de twee fouten stond bij het laatste controlemoment in CISA’s catalogus van bekende uitgebuite kwetsbaarheden.
PHP heeft nog niet gezegd welke versies getroffen zijn, welk onderdeel van PHP betrokken is, of dat een instelling het risico verandert; het zegt dat de volledige details en de gefixte versies samen met de release bekendgemaakt worden.
⚡ UPDATE — PHP brengt noodpatches uit voor twee kritieke PHP2Shell RCE-kwetsbaarheden nu exploitpogingen opduiken
Op het moment van schrijven was die release nog niet uit. Dus niemand buiten de groep die de fouten vond kan testen of een gegeven verdediging werkt, wat de reden is dat het advies hieronder gericht is op risicobeperking en niet op het beloven van veiligheid.
De instelling die men je vertelde te veranderen is geen bescherming
De workaround die op sociale media en in beveiligingsblogs circuleert is één regel in een PHP-configuratiebestand: session.upload_progress.enabled=0. Die zet Session Upload Progress uit, een PHP-functie die standaard aanstaat en bijhoudt hoever een bestandsoverdracht gevorderd is zodat een ander verzoek daarover kan informeren.
GMO Flatt Security, een beveiligingsbedrijf uit Tokio, adviseerde op 21 oktober vroeg op de dag om deze instelling te zetten. Het zei toen niet zeker te weten of de wijziging de kwetsbaarheden volledig oplost, maar meende dat het waarschijnlijk in sommige gevallen zou helpen.
Later diezelfde dag trok het bedrijf dat advies deels terug. In een update met tijdstempel 14:00 Japanse tijd (05:00 UTC) stelde het dat die instelling op zichzelf geen volledige oplossing biedt en dat aanvallen die eromheen werken worden verwacht. Het riep beheerders op hun updateprocedure gereed te hebben, te letten op aanvalverkeer vóór de release en de patch meteen toe te passen zodra die uitkomt.
Twee mensen van het PHP-project stelden hetzelfde nog duidelijker. Als antwoord op iemand die suggereerde dat de upload-progress-instelling de fout zou kunnen patchen schreef Gina Peter Banyard, PHP-coreontwikkelaar en documentatieschrijfster gefinancierd door de PHP Foundation: “Het enige wat ik kan zeggen is dat de enige mitigatie het patchen / updaten van PHP is. Ik weet helaas te veel.” Joe Ferguson, release manager voor het aanstaande PHP 8.6, vatte het korter samen: “ini-instellingen redden je niet.”
De instelling is om twee redenen niet te vertrouwen. GMO Flatt verwacht een manier om eromheen te komen maar heeft niet gezegd wat dat is. En het hele idee dat de fout in Session Upload Progress zit is een gok: PHP heeft dat niet bevestigd, het bedrijf zelf zei dat die stelling alleen geldt voor zover hun eigen onderzoek overeenkomt met PHP2Shell, en een onafhankelijke code-audit stelt dat de specifieke bug die anderen in die feature beschrijven niet in de vrijgegeven PHP-versies aanwezig is. Die audit komt van een anoniem account en PHP’s eigen broncode zal het definitief uitsluitsel geven, maar het is nog een reden om de instelling niet als schild te beschouwen.
Niet iedereen is het daarmee eens. Eén leverancier, Upwind, noemt de instelling nog steeds als een onmiddellijke mitigatie en geeft daarin de analyse van een andere onderzoeker door in plaats van eigen tests. watchTowr, dat één van de kwetsbaarheden reproduceerde, zegt dat “er op dit moment geen bevestigde patch of workaround is.”
Als je het al hebt ingesteld
Niemands vraagt je de wijziging ongedaan te maken. De waarschuwing is alleen dat je die niet als bescherming moet beschouwen. De handleiding van PHP adviseert het uitschakelen van de feature al wanneer een applicatie geen upload-progressbalken gebruikt, omdat de opgeslagen bestandsnamen en veldnamen “niet gevalideerd zijn en PHP-code kunnen bevatten.” Als je de instelling per ongeluk op een plaats hebt uitgeschakeld die ze nodig heeft, is het enige nadeel dat upload-progressbalken niet meer werken.
Controleer dat de wijziging daadwerkelijk van kracht is in het proces dat het webverkeer afhandelt, niet alleen op de command line. De instelling is INI_PERDIR, dus je kunt hem zetten in php.ini, .htaccess of .user.ini.
Een .user.ini-bestand wordt alleen gelezen door de CGI- en FastCGI-versies van PHP, niet door de Apache-module, en PHP leest het standaard maar elke 300 seconden opnieuw in, dus een wijziging kan daar vijf minuten duren om van kracht te worden.
Bij de Apache-module gebruik je .htaccess of de serverconfiguratie. Bevestig de waarde op PHP-FPM of mod_php — afhankelijk van wat jouw site bedient — en niet alleen met php -i in de shell.
Als je om 14:00 UTC kunt patchen
Bereid alles nu voor. GMO Flatt raad aan je update-stappen en de checks die je daarna uitvoert te controleren, een eventuele configwijziging te oefenen en de juiste mensen en goedkeuringen klaar te zetten voor een mogelijke noodrestart. Zodra de fix beschikbaar is, update je de runtime die webverzoeken afhandelt — dat is PHP-FPM, mod_php of CGI — en niet de applicatie erbovenop.
PHP brengt fixes alleen uit voor zijn vier ondersteunde branches, 8.2 tot en met 8.5. Welke exacte versies de patch krijgen en hoe ver de kwetsbaarheden teruggaan wordt bij de release bekendgemaakt.
The Hacker News rapporteerde de branch-ondersteuning en de bredere achtergrond in zijn eerdere berichtgeving over de disclosure.
Als je niet meteen kunt patchen, of een niet-ondersteunde versie draait
Als een directe update niet mogelijk is, adviseert CERT-EU organisaties om “te overwegen internet-facing applicaties te isoleren van publieke netwerken totdat een fix toegepast kan worden.” Banyard zei hetzelfde vanuit het project: een server voor een dag uitzetten “kan de meest verstandige stap zijn. Maar dat is verre van redelijk om van de meeste mensen te eisen.” Als je het niet helemaal kunt afsluiten, beperk dan de bereikbaarheid: zet de site achter een VPN, allowlist clients of vereis geauthentiseerde toegang aan de rand, en controleer dat verkeer niet rechtstreeks de origin kan bereiken rond die controles.
Beperk wat een aanvaller krijgt als de server wordt overgenomen. De andere stappen die GMO Flatt aanbeveelt zijn: de hoeveelheid data op de server beperken, privileges verminderen, opgeslagen inloggegevens en cloud-rollen verwijderen en zorgen dat logging aanstaat en veilig wordt bewaard zodat je later onderzoek kunt doen.
Branches ouder dan 8.2, waaronder 8.1, 7.x en 5.x, zijn end-of-life en krijgen geen PHP-fixes meer. Voor die versies moet je upgraden, het systeem offline halen of isoleren; een Linux-distributie of hostingprovider kan op eigen schema een fix terugporten.
Sommige onderzoekers wijzen op een sterkere tussenoplossing dan de sessions-instelling: requests blokkeren die een multipart/form-data-body dragen op de webserver, voordat ze PHP bereiken, omdat de vermoedelijke fout zou zitten in hoe PHP die body leest. Als je dit probeert, blokkeer het dan voor meer dan alleen POST. PHP 8.4 voegde een functie toe, request_parse_body(), die multipart-bodies ook voor andere methodes kan lezen, dus een regel die alleen POST blokkeert kan omzeild worden.
De kosten zijn reëel: bestanduploads en sommige formulieren die multipart zonder bestand gebruiken werken niet meer totdat je de blokkade opheft. En zoals bij de session-instelling, richt dit zich op een vermoedelijke toegangspad, niet op een bevestigd pad, dus het vermindert blootstelling in plaats van veiligheid te garanderen.
Een web application firewall is hier een tussenoplossing, geen definitieve fix, en dat zegt Cloudflare zelf ook. Het heeft noodregels gepusht voor de bekende exploitpaden, ook voor gebruikers van het gratis plan, die haar CTO omschrijft als “alleen EEN TUSSENOPLOSSING” totdat er gepatcht is. Zulke regels zien alleen verkeer dat via Cloudflare loopt, en ze kunnen nieuwe aanvalspaden missen zodra die opduiken.
Als iemand anders jouw PHP beheert
Het updaten van WordPress, Laravel of een andere applicatie werkt de onderliggende PHP-runtime niet bij; die komt uit het serverspakket, je hostingprovider of het containerimage. Bij managed of gedeelde hosting, vraag je provider wanneer een gefixeerde PHP-build beschikbaar komt en laat ze paraat staan.
Hostingproviders bouwen hun pakketten pas nadat PHP de fix uitbrengt: CloudLinux zegt bijvoorbeeld dat zijn bijgewerkte pakketten afhangen van de upstream-release en gepost worden zodra ze klaar zijn.
Een valkuil als je PHP via de pakketten van een Linux-distributie draait: Debian, Ubuntu en soortgelijke distros backporten beveiligingsfixes in de versie die je al draait in plaats van je naar een nieuwere versie te brengen, dus een gepatcht pakket kan er nog uitzien als een oude versienummer. Beoordeel niet alleen aan de hand van het versienummer of je gepatcht bent; controleer de changelog van het pakket op de CVE, of vergelijk het exacte pakketversienummer met het advies van je distributie.
Wat te controleren wanneer de release uitkomt
Misbruikpogingen zijn vroeg en onbegrepen. Cloudflare rapporteert opkomende pogingen; watchTowr zegt één van de fouten te hebben gereproduceerd maar heeft geen aanvallen gerapporteerd; de circulerende publieke exploitcode is niet aangetoond als effectief; en geen van de twee fouten stond op 21 oktober in CISA’s catalogus van bekende uitgebuite kwetsbaarheden.
Een onderzoeker heeft een video geplaatst die de exploitketen zou demonstreren, en de eerder genoemde audit stelt dat de circulerende proof-of-conceptcode niet afgaat tegen vrijgegeven PHP-versies. Behandel dit alles als een momentopname die per uur kan veranderen.
Wanneer de fix uitkomt, controleer dan welke gefixeerde versie voor jouw branch beschikbaar is, welke versies PHP als getroffen aanduidt, of PHP een instelling als mitigatie bevestigt of weerlegt, en of er codewijzigingen in de session-component zitten — dat geeft ook antwoord op de discussie over waar de fout precies zit.
De gefixte versies en het advies verschijnen op php.net en via PHP’s GitHub security advisories, waar het project zijn eigen identificaties toekent. Na het updaten, controleer je de logs op activiteiten die plaatsvonden voordat je gepatcht had.
