Kritische Lücke in Next.js: so hat ClassKasa sie geschlossen

Am 22. Oktober 2026 hat das Next.js-Team eine kritische Sicherheitsmeldung veröffentlicht, GHSA-673q-mjm6-r5xr, bewertet mit 9.5 von 10 (CVSS 4.0). ClassKasa ist mit Next.js gebaut und nutzt genau die Funktion, in der der Fehler steckte. Am 23. Oktober haben wir ClassKasa v4.75.0 veröffentlicht, die auf Next.js 16.4.3 wechselt, eine Version mit dem Fix. Auf dem Bildschirm ändert sich nichts: Klasse, Sammlungen und Bankverbindung funktionieren wie bisher.

Worum es ging

Next.js ist das Framework, auf dem ClassKasa (und ein großer Teil des Webs) läuft. Es hat eine Funktion namens Cache Components: Eine Seite kann eine fertige Antwort mit einer 'use cache'-Funktion zwischenspeichern, damit der nächste Besuch sie schneller bekommt.

Die Meldung beschreibt einen Fehler in diesem Cache. Gibt eine 'use cache'-Funktion mehrere typisierte Arrays zurück (Blöcke roher Binärdaten), konnte eine präparierte Anfrage den Server dazu bringen, Code eines Angreifers auszuführen. Ein Konto oder eine Anmeldung war dafür nicht nötig. Betroffen sind Next.js 16.0.0 bis 16.4.0, behoben ist es in 16.4.1, und die Meldung nennt keinen Workaround: Wer auf diesen Versionen ist, soll aktualisieren, auch wenn der eigene Code keine solche Funktion hat.

Dasselbe Next.js-Release enthält außerdem Fixes für zwei weitere Meldungen, GHSA-2464-fhr4-w9xw und GHSA-p3m5-59mp-jv5r.

Warum das ganz oben auf der Liste stand

Mit Premium kann der Kassenwart das Konto der Klasse mit ClassKasa verbinden, und Eltern sehen nach, was sie zahlen müssen (inzwischen gibt es über 140 Klassen bei ClassKasa). Wo Geld und Bankdaten fließen, kommt Sicherheit vor neuen Funktionen. Deshalb ist dieses Update an allem anderen vorbeigezogen.

Was wir vor dem Release gemacht haben

• Das Fundament aktualisiert: Next.js 16.4.3, die Version mit dem Fix, darunter Node.js 22.
• Die Geldwege geprüft: Eine eigene Prüfung (ein Claude-Code-Agent, der die Änderung nicht geschrieben hatte) ist die Stellen durchgegangen, an denen Zahlungen, Stripe-Benachrichtigungen und Bankdaten laufen, und hat nach allem gesucht, was die neuen Versionen kaputt machen könnten.
• Zahlungen echt getestet, im Testmodus von Stripe: eine Kartenzahlung, eine Karte mit 3-D Secure, eine abgelehnte Karte und eine wiederholte Zahlungsbenachrichtigung, die nichts doppelt buchen darf.
• Personenbezogene Daten in Fehlerberichten abgeschaltet: Die neue Version unseres Fehlerberichts-Tools Sentry würde standardmäßig Cookies, Header und Inhalte von Anfragen sammeln. Wir haben jede dieser Kategorien abgeschaltet, und ein Test stoppt den Build, falls eine künftige Version eine neue, standardmäßig aktive Kategorie hinzufügt.
• Die Schranken bleiben zu: Eine neu gefundene Schwachstelle in einer Bibliothek, die wir nutzen, blockiert den Build, bis sie behoben oder begründet ist.

Was das für dich heißt

Du musst nichts tun. In ClassKasa gibt es kein Passwort zu ändern: Du meldest dich über einen Link an, der per E-Mail kommt, und dein Bankpasswort gibst du nie in ClassKasa ein. Wie die Bankverbindung funktioniert und welche Prüfungen bei jeder Änderung laufen, steht auf unserer Sicherheitsseite.

Häufige Fragen

War der Fehler im Code von ClassKasa selbst?

Nein. Er steckte in Next.js, dem Framework, auf dem ClassKasa gebaut ist. Es aktuell zu halten ist trotzdem unser Job, darum kam der Fix als eigenes Release.

Muss ich in meiner Klasse etwas ändern?

Nein. Der Fix liegt auf unseren Servern. Klasse, Sammlungen, Zahlungen und Bankverbindung bleiben genau so, wie sie waren.

Wo sehe ich, wie ClassKasa Bankdaten schützt?

Auf der Sicherheitsseite: wie das Verbinden einer Bank funktioniert, wer was betreibt und welche automatischen Prüfungen bei jeder Änderung laufen. Alltagsfragen stehen in den FAQ.