PHP2Shell: wat je er nu al mee kunt doen

Twee kritieke PHP-kwetsbaarheden, ook wel PHP2Shell genoemd (CVE-2026-109618 en CVE-2026-109619), stellen een aanvaller in staat om code uit te voeren op een webserver zonder in te loggen. PHP scoort beide kwetsbaarheden een 9,2 op 10 en brengt op 21 oktober 2026 om 14:00 UTC patches uit. Details lekten een dag eerder uit en er zijn al aanvallen gemeld.

Als uw website op PHP draait, kunt u vandaag nog het volgende doen, van de definitieve oplossing tot tijdelijke maatregelen. Voor de volledige technische achtergrond en een actuele tijdlijn, lees verder. Advies van Sansec.

1. Update PHP zo snel mogelijk.

Het updaten van PHP is de enige echte oplossing. Al het andere in dit artikel verlaagt het risico slechts tot die tijd.

• Verwachte gecorrigeerde versies: 8.5.12, 8.4.27, 8.3.36 en 8.2.35. Deze nummers zijn afkomstig van beveiligingsonderzoekers en Linux-distributietrackers; PHP zelf bevestigt ze pas bij de release.
• Oudere versies (8.1, 8.0, 7.x, 5.x) Deze apparaten zijn aan het einde van hun levenscyclus en er is geen officiële oplossing meer voor. Als u een van deze apparaten gebruikt, plan dan nu een upgrade en blijf de onderstaande tijdelijke oplossingen gebruiken.
• Controleer of uw pakket de oplossing daadwerkelijk bevat. Het versienummer alleen kan misleidend zijn, omdat distributies vaak fixes terugporteren. Zoek naar het CVE-nummer in de changelog, bijvoorbeeld met apt changelog php8.3-cli (Debian/Ubuntu) of rpm -q --changelog php (RHEL/Alma/Rocky).
• Start PHP opnieuw na de update. (Bijvoorbeeld systemctl restart php8.3-fpm), anders blijft de oude code draaien.
• Op gedeelde hosting, Vraag je hostingprovider wanneer ze de gepatchte PHP-versie zullen uitrollen.

2. Schakel de voortgang van het uploaden van sessies uit.

Uit eerste analyses blijkt dat de voortgangsfunctie voor sessie-uploads van PHP, die standaard is ingeschakeld en wordt geactiveerd wanneer een bestand wordt geüpload, de oorzaak is. Door deze functie uit te schakelen en de strikte sessiemodus in te schakelen, verkleint u de kans op een beveiligingslek. Dit lost het probleem echter niet op en beveiligingsonderzoekers waarschuwen dat het mogelijk slechts één van de twee kwetsbaarheden blokkeert.

Voeg dit toe aan php.ini, .user.ini of de PHP-instellingen van uw hostingprovider:

sessie.upload_progress.enabled = Uit sessie.use_strict_mode = 1

Als je PHP-FPM gebruikt, kun je dit ook per pool instellen:

php_admin_flag[session.upload_progress.enabled] = off

Herlaad PHP daarna. Slechts weinig websites maken gebruik van voortgangsbalken voor uploads die op deze functie gebaseerd zijn, dus deze wijziging veroorzaakt zelden problemen.

3. Blokkeer uploads op de webserver (nginx)

De bekende aanvalspaden maken gebruik van multipart-verzoeken, het formaat dat browsers gebruiken om bestanden te uploaden. Door deze verzoeken aan de webserver te blokkeren, worden ze gestopt voordat ze PHP bereiken. Sansec raadt dit aan als een tijdelijke maatregel.

Voeg dit toe aan je server { } blok, buiten elk locatie:

if ($http_content_type ~* "multipart/form-data") { rewrite ^ /__upload_blocked last; } location = /__upload_blocked { internal; default_type text/plain; return 403 "Uploaden is momenteel niet toegestaan vanwege een grote bug. We zijn binnenkort weer beschikbaar.\n"; }

