Respuesta a CVE-2025-55182: nuestra experiencia con la vulnerabilidad de React Server Components

El 3 de diciembre de 2025, el equipo de React divulgó CVE-2025-55182 – una vulnerabilidad de ejecución remota de código sin autenticación previa en React Server Components con una puntuación CVSS de 10,0. En los días siguientes, los equipos de inteligencia de amenazas de Amazon, Google y Microsoft informaron de explotación activa por parte de múltiples grupos de actores, incluidas operaciones patrocinadas por Estados; Amazon lo hizo a las pocas horas de la divulgación. La vulnerabilidad afecta a Next.js, React Router y a otros frameworks y empaquetadores que implementan React Server Components, como Waku y los plugins RSC de Parcel y Vite.

Este artículo documenta nuestra respuesta a una notificación del BSI (Oficina Federal Alemana de Seguridad de la Información) sobre uno de nuestros servidores de producción, y proporciona un marco de auditoría de seguridad para equipos que enfrentan situaciones similares.

Qué hace realmente CVE-2025-55182

CVE-2025-55182 explota la deserialización insegura en el protocolo RSC «Flight» – el mecanismo que React utiliza para serializar árboles de componentes entre servidor y cliente. Cuando un servidor recibe una solicitud POST especialmente diseñada, no valida correctamente la estructura de la carga útil, permitiendo que datos controlados por el atacante influyan en la lógica de ejecución del lado del servidor. El resultado es la ejecución arbitraria de código con los privilegios del proceso Node.js.

Lo que hace esto particularmente relevante es la superficie de ataque. Las configuraciones predeterminadas son vulnerables. Una aplicación Next.js estándar creada con create-next-app y compilada para producción puede ser explotada sin ningún cambio de código por parte del desarrollador. Las pruebas realizadas por Wiz Research demostraron una fiabilidad cercana al 100 %, y el exploit requiere solo una única solicitud HTTP sin autenticación.

El problema es que React Server Components se han convertido en infraestructura fundamental para las aplicaciones web modernas. Los datos de Wiz indican que el 39 % de los entornos en la nube contienen instancias que ejecutan versiones vulnerables. Para aplicaciones expuestas a internet, esa ventana de exposición representa un riesgo sustancial.

Qué nos sucedió

El 14 de enero de 2026, recibimos una notificación de seguridad automatizada de Hetzner, que reenviaba una alerta del equipo CERT-Bund del BSI. La notificación identificaba uno de nuestros servidores de producción – meinjagdschein.tva.sg ejecutándose en infraestructura de Hetzner Cloud – como servidor que alojaba una aplicación web vulnerable a CVE-2025-55182. La metodología de detección del BSI, documentada por SL Cyber, identificó la vulnerabilidad mediante escaneo externo sin necesidad de acceder a la propia aplicación.

La notificación llegó aproximadamente seis semanas después de la divulgación pública inicial el 3 de diciembre. Ese plazo es importante porque la explotación activa comenzó casi de inmediato. La inteligencia de amenazas de Amazon documentó intentos de explotación en cuestión de horas tras la divulgación, con campañas que desplegaban mineros de criptomonedas, shells inversos y mecanismos de acceso persistente. Google Threat Intelligence Group identificó distintas campañas que desplegaban el descargador SNOWLIGHT, la puerta trasera HISONIC y mineros XMRIG en sistemas comprometidos.

En realidad, la ventana de exposición representa el riesgo central en la gestión de vulnerabilidades. El tiempo entre la divulgación pública y el despliegue del parche determina si una vulnerabilidad teórica se convierte en una intrusión real.

Aplicación del parche

La corrección en sí es sencilla. Para aplicaciones Next.js, actualizar a las versiones parcheadas resuelve la vulnerabilidad. El registro de cambios de Vercel documenta las versiones específicas:

