Krytyczna luka w Next.js i poprawka, którą wdrożyła ClassKasa

22 października 2026 zespół Next.js opublikował krytyczny komunikat bezpieczeństwa GHSA-673q-mjm6-r5xr z oceną 9.5 na 10 (CVSS 4.0). ClassKasa jest zbudowana na Next.js i korzysta z funkcji, w której siedziała luka. 23 października wydaliśmy ClassKasę v4.75.0, która przenosi nas na Next.js 16.4.3, wersję z poprawką. Na ekranie nic się nie zmienia: klasa, zbiórki i połączenie z bankiem działają jak wcześniej.

Na czym polegała luka

Next.js to framework, na którym stoi ClassKasa (i spory kawałek internetu). Ma funkcję Cache Components: strona może trzymać gotową odpowiedź w pamięci podręcznej przez funkcję 'use cache', żeby kolejna osoba dostała ją szybciej.

Komunikat opisuje błąd w tej pamięci. Jeśli funkcja 'use cache' zwraca kilka tablic typowanych (bloków surowych danych binarnych), odpowiednio spreparowane żądanie mogło sprawić, że serwer uruchomi kod wybrany przez atakującego. Nie było potrzebne ani konto, ani logowanie. Dotyczy to Next.js od 16.0.0 do 16.4.0, poprawka jest w 16.4.1, a komunikat nie podaje żadnego obejścia: każdy na tych wersjach ma zaktualizować, nawet jeśli w jego kodzie nie ma takiej funkcji.

To samo wydanie Next.js zawiera też poprawki do dwóch innych komunikatów: GHSA-2464-fhr4-w9xw i GHSA-p3m5-59mp-jv5r.

Dlaczego ta sprawa poszła na sam początek kolejki

W Premium skarbnik może połączyć z ClassKasą konto bankowe klasy, a rodzice sprawdzają, ile mają zapłacić (w ClassKasie jest już ponad 140 klas). Tam, gdzie ruszają się pieniądze i dane z banku, bezpieczeństwo idzie przed nowymi funkcjami. Dlatego ta aktualizacja wyprzedziła wszystko inne.

Co zrobiliśmy przed wydaniem

• Zaktualizowaliśmy fundament: Next.js 16.4.3, wersja z poprawką, a pod spodem Node.js 22.
• Przejrzeliśmy ścieżki pieniędzy: osobny przegląd (agent Claude Code, który nie pisał tej zmiany) przejrzał miejsca, przez które płyną płatności, powiadomienia z Stripe i dane z banku, i szukał wszystkiego, co nowe wersje mogłyby zepsuć.
• Sprawdziliśmy płatności naprawdę, w trybie testowym Stripe: płatność kartą, kartę z 3-D Secure, kartę odrzuconą i powtórzone powiadomienie o płatności, które nie może niczego zaksięgować dwa razy.
• Wyłączyliśmy dane osobowe w raportach błędów: nowa wersja naszego narzędzia do raportowania błędów, Sentry, domyślnie zbierałaby ciasteczka, nagłówki i treść żądań. Wyłączyliśmy każdą z tych kategorii, a test zatrzyma budowanie aplikacji, jeśli przyszła wersja doda nową, domyślnie włączoną.
• Bramki zostają zamknięte: nowo wykryta podatność w bibliotece, której używamy, blokuje budowanie, dopóki nie zostanie naprawiona albo wyjaśniona.

Co to oznacza dla ciebie

Nic nie musisz robić. W ClassKasie nie ma haseł do zmiany: logujesz się linkiem wysłanym na e-mail, a hasła do banku nigdy nie wpisujesz w ClassKasie. Jak działa połączenie z bankiem i jakie kontrole uruchamiamy przy każdej zmianie, opisujemy na stronie o bezpieczeństwie.

Pytania i odpowiedzi

Czy luka była w kodzie samej ClassKasy?

Nie. Była w Next.js, frameworku, na którym zbudowana jest ClassKasa. Pilnowanie, żeby był aktualny, to i tak nasza robota, dlatego poprawka wyszła jako osobne wydanie.

Czy muszę coś zmienić w swojej klasie?

Nie. Poprawka jest na naszych serwerach. Klasa, zbiórki, wpłaty i połączenie z bankiem zostają dokładnie takie, jakie były.

Gdzie zobaczę, jak ClassKasa chroni dane z banku?

Na stronie o bezpieczeństwie: jak działa łączenie banku, kto co obsługuje i jakie automatyczne kontrole uruchamiamy przy każdej zmianie. Codzienne pytania są w FAQ.