Vulnerabilidad Crítica en React y Next.js
Por qué los usuarios de Next.js resultaron más afectados y los pasos exactos que debes tomar para protegerte
Estaba teniendo una de esas raras mañanas tranquilas en las que todo simplemente… funciona.
El código se compila. Las pruebas pasan. El café aún está caliente.
Y entonces un amigo me envió un mensaje: “Oye, React puede ejecutar comandos arbitrarios en el servidor. Como… comandos a nivel del sistema.”
Me reí.
Esa clase de risa que das cuando crees que alguien está bromeando, pero también rezas para que lo esté, porque ya sabes que no lo está.
Cinco minutos después, estaba mirando una terminal donde una aplicación Next.js —una instalación fresca, por cierto— estaba ejecutando felizmente
id reboot
Y luego la máquina virtual se apagó.
Ese fue el momento en que mi café se enfrió.
Vamos a desglosar exactamente qué sucedió, por qué esta vulnerabilidad es tan grave como parece, y qué debes hacer ahora mismo para que tú (y tu trabajo, tu aplicación en producción y tu cordura) no caigan con ella.
¿Qué Ocurrió Realmente? (Sin Eufemismos)
Una vulnerabilidad crítica —CVE-2025–55182— afectó a React Server Components (RSC), permitiendo a los atacantes ejecutar comandos del sistema arbitrarios en el servidor.
No inyección de JavaScript. No XSS. No algún error extraño que solo ocurre en modo desarrollo.
Comandos reales a nivel del sistema.
Eso significa
- Crear archivos
- Eliminar archivos
- Leer secretos
- Ejecutar shells inversos
- Apagar tus servidores
Todo.
La vulnerabilidad ha sido cariñosamente (o traumáticamente) apodada React to Shell, en referencia a la infame pesadilla de Log4Shell de 2021.
Este es el tipo de error que mantiene despiertos a los equipos de seguridad y hace que los equipos de DevOps actualicen sus perfiles de LinkedIn.
Por Qué los Usuarios de Next.js Resultaron Más Afectados
React por sí solo?
Debes optar por los componentes del servidor.
Next.js?
Estás optado por defecto.
Felicidades. Te has jugado a ti mismo.
Si instalaste una aplicación Next.js 14+ usando la estructura de directorios app/, estabas ejecutando React Server Components desde el primer día —sin importar si te dabas cuenta o no.
Y como RSC se encuentra entre tu aplicación y la lógica de base de datos o backend, comprometer RSC significa comprometer todo el servidor.
Por eso fue posible el demo que mostraba una instalación básica de Next reiniciando una máquina virtual. Sin código personalizado. Sin configuraciones extrañas. Solo valores predeterminados.
Deja que eso te hunda.
Edición de imagen: Mark
Cómo Funciona Realmente la Vulnerabilidad (En Términos Humanos)
No voy a ahogarte con diagramas de protocolo o diferencias de miles de líneas.
Aquí está la explicación honesta y de alto nivel:
React Server Components utiliza un protocolo llamado Flight, que serializa datos y los envía a través de la red.
Los objetos se serializan. Los objetos luego se deserializan.
Nada inusual hasta ahora.
El Error Fatal
Durante la deserialización, React no verificó adecuadamente que ciertos campos en los datos serializados realmente pertenecieran allí.
Si un atacante creaba una carga maliciosa usando la propia sintaxis de referencia de objetos de Flight, podía
- Acceder a cadenas de prototipos a las que no debería tener acceso
- Obtener el constructor de Function
- Invocarlo con JavaScript arbitrario
- Usar APIs de Node.js (como
child_process) - Ejecutar comandos del sistema
Es el equivalente en JavaScript a entregarle a alguien las llaves de tu casa porque te dijo que “sentía que pertenecían en el llavero”.
La vulnerabilidad es elegante, aterradora y un recordatorio de que la serialización es el diablo.
Edición de imagen: Mark
La Realidad — Este Error Fue Prácticamente Diseñado para Atacantes
Seamos francos.
Cuando tu servidor automáticamente
- Analiza entradas controladas por el usuario
- Deserializa objetos
- Carga constructores dinámicamente
- Ejecuta JavaScript en el backend
…estás pidiendo a gritos un evento de seguridad.
Este error no es sorprendente. Lo único sorprendente es que no ocurrió antes.
JavaScript permite que las funciones se traten como datos. La serialización permite que los datos se conviertan en código. El renderizado en backend ejecuta ese código con permisos de servidor.
Esa tríada es poderosa. También es un campo minado.
Lo Que Debes Hacer Ahora Mismo
Omitamos las florituras y vayamos directamente a la lista de verificación.
1. Actualiza React Inmediatamente
React lanzó versiones parcheadas
- React 19.0.1
- React 19.1.2
- React 19.2.1
Si estás en React 18 y usas RSC indirectamente a través de un framework, el parche de tu framework es más importante.
2. Actualiza Next.js
Los equipos de Next.js han lanzado versiones parcheadas para las versiones menores activas.
Si estás en Next 14.3.x:
Regrésate a 14.0.0 O actualiza al último parche —el código defectuoso estaba aislado en 14.3.
3. Vuelve a Implementar Servidores Nuevos
No estoy bromeando.
Si tu máquina estuvo expuesta públicamente y no estabas usando sandboxing, asume que fue comprometida. Desmantela el servidor. Vuelve a implementar infraestructura limpia.
¿Contenedores? Reconstrúyelos.
¿EC2? Reemplázalos.
¿Hardware físico? Tienes mi más sentido pésame.
4. Rota los Secretos
Si el servidor podía ejecutar comandos de shell, asume que
- Las variables de entorno fueron leídas
- Los archivos fueron accedidos
- Los tokens fueron extraídos
Rota todo.
Sí, incluso los molestos.
5. Audita los Registros en Busca de Comportamientos Extraños
Busca
- Conexiones salientes inesperadas
- Procesos sospechosos
- Eventos de reinicio
- Artefactos extraños en
/tmp
Si ves algo extraño, no lo racionalices. Los servidores no se reinician solos porque “quizás el kernel tuvo un error”.
La Lección Incómoda
Cada pocos años, el universo nos recuerda que la abstracción no elimina la complejidad —solo la mueve a otro lugar.
Queríamos
- Componentes más limpios
- Mejor experiencia de desarrollo
- Interfaces de usuario renderizadas en servidor más rápidas
En cambio obtuvimos
- Ejecución de código arbitrario
- Desarrolladores gritando en Twitter
- Una migración masiva al rastreador de problemas de React
La innovación es genial. La seguridad aún importa.
Y cuando los frameworks intentan colapsar demasiadas capas juntas, el radio de impacto de un solo error se vuelve catastrófico.
Entonces… ¿Habría Salvado Rust?
Respuesta corta?
Probablemente no.
La serialización es riesgosa en cualquier lenguaje cuando mezclas código y datos.
Los serializadores de Rust (como Serde) evitan completamente enviar código a través de la red —lo cual es bueno.
Pero el diseño de RSC es fundamentalmente más complejo porque no solo envía JSON —envía instrucciones y comportamientos de componentes.
La elección del lenguaje por sí sola no resuelve riesgos arquitectónicos.
Finalmente — Y Un Llamado a la Acción
Si tu pila utiliza React Server Components, este es tu llamado de atención.
La seguridad no es una característica que agregas después. Es una restricción de diseño.
Y ignorarla es cómo terminamos con CVEs que pueden reiniciar tu máquina virtual con una sola solicitud HTTP.
Pero bueno —al menos aprendimos algo, ¿verdad?
Si este artículo te hizo reconsiderar tu configuración, compártelo con un compañero.
Dime qué crees que React debería haber hecho de manera diferente.
Guarda esto para que puedas referirte a él cuando estés parcheando tu aplicación.
Solo no lo ignores.
Porque el “desarrollo web moderno” ya es lo suficientemente caótico sin que los atacantes se unan a la fiesta.
Mantente seguro por ahí.