Van wie is PHP eigenlijk? Wat het PHP-lek van oktober leert over de motor onder je website

Op 20 oktober 2026 waarschuwde het PHP-team voor twee kritieke lekken in PHP zelf. Een dag later, op 21 oktober, kwam de reparatie. In die 24 uur haalden hostingpartijen en zelfs het NCSC websites uit voorzorg offline.

De lekken staan bekend als CVE-2026-109618 en CVE-2026-109619, samen bijgenaamd PHP2Shell. Het PHP-team gaf beide een ernstscore van 9,2 op 10. Via de lekken kon een buitenstaander op afstand opdrachten uitvoeren op een webserver, zonder in te loggen.

Voor de meeste lezers was dit de eerste keer dat ze echt over PHP hoorden. Terwijl hun eigen website er al jaren op draait. Dit artikel legt uit wat PHP is, van wie het is, en waarom dat ertoe doet voor iedereen met een website.

Wat is PHP eigenlijk

PHP is een programmeertaal die op de server wordt uitgevoerd. Wanneer een bezoeker een pagina opent, een formulier verstuurt of een bestelling plaatst, kan PHP dat verzoek verwerken, gegevens uit een database ophalen of opslaan en een antwoord terugsturen naar de browser.

Je ziet PHP nooit, maar het is overal. WordPress draait erop, net als WooCommerce, Drupal, Joomla en Laravel. Volgens meetbureau W3Techs draait ongeveer 69 procent van alle websites waarvan de servertaal bekend is op PHP.

Vergelijk het met het elektriciteitsnet onder een gebouw. Bezoekers zien de inrichting: je ontwerp, je teksten, je formulieren. Niemand denkt aan de bedrading, tot er kortsluiting is.

Van wie is PHP?

PHP is van niemand, in de zin waarin Java van Oracle is. Er is geen bedrijf dat de taal bezit, en ook geen bedrijf dat je kunt bellen als er iets misgaat.

Formeel ligt het auteursrecht op PHP bij The PHP Group, een kleine groep vroege kernontwikkelaars. Het auteursrecht op de technische motor van PHP, de Zend Engine, ligt bij Zend, dat nu onderdeel is van softwarebedrijf Perforce. PHP is open source: iedereen mag het gratis gebruiken, bekijken en verbeteren.

De taal wordt ontwikkeld door een gemeenschap van vrijwilligers en betaalde ontwikkelaars. Over nieuwe functies stemmen zij via een openbaar voorstellenproces, de zogeheten RFC’s (Request for Comments). Wie wil, kan meelezen hoe elke beslissing tot stand komt.

Sinds eind 2021 bestaat ook The PHP Foundation. Deze non-profit betaalt ontwikkelaars om aan PHP zelf te werken. Ze is opgericht op initiatief van JetBrains, samen met onder andere Automattic (het bedrijf achter WordPress.com), Laravel, Symfony en Zend. Bedrijven en particulieren financieren de foundation, maar ook zij bezit de taal niet.

Zend speelde vroeger een grote rol in de ontwikkeling van PHP. Toch heeft het bedrijf vandaag geen zeggenschap over de taal: wat erin komt, bepaalt de gemeenschap.

Kort gezegd: een van de belangrijkste bouwstenen van het internet wordt onderhouden door een relatief kleine groep mensen, betaald uit vrijwillige bijdragen.

Waarom een bijgewerkte WordPress niet genoeg was

Dit lek zat niet in een plugin of in WordPress, maar een laag dieper. Een website die keurig up-to-date was, kon dus toch kwetsbaar zijn.

Een website bestaat uit lagen die op elkaar rusten:

1. Thema en plugins: wat je ziet en gebruikt, zoals formulieren en sliders.
2. Het CMS, bijvoorbeeld WordPress.
3. PHP: de taal waarin het CMS draait.
4. De server: het besturingssysteem en de software die alles laat draaien.

De automatische updates in WordPress werken alleen de bovenste twee lagen bij. PHP en de server worden bijgewerkt door wie de hosting beheert. WordPress.org en WooCommerce lieten dan ook weten dat er geen update van hun kant nodig was: de oplossing moest uit de PHP-laag komen.

Ook een beveiligingsplugin hielp hier weinig. Zo’n plugin is zelf PHP-code en komt pas in actie nadat PHP het verzoek al verwerkt. Firewalls zoals die van Cloudflare hielden bekende aanvalspogingen tegen, maar ook Cloudflare adviseerde PHP zelf bij te werken.

Wat we hiervan leren

Open source werkt, maar het werkt niet vanzelf. Het PHP-team bracht binnen een dag een oplossing uit voor miljoenen websites, zonder dat iemand daar een licentie voor betaalt. Dat is indrukwekkend.

Tegelijk laat deze week zien hoe kwetsbaar die afhankelijkheid is. Volgens de PHP Foundation waren de eerste tekenen van het probleem al in 2024 zichtbaar, en kwam de reparatie een dag eerder dan gepland omdat details uitlekten. De foundation wees er zelf op dat het securityteam door AI-ondersteund onderzoek veel meer meldingen binnenkrijgt dan vroeger. Meer werk dus, voor dezelfde kleine groep mensen.

Drie lessen voor iedereen met een website:

• De onderlaag telt net zo zwaar als de buitenkant. Een mooie, actuele site op een verouderde PHP-versie is een open deur.
• Versies verlopen. Elke PHP-versie krijgt een paar jaar beveiligingsupdates. PHP 8.1 en ouder krijgen er geen meer, en voor PHP 8.2 stopt de ondersteuning op 31 december 2026.
• Iemand moet verantwoordelijk zijn. Bij een lek als dit telt elk uur. Het moet vooraf duidelijk zijn wie de PHP-laag bijwerkt, hoe snel, en wie daarna controleert of alles nog werkt.

Wat kun je nu doen?

De reparatie zit in PHP 8.5.12, 8.4.27, 8.3.36 en 8.2.35. Draait je website op een oudere versie, of weet je het niet, stel dan je hosting- of onderhoudspartij deze drie vragen:

1. Op welke PHP-versie draait mijn website nu, en bevat die de reparatie voor CVE-2026-109618 en CVE-2026-109619?
2. Zijn de PHP-processen na de update opnieuw gestart?
3. Wie houdt de PHP-laag voortaan bij, en hoe snel gebeurt dat bij een kritiek lek?

Vraag de antwoorden per mail. Dan heb je ze bij een volgend lek direct bij de hand. Was je website in de kwetsbare periode online, laat dan ook controleren of er geen onbekende beheerders, bestanden of plugins zijn bijgekomen.`

Wat wij vorige week deden

Op 21 oktober, net voor 16:00 uur, kwam de reparatie beschikbaar. Op dat moment ging ons team samen met onze netwerkpartner Nextpertise aan de slag. We werkten DirectAdmin bij, het beheersysteem van onze servers, en rolden de gerepareerde PHP-versies uit.

Om 19:00 uur draaiden al onze servers op PHP 8.2.35 of hoger. Binnen drie uur na de release waren alle websites, die wij hosten, dus beschermd.