Gepubliceerd op 14 oktober 2026

Op 9 december 2026 is Drupal 10 end-of-life: de ondersteuning stopt. Je website gaat die dag niet uit de lucht en je ziet niets veranderen. Maar elk lek dat daarna in Drupal 10 wordt gevonden, blijft open.

Dat klinkt als een probleem voor later. Alleen worden er veel meer lekken gevonden dan een paar jaar geleden. In heel 2024 verschenen 71 beveiligingsmeldingen voor Drupal-modules. In 2026 waren het er tot en met september al 189. Daardoor is wachten riskanter dan bij eerdere versies.

Wat betekent end-of-life precies?

Na de einddatum krijgt Drupal 10 geen beveiligingsupdates en bugfixes meer. Voor een deel van de sites is dat al eerder zo, want alleen versie 10.6 wordt tot het einde bijgewerkt. Draait je site op Drupal 10.5 of ouder, dan krijgt hij nu al geen beveiligingsupdates meer.

Naar welke versie upgraden?

De volgende stap is Drupal 11. Kies dan meteen voor 11.4 of nieuwer, want de ondersteuning voor 11.3 stopt in dezelfde week als die voor Drupal 10. Rechtstreeks naar Drupal 12 (release in de week van 7 december 2026) kan niet: een site moet eerst op Drupal 11 zitten.

Waarom wachten riskanter is geworden

Voor deze blog heb ik op 13 oktober 2026 geteld hoeveel beveiligingsmeldingen (security advisories) er per jaar op drupal.org verschenen voor Drupal-modules:

Het aantal stijgt niet alleen, het stijgt elk jaar harder. Ook het aantal kritieke lekken (critical en highly critical) loopt op: in de eerste negen maanden van 2026 waren het er bijna twee keer zoveel als in heel 2025. Meldingen over modules die niet meer worden ondersteund, heb ik niet meegeteld.

De Drupal Association wijst AI aan als belangrijke factor. In een blog van juli 2026 schrijft de organisatie dat AI het vinden van lekken "dramatisch goedkoper" maakt. Dat geldt voor beide kanten: wie lekken wil dichten, vindt ze sneller, maar wie ze wil misbruiken ook. Dat merk ik in mijn eigen beheerwerk: ik installeer veel vaker beveiligingsupdates dan een paar jaar geleden.

Wat is een kritiek lek?
Het Drupal Security Team geeft elk lek een score. Daarbij telt mee hoe makkelijk het lek te misbruiken is, hoe groot de mogelijke schade is en hoeveel sites het raakt. Bij een kritiek lek is die score hoog. Soms hoeft een aanvaller niet eens in te loggen om het lek te misbruiken.

Wat kan er dan gebeuren?
Een aanvaller kan gegevens uit je site halen, zoals formulierinzendingen en accounts. Ook kan een aanvaller ongemerkt spamlinks of malware op je site zetten. Google kan bezoekers dan waarschuwen voor je site, of je site lager tonen in de zoekresultaten. Lekken er persoonsgegevens uit, dan moet je dat in de meeste gevallen binnen 72 uur melden bij de Autoriteit Persoonsgegevens. Vaak merk je er zelf niets van. Soms is de spam alleen zichtbaar voor Google, en zie je zelf niets als je je site bezoekt.

Twee kritieke lekken uit 2026 laten zien hoe snel misbruik volgt, en waarom je versie ertoe doet:

Na 9 december 2026 is dat de situatie voor elke Drupal 10-site, bij elk nieuw lek.

Welke versie draait jouw website?

Met de Drupal-versie checker zie je binnen een paar seconden welke versie een site gebruikt en of die nog wordt ondersteund. Je hoeft daarvoor niet in te loggen.

Upgraden, migreren of overstappen?

Welke route het beste past, hangt vooral af van twee dingen: op welke versie je site nu draait, en hoe goed hij is bijgehouden.

Waar hangen de tijd en de kosten van af?

Een prijs noemen zonder de site te kennen, is een belofte die ik niet kan waarmaken. Dit bepaalt de omvang:

• De staat van de site: is hij bijgehouden, of staan er al jaren updates open?
• Het aantal modules: een site met 20 modules is iets anders dan een site met meer dan 100, waarvan sommige niet meer worden ondersteund.
• Maatwerk: eigen code en eigen aanpassingen (patches) moeten worden nagelopen en vaak aangepast.
• De bouw van de site: is hij netjes opgezet met Composer (het standaard hulpmiddel om Drupal en modules te beheren), of half met de hand?
• De inrichting: is de site logisch en duidelijk opgezet, of staat er veel in dat niemand meer gebruikt of begrijpt? Elk onduidelijk onderdeel moet eerst worden uitgezocht voordat het veilig kan worden bijgewerkt of opgeruimd.
• Of ik de site al ken: bij een site die ik zelf heb gebouwd en beheer, heb ik al toegang, een testomgeving en kennis van de code. Bij een nieuwe site gaat daar eerst tijd in zitten.

Uit de praktijk: bij een audit van een Drupal-site vond ik blokken en overzichtspagina's (views) die nergens meer werden gebruikt. Ook was aan de namen van content types en velden niet te zien waarvoor ze dienden. Een bezoeker merkt daar niets van, maar bij een upgrade moet het allemaal worden nagelopen.

Denk ook aan modules die wel zijn geïnstalleerd maar niet meer worden gebruikt, content types met namen als "page_1" en "page_2", of velden met een naam als "nieuw veld". Hoe meer er onduidelijk is, hoe langer het uitzoeken en testen duurt.

Daarom begin ik bij een nieuwe klant altijd met een korte audit. Pas als ik de code en de database heb gezien, kan ik een eerlijke inschatting geven.

Wat kun je zelf alvast doen?

Je hoeft geen technische kennis te hebben om een upgrade sneller en goedkoper te maken. Dit helpt:

• Zet op papier wat je website moet kunnen. Welke functies zijn essentieel? Wat is bijzonder aan jouw site? Dan weet je ontwikkelaar wat na de upgrade in elk geval moet werken.
• Verzamel wat er al is: documentatie, oude offertes en de contactgegevens van de vorige webbouwer. Daarin staat vaak waarom bepaalde keuzes zijn gemaakt.
• Vraag je hostingpartij welke PHP-versie ze bieden. Drupal 11.4 werkt met PHP 8.3 of nieuwer, Drupal 12.0 alleen met PHP 8.5. Biedt je hosting nog geen PHP 8.5, dan loop je bij de stap naar Drupal 12 opnieuw vast.
• Vraag wie je site beheert wanneer de laatste updates zijn gedaan. Dan weet je meteen of er een achterstand is.
• Wacht met nieuwe wensen. Rond eerst de upgrade af en kijk daarna naar nieuwe functies. Twee dingen tegelijk maakt het lastiger om te testen en om fouten terug te vinden.

Overstappen naar een andere webbouwer?

Laat je de upgrade door iemand anders doen dan je huidige webbouwer? Dan is het efficiënter als je huidige webbouwer zorgt voor een goede overdracht: ongebruikte onderdelen opruimen, onduidelijke namen aanpassen en vastleggen wat er bijzonder is aan de site. Lukt dat niet, geen probleem. Zorg dan voor goede documentatie. Het hoeft allemaal niet, maar zonder kost het hele traject meer tijd. Wat je wel altijd nodig hebt: de toegangsgegevens van hosting, database en beheeraccounts.

Stel het niet uit

Elke dag na 9 december 2026 zonder updates wordt het risico groter. Wie de upgrade tot december laat liggen, is vaak pas in januari aan de beurt: december is voor veel webbouwers een drukke maand. Kies je er bewust voor om te wachten, zorg dan in elk geval dat er geen klantgegevens in je site staan. Vaak staan er meer in dan je denkt. De veelgebruikte formuliermodule Webform bewaart standaard elke inzending en verwijdert die nooit vanzelf. Een contactformulier dat al jaren online staat, kan dus jaren aan namen, e-mailadressen en berichten bevatten. Gegevens die je niet bewaart, kunnen ook niet uitlekken.

Hulp nodig?

Draait je site op Drupal 10 of ouder, of weet je niet wat je moet doen? Neem dan contact op. Je spreekt direct met mij, en na een korte audit weet je waar je aan toe bent.