Las versiones estables de Next.js 14.x no están afectadas por CVE-2025-55182 (solo lo están 14.3.0-canary.77 y las versiones canary posteriores; estas deben sustituirse por la última versión estable de 14.x), aunque 14.2.35 es la versión de la rama 14.x que corrige el problema de denegación de servicio descubierto posteriormente. Para Next.js 15.x: actualizar a 15.0.5, 15.1.9, 15.2.6, 15.3.6, 15.4.8, 15.5.7 o posterior en cada versión menor respectiva. Para Next.js 16.x: actualizar a 16.0.7 o posterior.

Los paquetes subyacentes de React requieren la versión 19.0.1, 19.1.2 o 19.2.1 dependiendo de su versión actual. Las versiones posteriores 19.0.2, 19.1.3 y 19.2.2 corrigen la exposición de código fuente (CVE-2025-55183) y la denegación de servicio (CVE-2025-55184), y las versiones 19.0.3, 19.1.4 y 19.2.3 completan la corrección de denegación de servicio (CVE-2025-67779). Un aviso posterior, del 26 de enero de 2026, sustituyó estas versiones por 19.0.4, 19.1.5 y 19.2.4.

Para despliegues en producción que utilizan Docker, esto generalmente significa actualizar package.json, reconstruir la imagen del contenedor y volver a desplegar. El proceso sigue los mismos patrones de despliegue en contenedores que hemos documentado en nuestra guía de despliegue de aplicaciones React y en nuestro artículo sobre arquitectura multiinquilino con Docker.

Pero en realidad, aplicar el parche aborda la explotación futura. La pregunta más urgente después de una exposición prolongada es si el sistema ya ha sido comprometido.

Comprobación de posibles intrusiones

La naturaleza de la explotación de CVE-2025-55182 significa que los ataques exitosos suelen dejar rastros identificables. La actividad posterior a la explotación documentada por Unit 42, Google Threat Intelligence y los equipos de seguridad de Amazon sigue patrones consistentes: reconocimiento inicial, entrega de cargas útiles mediante comandos codificados en Base64, establecimiento de persistencia a través de tareas cron o servicios systemd, y movimiento lateral o despliegue de minería de criptomonedas.

Una auditoría sistemática debe examinar la actividad de procesos, las conexiones de red, los mecanismos de persistencia, los cambios en el sistema de archivos y la integridad de la aplicación.

Análisis de procesos se enfoca en identificar consumo inesperado de recursos (los criptomineros típicamente causan un uso elevado y sostenido de CPU) y nombres de procesos sospechosos. El malware conocido de las campañas React2Shell incluye variantes de xmrig, procesos que ejecutan scripts de shell mediante curl o wget, y nombres que imitan al kernel como variantes de kswapd o kworker que intentan mezclarse con procesos legítimos del sistema.

Análisis de red examina las conexiones activas en busca de tráfico saliente inesperado. La infraestructura de comando y control típicamente se comunica a través de puertos comunes (443, 8443, 8080) para evadir la detección del firewall, pero las conexiones a direcciones IP desconocidas merecen investigación. Las conexiones establecidas desde el proceso Node.js a direcciones fuera de las dependencias esperadas de la aplicación indican una posible intrusión.

Mecanismos de persistencia representan el indicador más fiable de explotación exitosa. Los atacantes que establecen acceso persistente típicamente modifican crontabs, crean servicios systemd, añaden claves SSH autorizadas o inyectan comandos en scripts de perfil de shell. Cualquier modificación a estos archivos durante la ventana de exposición requiere un examen cuidadoso.

Auditoría de claves SSH merece especial atención. Añadir claves SSH no autorizadas a los archivos authorized_keys proporciona a los atacantes una vía fiable para volver a acceder incluso después de que se aplique el parche de la vulnerabilidad inicial. Comparar las claves autorizadas actuales con las claves legítimas conocidas identifica claves añadidas que pueden indicar una intrusión.

Análisis del sistema de archivos examina los directorios temporales (/tmp, /var/tmp, /dev/shm) donde los atacantes frecuentemente almacenan cargas útiles, e identifica ejecutables o archivos de configuración modificados recientemente. La ventana de exposición – del 3 de diciembre de 2025 hasta el despliegue del parche – define el período de modificación relevante.

