A Critical Next.js Bug, and the Fix ClassKasa Has Shipped
On 22 October 2026 Next.js disclosed a CVSS 9.5 remote code execution bug. ClassKasa runs on Next.js. What the bug was and what we shipped on 23 October.
Tomasz Żyłka · 3 min read
On 22 October 2026 the Next.js team published a critical security advisory, GHSA-673q-mjm6-r5xr, scored 9.5 out of 10 (CVSS 4.0). ClassKasa is built on Next.js and uses the feature the bug lives in. On 23 October we released ClassKasa v4.75.0, which moves us to Next.js 16.4.3, a version that contains the fix. Nothing changes on your screen: your class, your collections and your bank connection work as before.
What the bug was
Next.js is the framework ClassKasa (and a large part of the web) is built on. It has a feature called Cache Components: a page can keep a ready-made answer in a cache with a 'use cache' function, so the next visitor gets it faster.
The advisory describes a flaw in that cache. If a 'use cache' function returns several typed arrays (blocks of raw binary data), a crafted request could make the server run code chosen by the attacker. No account or login was needed. It affects Next.js 16.0.0 up to 16.4.0, version 16.4.1 fixes it, and the advisory names no workaround: everyone on those versions is told to upgrade, even if their own code has no such function.
The same Next.js release also carries fixes for two more advisories, GHSA-2464-fhr4-w9xw and GHSA-p3m5-59mp-jv5r.
Why this one got the top of our list
On Premium, a class treasurer can connect the class bank account to ClassKasa, and parents check what they owe (there are now over 140 classes on ClassKasa). Where money and bank data move, security comes before new features. So this update went in front of everything else in the queue.
What we did before the release
- Updated the framework: Next.js 16.4.3, which contains the fix, and Node.js 22 under it.
- Reviewed the money paths: a separate review (a Claude Code agent that had not written the change) went through the places where payments, webhooks and bank data move, and looked for anything the new versions could break.
- Tested payments for real, in Stripe's test mode: a card payment, a card with 3-D Secure, a declined card and a replayed payment notification, which must not book anything twice.
- Switched off personal data in error reports: the new version of our error-reporting tool, Sentry, would collect cookies, headers and request contents by default. We turned every one of those off, and a test now fails the build if a future version adds a new category that is on by default.
- Kept the gates shut: a newly found vulnerability in a library we use blocks the build until it is fixed or explained.
What this means for you
Nothing to do. ClassKasa has no passwords to change: you sign in with a link sent to your e-mail, and your bank password is never typed into ClassKasa. How the bank connection works, and which checks run on every change, is on our security page.
FAQ
Was the bug in ClassKasa's own code?
No. It was in Next.js, the framework ClassKasa is built on. Keeping that framework up to date is still our job, which is why the update went out as its own release.
Do I need to change anything in my class?
No. The fix is on our servers. Your class, collections, payments and bank connection stay exactly as they were.
Where can I see how ClassKasa protects bank data?
On the security page: how connecting a bank works, who runs what, and the automated checks on every change. Everyday questions are in the FAQ.