Twee Next.js-beveiligingsupdates in een week: wat dat zegt over het onderhoud van je website

Op 22 en 30 september bracht Vercel binnen acht dagen twee beveiligingsupdates uit voor Next.js, het framework achter een groot deel van de moderne bedrijfswebsites. Wat er precies gebeurde, en waarom het laat zien dat een website na de livegang nooit klaar is.

Op 22 september bracht Vercel, het bedrijf achter Next.js, een spoedupdate uit voor een kritieke kwetsbaarheid in het framework. Acht dagen later, op 30 september, volgde een tweede, al langer aangekondigde beveiligingsupdate met negen kwetsbaarheden in een keer, waarvan opnieuw een als kritiek werd bestempeld. Twee updates in iets meer dan een week, voor een framework dat achter een groot deel van de moderne bedrijfswebsites, webshops en klantportalen zit, ook achter die van Zarioh zelf.

Voor wie zelf geen code schrijft, klinkt dit als achtergrondruis uit de ontwikkelaarswereld. Dat is het niet. Wat er in september gebeurde, laat precies zien waarom een website na de livegang geen afgerond project is, maar een stuk software dat onderhoud blijft vragen, net als een boekhoudpakket of een besturingssysteem.

Wat er precies gebeurde

De update van 22 september loste een probleem op in het onderdeel van Next.js dat afbeeldingen genereert, next/og, via een externe bibliotheek genaamd Satori. Onder specifieke omstandigheden kon een aanvaller via die route eigen code laten uitvoeren op de server, in vaktaal remote code execution. Het probleem trof versies vanaf 16.2.0 tot en met 16.3.5, en Vercel bracht binnen enkele uren versie 16.3.6 uit met de oplossing.

De tweede update, gepland voor 30 september, was geen noodgreep maar een vooraf aangekondigde release. Vercel liet ruim een week van tevoren weten dat die negen kwetsbaarheden zou verhelpen: een kritieke, twee met hoge impact, vijf gemiddelde en een lage. Door die vooraankondiging konden ontwikkelteams zich voorbereiden, iets wat bij de spoedupdate van de 22e niet mogelijk was.

Waarom remote code execution meer is dan jargon

Remote code execution betekent dat een aanvaller niet alleen gegevens kan inzien, maar de server zelf kan overnemen. In de praktijk kan dat leiden tot gestolen klantgegevens, een website die ongemerkt schadelijke code naar bezoekers stuurt, of een volledige gijzeling van de omgeving. Het verschil met een gewone bug is het verschil tussen een kapotte deurbel en een voordeur die niet meer op slot kan.

De aanname dat een website klaar is zodra hij live staat

Veel organisaties behandelen een website als een eenmalig project: een bureau bouwt hem, er volgt een oplevering, en daarna verandert er weinig meer buiten wat teksten en foto's. Onder de motorkap draait intussen een stapel software, het framework zelf plus tientallen tot honderden losse pakketten, die net als elke andere software kwetsbaarheden blijft ontwikkelen. Next.js bracht dit jaar al meerdere keren beveiligingsupdates uit, onder meer in mei en augustus, en nu twee keer in september. Dat is geen uitzondering, dat is het normale ritme van een actief onderhouden framework.

Het probleem zit niet in het framework, maar in de aanname dat een website na oplevering geen aandacht meer nodig heeft. Een kwetsbaarheid die vandaag wordt gepubliceerd, staat morgen al in scansoftware die het hele internet aftast op onbijgewerkte versies. Hoe langer een patch uitblijft, hoe groter het venster waarin een geautomatiseerde aanval raak kan schieten, vaak zonder dat er een specifieke aanvaller naar uw bedrijf op zoek was.

Ook buiten Next.js geldt dezelfde regel

Wie geen Next.js gebruikt is niet automatisch veilig. WordPress, dat een groot deel van het web aandrijft, kent een vergelijkbaar ritme van beveiligingsupdates voor de kern en voor duizenden plugins. Het onderliggende probleem is steeds hetzelfde: software die na oplevering zonder toezicht blijft draaien, wordt vroeg of laat het makkelijkste doelwit. Niet omdat een aanvaller specifiek naar die ene organisatie zoekt, maar omdat geautomatiseerde scans dag en nacht op zoek zijn naar onbijgewerkte versies, van welk platform dan ook.

Wie patcht jouw website eigenlijk

Dit is de vraag die de meeste directies en marketingteams niet kunnen beantwoorden. Is er een hostingpartij die versies actief bijhoudt en updatet? Is dat de freelancer die de site drie jaar geleden bouwde en intussen iets anders doet? Of draait de site gewoon door totdat er iets zichtbaar misgaat? Bij veel websites is het antwoord: niemand structureel. Updates gebeuren pas als er toevallig een nieuwe functie wordt toegevoegd, en beveiligingspatches zonder zichtbaar effect blijven liggen.

Wat je deze week kunt doen

Vraag je hostingpartij of ontwikkelaar concreet welke Next.js- of WordPress-versie er nu draait, en of de updates van 22 en 30 september al zijn doorgevoerd. Geen concreet antwoord, of een antwoord dat dagen op zich laat wachten, is zelf al een signaal. Vraag ook hoe patches in het algemeen verlopen: automatisch bij elke release, periodiek gepland, of pas na een incident. Voor een klantportaal, webshop of ander systeem met inloggegevens en persoonsgegevens is een structureel patchproces geen overdreven voorzorg, maar een basisvoorwaarde.

Een website bouwen is het begin van de verantwoordelijkheid voor de veiligheid ervan, niet het einde. Wil je laten checken of jouw website en de onderliggende software actueel en veilig zijn, of wil je het onderhoud structureel beleggen bij een partij die dat continu bijhoudt? Zarioh denkt graag mee over beheerde hosting en doorlopend onderhoud voor je website.