Bezoekers die nu proberen iets te uploaden, krijgen een duidelijke melding in plaats van een kale foutpagina. intern lijn betekent dat niemand open kan gaan /__upload_blocked rechtstreeks, en uw andere foutpagina's blijven ongewijzigd.

Testen en opnieuw laden:

nginx -t && nginx -s reload curl -i -F "x=1" https://yoursite.example/ curl -i -F "x=1" https://yoursite.example/some/subpage

Beide krul tests zouden moeten retourneren 403 met het bericht. Als er nog steeds een subpagina laadt, controleer dan of de als zit direct in server { } en niet binnenin een locatie, en dat je de bewerking hebt gedaan server Dit blok zorgt ervoor dat de site daadwerkelijk wordt geladen. Een normale paginaaanvraag zonder upload zou nog steeds moeten werken.

4. Blokkeer uploads op de webserver (Apache / .htaccess)

Voeg dit toe aan de Apache 2.4-configuratie. .htaccess in de rootmap van je document. Het werkt overal in het bestand, ook boven of onder de regels van je CMS zelf:

Foutmelding 403 "Uploaden is momenteel niet toegestaan vanwege een ernstige bug. Het is binnenkort weer mogelijk." Alles vereist geweigerd

Apache weigert het verzoek voordat er herschrijfregels worden uitgevoerd, dus elke URL wordt gedekt, niet alleen de homepage. Een versie gebaseerd op RewriteRule [F] Dit kan gemakkelijk fout gaan: als het onder de regels van een CMS wordt geplaatst, blokkeert het alleen de homepage, terwijl subpagina's nog steeds PHP kunnen bereiken.

• Gebruik de .htaccess Apache leest de gegevens voor je website. Voor Magento 2 is dat vaak de in pub/.
• Een submap met een eigen .htaccess, Een tweede WordPress-installatie, bijvoorbeeld, heeft mogelijk hetzelfde blok nodig.
• Een 500-foutmelding na het opslaan betekent meestal dat uw host deze instructies niet toestaat. .htaccess. Vraag hen om dit toe te staan of om de regel toe te voegen aan de serverconfiguratie.

Test de homepage en minstens één subpagina. Beide zouden een resultaat moeten geven. 403 met de volgende boodschap:

curl -i -F "x=1" https://yoursite.example/ curl -i -F "x=1" https://yoursite.example/some/subpage

Als een subpagina nog steeds de pagina zelf retourneert, is de blokkering niet van kracht voor die URL.

Wat je kunt verwachten en wanneer je het ongedaan kunt maken.

De webserver blokkeert alle multipart-verzoeken, niet alleen bestandsuploads. Verwacht dat deze niet meer werken totdat je de blokkering opheft:

• Bestanden en afbeeldingen uploaden, ook vanuit uw beheerdersgedeelte of CMS.
• Sommige standaardformulieren, zoals contactformulieren of productbewerkingsformulieren, worden als meerdelige formulieren verzonden.
• Achtergronduploads in JavaScript kunnen een algemene foutmelding weergeven in plaats van uw bericht.

De PHP-instellingen uit stap 2 veroorzaken zelden problemen en kunnen zo blijven. Verwijder de blokkering van de webserver zodra PHP is bijgewerkt en je de oplossing in de changelog van je pakket hebt bevestigd. Herlaad vervolgens nginx of Apache en test een upload.

Verder lezen

• Kritieke PHP RCE: CVE-2026-109618 en CVE-2026-109619 (Sansec): advies, maatregelen ter beperking van de risico's en een live tijdlijn
• Aanstaande kritieke PHP-beveiligingsupdate (PHP-aankondiging)
• Ernstige beveiligingswaarschuwing: PHP is kwetsbaar voor kritieke RCE-aanvallen. (Patchstack)
• PHP2Shell: wat beschermt je eigenlijk vóór de patch? (The Hacker News)

Laatst bijgewerkt op 21 oktober 2026