Vulnerabilidad de ejecución remota de código (RCE) en React y Next.js

 (github.com/vercel)
8 puntos por GN⁺ 2025-12-04 | 1 comentarios | Compartir por WhatsApp
  • Se reportó una vulnerabilidad de seguridad de ejecución remota de código (RCE) en React y Next.js
  • Este problema ocurre dentro del paquete de Next.js y permite que un atacante provoque la ejecución de código arbitrario mediante entrada maliciosa
  • Vercel divulgó la vulnerabilidad y lanzó una versión actualizada a través del aviso de seguridad de GitHub (GHSA-9qr9-h5gf-34mp)
  • Los usuarios deben actualizar a la versión más reciente para mitigar la vulnerabilidad
  • Este caso vuelve a destacar la importancia de la gestión de seguridad a nivel de framework

Resumen de la vulnerabilidad RCE

  • Se detectó una vulnerabilidad que permite ejecución remota de código en entornos Next.js y React
    • Existe el riesgo de que un atacante ejecute cualquier código JavaScript en el servidor
  • Esta vulnerabilidad aparece en el proceso de manejo de código interno del paquete Next.js
    • No se publicaron detalles concretos sobre la función o módulo vulnerable

Impacto y respuesta

  • Vercel anunció oficialmente el problema mediante el avviso de seguridad de GitHub (GHSA-9qr9-h5gf-34mp)
    • Ese aviso se publicó en la sección de avisos de seguridad del repositorio de Next.js
  • No se especificaron las versiones en las que existe la vulnerabilidad, pero se realizó una distribución de una versión actualizada
    • Se recomienda a los usuarios actualizar a la versión estable más reciente

Recomendaciones y medidas de seguridad

  • Todos los proyectos que usan el paquete Next.js deben verificar la versión inmediatamente
    • La versión de Next.js en package.json debe mantenerse actualizada
  • Vercel no mencionó medidas de mitigación adicionales además de la distribución de la versión corregida
  • El detalle técnico de la vulnerabilidad permanece sin divulgar, pues solo se entregó información limitada por motivos de seguridad

Importancia

  • Esta vulnerabilidad muestra el riesgo de ejecución de código en entornos de renderizado en el servidor
  • Los operadores de servicios basados en React y Next.js deben aplicar actualizaciones de seguridad con regularidad
  • Una vulnerabilidad de seguridad a nivel de framework puede tener un impacto directo en la seguridad de toda la aplicación

Lecturas relacionadas

