PHP heeft noodbeveiligingsupdates uitgebracht voor twee kritieke kwetsbaarheden die aanvallers in staat zouden kunnen stellen schadelijke code uit te voeren op een webserver zonder in te loggen.

De kwetsbaarheden, geregistreerd als CVE-2026-109618 en CVE-2026-109619 en gezamenlijk PHP2Shell genoemd, zitten in PHP zelf — de programmeertaal achter websites en toepassingen zoals WordPress, Drupal en Joomla. Elk scoort 9,2 uit 10 op het Common Vulnerability Scoring System (CVSS), waarmee beide in de kritieke categorie vallen.

Wat is PHP2Shell?

PHP draait op een webserver, waar het verzoeken van bezoekers afhandelt, informatie uit databases haalt, formulieren verwerkt en pagina's opbouwt. Volgens beveiligingsbedrijf Qualys bestaat PHP2Shell uit twee bugs in de manier waarop de taal geheugen en de status van een webverzoek afhandelt. De kwetsbaarheden zitten in PHP zelf, niet in WordPress, Drupal of Joomla.

WordPress zei in een bericht op X dat de kwetsbaarheden elke server raken die een PHP-applicatie host en dat geen enkele WordPress-update vereist of gepland is. Omdat elke applicatie op een server van dezelfde runtime gebruikmaakt, sluit één gepatchte PHP de kloof voor alle applicaties — en één ongepatchte runtime stelt ze allemaal bloot, hoe actueel hun applicaties en plugins ook zijn.

De eerste kwetsbaarheid, CVE-2026-109618, doet zich voor wanneer PHP tijdens een verzoek zonder geheugen komt te zitten en gegevens half ingesteld achterlaat. De tweede, CVE-2026-109619, treedt op wanneer PHP blijft verwijzen naar verzoekgegevens nadat het onderliggende geheugen is vrijgegeven.

Wiz, een van de bedrijven die de bugs meldden, zei aanvallen te hebben gedemonstreerd die code uitvoeren op WordPress- en Drupal-sites vóór het inloggen. Het bedrijf voegde toe dat één kwetsbaarheid ook het geheugen van een draaiend PHP-proces kan lekken. Een aanv heeft geen account nodig, en wat er daarna gebeurt hangt af van de configuratie van de server en de rechten van het gecompromitteerde PHP-proces.

Wie is kwetsbaar?

PHP zei in zijn aankondiging dat elke installatie die webverzoeken verwerkt risico loopt, waaronder PHP-FPM, Apache met mod_php, php-cgi, FrankenPHP en LiteSpeed. Het project zei dat het risico het grootst is voor Apache's mod_php, met de kanttekening dat een gedemonstreerde exploit een niet-geverifieerd verzoek de aanval kan laten starten vóórdat er applicatiecode draait — wat betekent dat de trigger niet afhankelijk is van een zwakte in de eigen code van de gehoste site.\nWiz zei dat getroffen versies teruggaan tot PHP 5.4 — een reikwijdte die langlopende legacyservers omvat. De gecorrigeerde releases zijn PHP 8.5.12, 8.4.27, 8.3.36 en 8.2.35. PHP 8.1 en ouder ontvangen geen updates meer van het project, al biedt PHP minimale source-backports voor 7.4, 8.0 en 8.1 aan voor wie vanaf broncode bouwt of geen vendorondersteuning heeft.

PHP zei ook dat versie 8.2 aan het eind van het jaar geen beveiligingsfixes meer ontvangt, dus gebruikers op die tak moeten een upgrade plannen. Sommige Linux-distributies en leveranciers kunnen de fixes backporten naar oudere versies; beheerders moeten hun adviezen raadplegen en, waar die ontbreken, een migratie naar een ondersteunde versie plannen. Producten, containers en hostingpanelen die hun eigen PHP meebrengen hebben aparte updates nodig.

Volgens beveiligingsbedrijf Huntress lekten details van de kwetsbaarheden een dag vóór de geplande openbaarmaking online. PHP heeft de release vervroegd en de fixes op 21 oktober gepubliceerd.

Sansec, een ander beveiligingsbedrijf, zei massale misbruik te verwachten nu de patches en technische analyses openbaar zijn. Het bedrijf wees erop dat Cloudflare al vroege aanvallen heeft gemeld. Nu de technische details openbaar zijn en aanvallen al zijn geregistreerd, zijn misbruikpogingen tegen servers die nog niet hebben bijgewerkt het eerste waar verdedigers op moeten letten.

Hoe te handelen

Het bijwerken van WordPress, Drupal, Joomla of een plugin lost geen lek in PHP zelf op. Beheerders kunnen de volgende stappen nemen:

Werk PHP bij. Installeer een gecorrigeerde versie via de pakketbeheerder en controleer daarna of de webserver die gebruikt. WordPress-gebruikers kunnen hun versie zien onder Tools > Site Health > Info > Server, en veel hosts tonen deze ook in hun controlepaneel.

Controleer elke installatie. Bekijk containers, controlepanelen en elke applicatie die zijn eigen PHP meebrengt.

Vraag het je host. Bij shared hosting kan PHP buiten de controle van de beheerder vallen. Vraag de provider of er een patch is geïnstalleerd, en neem dat niet aan. WordPress zei dat hosts mogelijk al patches en firewallregels aan het toepassen zijn, maar raadt desalniettemin aan om bij de host te informeren.

Houd je repository in de gaten. Sansec waarschuwde dat Remi's repository, die veel op PHP-servers voorkomt, op de releasedag de fix nog niet bevatte, en raadde aan de pakketten van de distributie te gebruiken of vanaf broncode te bouwen.

Gebruik mitigaties alleen als noodmaatregel. PHP zei dat er geen volledige mitigaties bestaan en dat bijwerken de enige veilige keuze is. Maatregelen zoals het beperken van verzoekgroottes en het uitschakelen van uploadtracking maken een installatie niet veilig.

Controleer op compromittering. Zoek naar onverwachte processen gestart door PHP, onbekende bestanden en vreemde uitgaande verbindingen. Een patch verwijdert geen malware die al is geplaatst.

Gewone bezoekers kunnen de kwetsbaarheden niet verhelpen, omdat ze op servers zitten en niet op telefoons of laptops. Dat betekent niet dat elke PHP-website is gehackt, maar bijwerken naar een gecorrigeerde versie is de enige volledige oplossing.