Verificación de integridad de la aplicación compara los archivos actuales de la aplicación con estados de referencia cuya integridad se ha verificado. Para aplicaciones bajo control de versiones, git status y git diff identifican modificaciones. Para despliegues en contenedores, comparar el contenido del contenedor en ejecución con la imagen de origen revela cambios introducidos después del despliegue.

Revisión de registros

Los registros del servidor web proporcionan visibilidad sobre los intentos de explotación, aunque una explotación exitosa puede no dejar rastros obvios dependiendo de la configuración de registro. El exploit React2Shell utiliza solicitudes POST a endpoints RSC, a menudo con cargas útiles inusuales en el cuerpo de las solicitudes.

Examinar los registros de acceso en busca de solicitudes POST durante la ventana de exposición, particularmente a rutas asociadas con React Server Components, puede revelar intentos de explotación. Sin embargo, la ausencia de entradas sospechosas en los registros no confirma la ausencia de intrusión – los atacantes con acceso persistente frecuentemente eliminan o modifican los registros para ocultar su actividad.

Los registros de autenticación (auth.log, entradas del diario de sshd) documentan intentos de inicio de sesión y accesos exitosos. Autenticaciones exitosas inesperadas, particularmente desde direcciones IP desconocidas o utilizando claves añadidas durante la ventana de exposición, indican una posible intrusión incluso si los registros de explotación a nivel de aplicación están ausentes.

Nuestro resultado

Después de un examen sistemático de nuestro sistema afectado, no encontramos evidencia de explotación exitosa. Ningún proceso inesperado, ninguna conexión de red sospechosa, ningún mecanismo de persistencia no autorizado, ninguna clave SSH modificada, ninguna evidencia de despliegue de cargas útiles en directorios temporales, y ningún cambio en los archivos de la aplicación fuera de la actividad normal de despliegue.

La ventana de exposición fue real – aproximadamente seis semanas entre la divulgación de la vulnerabilidad y nuestro despliegue del parche. El riesgo fue sustancial dadas las campañas de explotación activa documentadas. Pero en este caso, o bien nuestro sistema no fue objetivo durante esa ventana, los intentos de explotación no lograron ejecutar código, o cualquier actividad no dejó rastros que nuestra auditoría pudiera detectar.

Este resultado no valida la demora en la aplicación de parches. La ventana de exposición de seis semanas representa un riesgo inaceptable para la infraestructura de producción que maneja cualquier operación sensible. La respuesta correcta implica tanto la aplicación inmediata de parches cuando se conocen las vulnerabilidades como una auditoría sistemática para evaluar si se produjo una intrusión durante la exposición.

Lo que aprendimos

El sistema de notificación del BSI funcionó según lo previsto – el monitoreo externo identificó una vulnerabilidad que afectaba a infraestructura alojada en Alemania y alertó a la parte responsable a través del proveedor de alojamiento. Esto representa exactamente el modelo de seguridad colaborativa que debería existir para la infraestructura de internet.

El desafío radica en la latencia de respuesta. CVE-2025-55182 se divulgó el 3 de diciembre. Los parches estaban disponibles de inmediato. La explotación activa comenzó en cuestión de horas. Sin embargo, nuestra notificación llegó el 14 de enero – seis semanas después. Esa brecha refleja la realidad operativa de gestionar infraestructura de producción. No todas las organizaciones monitorean continuamente los avisos de seguridad de cada dependencia en su stack. El escaneo automatizado de vulnerabilidades existe pero requiere configuración y mantenimiento. Los entornos con múltiples aplicaciones amplifican el desafío.

Lo importante aquí es establecer procesos que reduzcan las futuras ventanas de exposición. Para aplicaciones React y Next.js específicamente, monitorear el blog de React y los avisos de seguridad de Next.js proporciona notificación directa de vulnerabilidades críticas. Para infraestructura más amplia, servicios como Dependabot, Snyk o herramientas similares automatizan el monitoreo de vulnerabilidades en dependencias a través de los proyectos.

