# php2shell PHP-lekken: wat videosites moeten weten

**Source:** https://vodlix.com/nl/blog/php2shell-php-vulnerability-october-2026  
**Summary:** php2shell voor videobedrijven: de twee PHP-lekken die op 21 oktober 2026 zijn verholpen, welke versies je installeert en hoe Vodlix het voor klanten regelde.  
**Published:** 2026-11-02  
**Publisher:** Vodlix

---

## Key takeaways

Op 21 oktober 2026 bracht PHP 8.5.12, 8.4.27, 8.3.36 en 8.2.35 uit om php2shell te verhelpen, twee kritieke lekken waarmee een niet-geauthenticeerde aanvaller code kan uitvoeren op een PHP-server. Vodlix patchte voordat de lekken openbaar waren, en zijn klanten hoefden niets te doen.

- Draait een onderdeel van je videobedrijf PHP op je eigen servers of hosting, update het dan nu naar een gerepareerde versie, of vraag je host om dat te doen.
- PHP 8.1 en ouder worden niet langer ondersteund, dus die sites hebben een upgrade nodig, niet alleen een patch.
- Lees de advisories van je host en leveranciers: AWS publiceerde bulletin 2026-143-AWS op 21 oktober 2026.
- Op een beheerd platform voert de provider updates als deze voor je uit; bij Vodlix gebruikt alleen de middleware PHP, en die is gepatcht.