1 comentarios

 
GN⁺ 2025-12-04
Comentarios de Hacker News

  • Esta vulnerabilidad es un caso en el que se hizo realidad el peor escenario posible sobre el que se venía advirtiendo desde la introducción de RSC/server actions
    El servidor deserializaba directamente entradas no confiables del cliente, buscaba el módulo y el nombre del export, y los ejecutaba
    Puede bloquearse con un parche de hasOwnProperty, pero el problema de fondo es no haber reconocido claramente que React estaba creando una capa RPC
    Frameworks RPC tradicionales como gRPC o SOAP dejan claros los límites con esquemas explícitos y definiciones de servicio, pero React es riesgoso porque expone cualquier API visible para el bundler
    Es muy probable que los problemas de seguridad derivados de este diseño se repitan en el futuro

    • Esto parece ser simplemente un problema de descuido
      Incluso con un esquema explícito, no sirve de mucho si al final se permite que una entrada no confiable haga referencia a cualquier objeto dentro del namespace del servidor
    • En la práctica, no se exponen todos los endpoints que pide el cliente
      Solo se exponen las funciones marcadas con "use server", y el equipo de React sí es consciente de que está diseñando un sistema RPC
      Este tipo de bug perfectamente podría ocurrir también en otros sistemas RPC (soy colaborador de React)
    • Que esto haya pasado pese a las advertencias al final solo puede verse como una implementación descuidada
    • Desde la perspectiva de un usuario común, da curiosidad si no usar este enfoque basta para estar a salvo
      Pero mantener un repo privado antiguo tampoco es una buena opción

  • Next tiene como única ventaja real el build estático
    Si dejan de darle soporte, ya no habría motivo para usarlo

  • Según el aviso de seguridad de Facebook/Meta, existe una vulnerabilidad de ejecución remota de código (RCE) antes de la autenticación en React Server Components versiones 19.0.0~19.2.0
    En el anuncio del blog oficial de React también explican que, debido a la estructura que permite al cliente invocar funciones del servidor, un atacante puede construir una solicitud HTTP maliciosa y ejecutar código arbitrario en el servidor

    • Si el cambio de la corrección fue agregar una verificación con hasOwnProperty, es probable que el ataque haya consistido en referenciar propiedades de la cadena de prototipos (__proto__, etc.)
    • Si la frase “el cliente puede invocar funciones del servidor” es una funcionalidad intencional, se siente como un diseño bastante aterrador

  • El commit de corrección parece ser este commit
    Da la impresión de que fue squash junto con varios cambios más, ocultando los detalles
    En el código se ve en 4 lugares un patrón de limitar la lista de funciones expuestas mediante whitelist

    • O quizá la causa fue este commit (indica explícitamente “corrección de vulnerabilidad de seguridad crítica”)

  • Vercel ya está bloqueando patrones de solicitudes maliciosas con protección a nivel de plataforma
    Ver el anuncio
    Cloudflare también respondió de forma preventiva con una regla de WAF

    • Se desplegaron medidas de mitigación preventivas en colaboración con varios socios
      Aun así, recomiendan encarecidamente actualizar de inmediato las dependencias de Next, React y otros meta-frameworks
    • También vale la pena revisar el anuncio de respuesta de Netlify y la entrada de blog de Deno Deploy/Subhosting
    • Yo lo parcheé y reconstruí directamente, y por si acaso también agregué una regla de Crowdsec WAF

  • Probé reproducir la vulnerabilidad usando el repositorio PoC

    • Incluso con react-server-dom-webpack parcheado se ejecuta el RCE, así que parece que el mecanismo no coincide del todo
      Estaría bien ver una demo en un proyecto real de Next.js
    • Aun así, el texto que lo explicó estuvo realmente impresionante

  • Esta vez quedó tan claro el vínculo entre entorno de hosting y seguridad que hasta surgió la frase “sin Vercel no hay RCE”

  • Un puntaje CVE de 10.0 es una cifra impactante para un proyecto tan usado

    • El paquete afectado react-server-dom-webpack indica explícitamente que es “experimental y bajo tu propio riesgo”
      Aun así, supera las 310 mil descargas semanales
    • En incidentes así, hay que indicar claramente CVSS 10.0 para que no quede tapado por declaraciones de PR
    • React se usa muchísimo, pero React Server Components todavía no es tan universal

  • Cuesta entender por qué el equipo de React dedica tiempo a funciones tan confusas
    No está claro qué mejora frente a SSR ni cuánto rendimiento aporta realmente
    La experiencia de desarrollo empeoró desde la introducción de Hooks, y en vez de mejorar eso, agregan otra capa de complejidad
    Preferiría que permitieran usar de forma natural el flujo de control propio de JS dentro de la lógica de componentes

    • Server Components no están directamente relacionados con SSR
      Yo lo veo como una capa BFF (Backend for Frontend) componentizada
      Cada fragmento de UI queda conectado directamente con la lógica de backend correspondiente, y puede obtener datos sin llamadas a fetch
      Eso facilita que frontend y backend evolucionen juntos, y permite cargar solo los datos necesarios con granularidad fina
      Al final, permite integrar de forma natural lógica de servidor exclusiva para la UI dentro de la estructura de componentes
    • Es una lástima que React se haya convertido en el “framework por defecto”
      El modelo basado en compilador de Svelte o de React es mucho más fácil de manejar
    • En el fondo, creo que el problema son las limitaciones del lenguaje JS y la falta de competencia
      Vue, Svelte y Angular requieren compiladores separados y extensiones de archivo propias
      En cambio, React/JSX ya recibe trato preferencial en la etapa de preprocesamiento
      Rust resolvió este tipo de problema con su sistema de macros — por ejemplo, Leptos y Yew soportan JSX o plantillas HTML dentro de archivos estándar .rs
      Si JS no adquiere una extensibilidad así, es muy probable que la web siga siendo un entorno complejo e ineficiente
    • A mí me gustan los hooks :)
    • RSC es un intento alternativo surgido porque no lograron hacer SSR realmente rápido
      Buscaron reducir la carga del lado del cliente, pero da la impresión de que hasta eso falló

  • También vale la pena revisar la explicación detallada del blog de React