Fallo crítico en Next.js: así lo ha corregido ClassKasa
El 22 de octubre de 2026 Next.js avisó de un fallo con CVSS 9.5. ClassKasa funciona con Next.js. Qué era exactamente y qué publicamos el 23 de octubre.
Tomasz Żyłka · 3 min de lectura
El 22 de octubre de 2026 el equipo de Next.js publicó un aviso de seguridad crítico, GHSA-673q-mjm6-r5xr, con una puntuación de 9.5 sobre 10 (CVSS 4.0). ClassKasa está hecha con Next.js y usa justo la función donde estaba el fallo. El 23 de octubre publicamos ClassKasa v4.75.0, que pasa a Next.js 16.4.3, una versión que ya trae el arreglo. En pantalla no cambia nada: tu clase, tus colectas y la conexión con el banco funcionan igual que antes.
Qué era el fallo
Next.js es el framework sobre el que funciona ClassKasa (y buena parte de la web). Tiene una función llamada Cache Components: una página puede guardar una respuesta ya preparada con una función 'use cache', para que la siguiente visita la reciba más rápido.
El aviso describe un fallo en esa caché. Si una función 'use cache' devuelve varios arrays tipados (bloques de datos binarios en bruto), una petición preparada a propósito podía hacer que el servidor ejecutara código elegido por el atacante. No hacía falta cuenta ni inicio de sesión. Afecta a Next.js desde la 16.0.0 hasta la 16.4.0, la 16.4.1 lo corrige y el aviso no da ninguna solución provisional: todo el que esté en esas versiones debe actualizar, aunque su código no tenga una función así.
La misma versión de Next.js trae además arreglos para otros dos avisos, GHSA-2464-fhr4-w9xw y GHSA-p3m5-59mp-jv5r.
Por qué esto se puso el primero de la lista
Con Premium, el delegado o la delegada puede conectar la cuenta bancaria de la clase con ClassKasa, y las familias miran cuánto les toca pagar (ya hay más de 140 clases en ClassKasa). Donde se mueven dinero y datos del banco, la seguridad va antes que las funciones nuevas. Por eso esta actualización adelantó a todo lo demás.
Qué hicimos antes de publicar
- Actualizamos la base: Next.js 16.4.3, la versión con el arreglo, y debajo Node.js 22.
- Revisamos los caminos del dinero: una revisión aparte (un agente de Claude Code que no había escrito el cambio) recorrió los sitios por donde pasan pagos, avisos de Stripe y datos del banco, buscando cualquier cosa que las versiones nuevas pudieran romper.
- Probamos los pagos de verdad, en el modo de prueba de Stripe: un pago con tarjeta, una tarjeta con 3-D Secure, una tarjeta rechazada y un aviso de pago repetido, que no debe apuntar nada dos veces.
- Apagamos los datos personales en los informes de errores: la nueva versión de nuestra herramienta de informes de errores, Sentry, recogería por defecto cookies, cabeceras y el contenido de las peticiones. Desactivamos cada una de esas categorías, y una prueba detiene la compilación si una versión futura añade una nueva activada por defecto.
- Las barreras siguen cerradas: una vulnerabilidad nueva en una librería que usamos bloquea la compilación hasta que se corrige o se justifica.
Qué significa para ti
No tienes que hacer nada. En ClassKasa no hay contraseñas que cambiar: entras con un enlace que te llega por correo, y la contraseña del banco nunca se escribe en ClassKasa. Cómo funciona la conexión con el banco y qué comprobaciones se hacen en cada cambio lo contamos en nuestra página de seguridad.
Preguntas frecuentes
¿El fallo estaba en el código de ClassKasa?
No. Estaba en Next.js, el framework con el que está hecha ClassKasa. Mantenerlo al día es igualmente cosa nuestra, por eso el arreglo salió como una versión propia.
¿Tengo que cambiar algo en mi clase?
No. El arreglo está en nuestros servidores. Tu clase, las colectas, los pagos y la conexión con el banco siguen exactamente como estaban.
¿Dónde veo cómo protege ClassKasa los datos del banco?
En la página de seguridad: cómo funciona conectar un banco, quién se encarga de qué y qué comprobaciones automáticas se hacen en cada cambio. Las dudas del día a día están en las preguntas frecuentes.