Op 21 oktober 2026 bracht het PHP-project PHP 8.5.12, 8.4.27, 8.3.36 en 8.2.35 uit. Deze releases verhelpen twee kritieke kwetsbaarheden, CVE-2026-109618 en CVE-2026-109619, het duo dat bekendstaat als php2shell. Onder de juiste omstandigheden laten ze een niet-geauthenticeerde aanvaller code uitvoeren op een server die PHP draait. De [PHP Foundation](https://thephp.foundation/blog/2026/10/21/todays-php-security-release-and-how-were-strengthening-php-security/) zegt het onomwonden: draai je PHP, update dan nu.

Vodlix patchte zijn systemen voordat de lekken openbaar werden gemaakt. Klanten van Vodlix hoefden niets te doen.

Een patch beschermt niemand zolang hij niet op je server staat. Voor een videobedrijf is dat waar php2shell op neerkomt.

## Wat is php2shell? {#wat-is-php2shell}

php2shell is de naam voor twee verwante remote-code-execution-lekken in PHP, CVE-2026-109618 en CVE-2026-109619. Beide zitten in het geheugenbeheer en de foutafhandeling, onderdelen van PHP die bijna elk verzoek raakt. De advisories van het PHP-project beoordelen ze als kritiek, en de gerepareerde versies verschenen op 21 oktober 2026.

De PHP Foundation en de advisories van het PHP-project verwijzen naar de lekken met hun CVE-nummers; gebruik die dus wanneer je de advisories van je leveranciers en hostingpartijen doorzoekt.

### CVE-2026-109618: geheugencorruptie wanneer PHP zonder geheugen komt te zitten {#cve-2026-109618-geheugencorruptie-wanneer-php-zonder-geheugen-komt-te-zitten}

Als een verzoek precies op het verkeerde moment de memory\_limit van PHP bereikte, kon PHP deels geïnitialiseerde interne gegevens achterlaten en die later als geldig behandelen. Op Apache met mod\_php kan een niet-geauthenticeerd verzoek dit uitlokken voordat er ook maar enige applicatiecode draait, en volgens de PHP Foundation is volledige remote code execution aangetoond met de standaardinstellingen. Remote code execution is ook bevestigd op PHP-FPM via codepaden in de applicatie.

### CVE-2026-109619: verouderde status die overblijft van een eerder verzoek {#cve-2026-109619-verouderde-status-die-overblijft-van-een-eerder-verzoek}

Een fatale fout op het verkeerde moment kon een interne status achterlaten die verwees naar geheugen van een eerder verzoek. Een later verzoek op dezelfde worker kon dat vrijgegeven geheugen vervolgens gebruiken. Volgens de PHP Foundation demonstreerde de melder remote code execution tegen een bestaande applicatie op Apache met mod\_php.

## Welke PHP-versies verhelpen de php2shell-kwetsbaarheid? {#welke-php-versies-verhelpen-de-php2shell-kwetsbaarheid}

De gerepareerde versies zijn PHP 8.5.12, 8.4.27, 8.3.36 en 8.2.35, allemaal uitgebracht op 21 oktober 2026. Elke eerdere release in die vier branches is kwetsbaar, volgens de [advisory van het PHP-project voor CVE-2026-109618](https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w). Draai je PHP 8.1 of ouder, dan is er geen patch voor jouw branch.

| Jouw PHP-branch | Kwetsbaar | Updaten naar |
| --- | --- | --- |
| 8.5 | Lager dan 8.5.12 | 8.5.12 |
| 8.4 | Lager dan 8.4.27 | 8.4.27 |
| 8.3 | Lager dan 8.3.36 | 8.3.36 |
| 8.2 | Lager dan 8.2.35 | 8.2.35 |
| 8.1 en ouder | Niet langer ondersteund | Een ondersteunde branch, zoals 8.5.12 |

[TechCrunch](https://techcrunch.com/2026/10/21/php-armageddon-openai-googles-wiz-find-ancient-holes-panicking-the-internet/) meldt dat de gaten in elke PHP-versie sinds PHP 5 uit 2004 hebben gezeten, en dat PHP 8.1 en ouder niet langer worden ondersteund. Sites op die versies staat meer te wachten dan een kleine update.

## Wie vond de lekken, en wanneer? {#wie-vond-de-lekken-en-wanneer}

Onderzoeker Ryan A van beveiligingsbedrijf Calif meldde de eerste remote code execution aan PHP op 11 augustus 2026, tijdens een audit die op 30 juli 2026 was begonnen. Wiz en OpenAI meldden daarna verdere aanvalspaden. De onderliggende oorzaak gaat terug op een geheugenprobleem dat het PHP-team in 2024 voor het eerst opmerkte.

Het eigen verslag van de PHP Foundation zet de volgorde van de gebeurtenissen op een rij:

1. **2024:** tijdens de eerste externe beveiligingsaudit van PHP in jaren vond een kernontwikkelaar de eerste tekenen van het out-of-memory-probleem. Er werd toen geen concreet aanvalspad gevonden, en de fix bleef liggen.
2. **30 juli 2026:** Calif begon een audit van PHP binnen het programma Patch the Planet.
3. **11 augustus 2026:** Ryan A van Calif meldde een onvoorwaardelijke remote code execution met dezelfde onderliggende oorzaak. OpenAI meldde onafhankelijk dezelfde oorzaak.
4. **24 augustus 2026:** Wiz meldde verdere aanvalsvectoren.
5. **18 september 2026:** OpenAI meldde verdere aanvalsvectoren.
6. **21 oktober 2026:** PHP bracht de gerepareerde versies uit.

De Foundation is eerlijk over het gat: ze noemt de vertraging na 2024 „een structureel falen” van het besluitvormingsproces van het beveiligingsteam en zijn gebrek aan middelen, en zegt dat het team zijn werkwijze verandert.

## Hoe ernstig is php2shell, en hoe heeft het internet gereageerd? {#hoe-ernstig-is-php2shell-en-hoe-heeft-het-internet-gereageerd}

Het is ernstig omdat PHP overal zit en het ergste scenario een aanvaller is die code op je server uitvoert. TechCrunch meldt dat PHP ongeveer 70% van de websites aandrijft, en dat de Amerikaanse National Security Agency adviseerde een site offline te halen als die niet meteen gepatcht kan worden.

TechCrunch meldt ook dat de gaten aanvallers toegang kunnen geven tot het bestandssysteem van een server of tot een database die de webapp gebruikt. Op het moment van zijn bericht op 21 oktober zei OpenAI dat de lekken door onderzoekers waren gevonden vóór aanvallers, zonder meldingen van misbruik in het wild. De openbaarmaking verandert dat, want de details zijn nu publiek.

Cloudproviders kwamen dezelfde dag in actie. [AWS publiceerde beveiligingsbulletin 2026-143-AWS](https://aws.amazon.com/security/security-bulletins/2026-143-aws/) op 21 oktober 2026, gemarkeerd als „Important (requires attention)”, voor PHP-webruntimes die door beide CVE's worden geraakt.

## Wat betekent php2shell voor een streamingplatform of videosite? {#wat-betekent-php2shell-voor-een-streamingplatform-of-videosite}

Het betekent dat je elk onderdeel van je videobedrijf dat PHP draait moet controleren, niet alleen de speler. Een streamingsite is een winkel, een inlogpagina, een betaalflow en vaak ook een marketingsite of blog. Als een daarvan PHP draait op een server die jij of je host beheert, heeft die een gerepareerde versie nodig.

Beveiliging is hier niet alleen een IT-taak. Het is een zakelijke kwestie. Een videosite die offline gaat om op een patch te wachten, verkoopt geen abonnementen en verhuur meer zolang hij uit de lucht is.

WordPress is een veelvoorkomend geval. TechCrunch meldt dat WordPress zei dat het lek niet specifiek voor WordPress is, en dat sites die erop draaien hun servers moeten patchen en moeten samenwerken met hun hostingbedrijven.

Patchen is één beschermingslaag. Onze gids over [de essentials van OTT-beveiliging voor je content en kijkers](https://vodlix.com/nl/blog/ott-security-essentials-safeguarding-your-content-and-viewers) behandelt de andere, en onze pagina over [inlogbeveiliging voor streamingplatforms](https://vodlix.com/nl/features/login-security) gaat over kijkersaccounts.

## Hoe heeft Vodlix php2shell aangepakt? {#hoe-heeft-vodlix-php2shell-aangepakt}

Vodlix patchte zijn systemen tegen CVE-2026-109618 en CVE-2026-109619 voordat de lekken op 21 oktober 2026 openbaar werden gemaakt. Bij Vodlix gebruikt alleen de middleware PHP, en die is gepatcht. Klanten van Vodlix hoefden geen enkele actie te ondernemen.

Op een beheerd platform zoals Vodlix worden beveiligingsupdates als deze voor je uitgevoerd. Wil je een beveiligingsprobleem over Vodlix melden, mail dan naar security@vodlix.com.

## Wat moet je doen als je je eigen PHP-sites beheert? {#wat-moet-je-doen-als-je-je-eigen-php-sites-beheert}

Update elke PHP-installatie die je beheert naar een gerepareerde versie, of vraag je host om dat te doen, en lees de advisories van je leveranciers. Kun je niet meteen updaten, volg dan het NSA-advies dat TechCrunch aanhaalt en haal de site offline totdat het wel kan.

1. **Breng in kaart wat PHP draait.** Neem je hoofdsite, elke WordPress-site of blog, landingspagina's en beheertools mee.
2. **Controleer elke versie.** Vergelijk die met de tabel hierboven.
3. **Update of vraag het je host.** Ga naar 8.5.12, 8.4.27, 8.3.36 of 8.2.35. Bij een beheerde host vraag je om bevestiging van de datum waarop ze hebben geüpdatet.
4. **Plan een upgrade voor oude branches.** PHP 8.1 en ouder worden niet langer ondersteund, dus daar komt geen patch voor.
5. **Lees de advisories van je leveranciers.** Begin bij je host en je cloudprovider. AWS heeft er al een gepubliceerd.
6. **Bevestig dat de nieuwe versie draait.** Controleer het na de update opnieuw, op elke server.

## Wat nu? {#wat-nu}

Ben je klant van Vodlix, dan hoef je niets te doen aan php2shell. Voor vragen ga je naar het [Vodlix-helpcentrum](https://vodlix.com/nl/help) of [neem je contact op met het Vodlix-team](https://vodlix.com/nl/contact).

Overweeg je een beheerd platform zodat updates als deze voor je worden geregeld, bekijk dan de [functies van het Vodlix-platform](https://vodlix.com/nl/features) of [vraag een Vodlix-demo aan](https://vodlix.com/nl/demo).

## Veelgestelde vragen

**Q: Wat is php2shell?**

php2shell is de bijnaam voor twee kritieke PHP-kwetsbaarheden, CVE-2026-109618 en CVE-2026-109619. Officiële advisories, zoals die van de PHP Foundation, gebruiken de CVE-nummers. Beide zijn lekken in het geheugenbeheer en de foutafhandeling van PHP die, onder de juiste omstandigheden, een niet-geauthenticeerde aanvaller code laten uitvoeren op een server. PHP verhielp ze op 21 oktober 2026.

**Q: Welke PHP-versies verhelpen CVE-2026-109618 en CVE-2026-109619?**

PHP 8.5.12, 8.4.27, 8.3.36 en 8.2.35 verhelpen beide kwetsbaarheden. Ze zijn uitgebracht op 21 oktober 2026. Elke eerdere release in de branches 8.5, 8.4, 8.3 en 8.2 is kwetsbaar. PHP 8.1 en ouder worden niet langer ondersteund, dus sites op die versies moeten overstappen op een ondersteunde branch.

**Q: Moeten klanten van Vodlix iets doen aan php2shell?**

Nee. Bij Vodlix gebruikt alleen de middleware PHP, en Vodlix patchte die voordat de lekken op 21 oktober 2026 openbaar werden gemaakt. Klanten hoefden geen actie te ondernemen. Wil je een beveiligingsprobleem over Vodlix melden, dan kun je mailen naar security@vodlix.com.

**Q: Is WordPress getroffen door de PHP-kwetsbaarheid van oktober 2026?**

WordPress draait op PHP, dus WordPress-sites zijn kwetsbaar via de PHP-versie van de server. TechCrunch meldt dat WordPress zei dat het lek niet specifiek voor WordPress is, en dat sites die erop draaien hun servers moeten patchen en moeten samenwerken met hun hostingbedrijven. WordPress zelf updaten vervangt het updaten van PHP niet.

**Q: Is php2shell misbruikt voordat de fix uitkwam?**

TechCrunch meldde op 21 oktober 2026 dat, volgens OpenAI, de lekken door onderzoekers waren gevonden vóór aanvallers en dat er op dat moment geen meldingen waren van misbruik in het wild. Nu de details publiek zijn, lopen ongepatchte servers meer risico, en daarom adviseerde de NSA om sites die niet gepatcht kunnen worden offline te halen.

**Q: Wat moet ik doen als ik PHP niet meteen kan updaten?**

TechCrunch meldt dat de Amerikaanse National Security Agency adviseerde om een website die niet meteen gepatcht kan worden offline te halen totdat dat wel kan. Vraag je host wanneer ze PHP 8.5.12, 8.4.27, 8.3.36 of 8.2.35 uitrollen, en lees hun advisory en die van je cloudprovider, zoals AWS-bulletin 2026-143-AWS.