Nuestra infraestructura – incluyendo el sistema tva-fetch documentado anteriormente – implementa patrones de despliegue en contenedores que facilitan la aplicación rápida de parches. Actualizar una dependencia significa reconstruir un contenedor y volver a desplegar, algo generalmente alcanzable en minutos una vez identificada la vulnerabilidad. Hemos cubierto estos patrones en detalle en nuestra guía de autoalojamiento de n8n y en nuestro tutorial de proxy inverso Traefik. Ese enfoque arquitectónico no previene las vulnerabilidades pero minimiza la fricción operativa al responder a ellas.

Si recibió una notificación similar

Si ha recibido notificaciones similares del BSI o de su proveedor de alojamiento sobre CVE-2025-55182, la prioridad de respuesta es clara: aplique el parche de inmediato y luego audite en busca de intrusiones.

Aplicar el parche previene la explotación futura pero no aborda una posible intrusión existente. El marco de auditoría anterior proporciona un punto de partida para un examen sistemático. Para organizaciones sin experiencia interna en seguridad, contratar servicios de respuesta a incidentes puede ser apropiado dependiendo de la sensibilidad de los sistemas y datos afectados.

La documentación es importante a lo largo de este proceso. Registre el estado actual del sistema antes de realizar cambios. Preserve los registros que podrían ser rotados o sobrescritos. Si aparecen indicadores de compromiso, deténgase y considere la preservación forense antes de la remediación que podría destruir evidencia útil para comprender el alcance del ataque.

La vulnerabilidad React2Shell representa un momento significativo para el ecosistema React – hasta donde sabemos, la primera RCE crítica sin autenticación previa que afecta a los componentes React del lado del servidor. El requisito de parcheo es sencillo, pero el incidente sirve como recordatorio de que los frameworks web modernos, a pesar de su comodidad de uso, introducen superficie de ataque del lado del servidor que requiere la misma atención de seguridad que cualquier otra infraestructura de servidor.

Resumen

CVE-2025-55182 demostró con qué rapidez una vulnerabilidad teórica se convierte en riesgo práctico. Actores patrocinados por Estados y grupos criminales integraron exploits en cuestión de horas tras la divulgación. La gravedad técnica – CVSS 10,0, sin autenticación requerida, explotación con una única solicitud HTTP – justificó la urgencia de la respuesta.

Para organizaciones que operan React Server Components en producción, la acción inmediata es verificar el estado de los parches en todos los despliegues. Para las que experimentaron ventanas de exposición prolongadas como la nuestra, una auditoría sistemática utilizando el marco anterior permite evaluar con una confianza razonable si el sistema ha sido comprometido, aunque la certeza completa sigue siendo difícil de alcanzar sin un análisis forense exhaustivo.

La lección más amplia se aplica más allá de esta vulnerabilidad específica. La gestión de dependencias en aplicaciones web modernas crea una superficie de ataque sustancial que requiere atención continua. El monitoreo automatizado de vulnerabilidades, los patrones de despliegue en contenedores que permiten actualizaciones rápidas y los procedimientos de respuesta a incidentes deberían ser prácticas operativas estándar en lugar de medidas reactivas implementadas después de que lleguen las notificaciones de seguridad.

Para equipos que gestionan aplicaciones Next.js o React y que se beneficiarían de consultoría en infraestructura o asistencia en auditorías de seguridad, tva ofrece servicios de asesoría técnica basados en nuestra experiencia con despliegues en producción de distintas escalas y con diferentes requisitos de seguridad. Los patrones arquitectónicos discutidos aquí reflejan lecciones aprendidas de contextos operativos reales.

¿Tiene preguntas sobre la seguridad de React Server Components o procedimientos de auditoría de infraestructura? Visite tva.sg/contact para iniciar una conversación sobre su entorno específico.