Sí, actualiza a React 19.3.1 ahora: corrige una falla crítica en el transporte de React Server Components.
Por qué es urgente este parche
El 14 de octubre de 2026, React 19.3.1 llegó con cambios directos al protocolo de transporte de React Server Components. Ese mismo día se publicaron avisos de seguridad críticos relacionados con RSC, lo que confirma que el punto de ataque está en la forma en que el servidor serializa y deserializa los payloads del protocolo Flight.
En aplicaciones que usan Server Components, el servidor envía un árbol serializado al cliente para reconstruirse, y las Server Actions envían argumentos de vuelta para su ejecución. Si esa capa no valida correctamente lo que recibe, la deserialización puede derivar en ejecución remota de código en el servidor. Ahí radica la gravedad: no se trata de un problema en el navegador, sino en el proceso del servidor con acceso a archivos, variables de entorno y red interna.
El parche modifica precisamente esa validación. Por ese motivo, actualizar solo react y react-dom no basta en la gran mayoría de proyectos. El framework que integra el runtime, ya sea Next.js, Remix o un servidor propio con react-dom/server, también necesita su versión parcheada correspondiente para hablar el mismo protocolo.
Cómo actualizar sin romper dependencias
El orden correcto es actualizar primero el framework y después React con su DOM, fijando versiones exactas. Esto evita que un runtime nuevo intente comunicarse con una integración desactualizada.
# 1. Revisar versiones instaladas
npm ls react react-dom
# 2. Actualizar el framework primero (ejemplo con Next.js)
npm install next@latest
# 3. Fijar React y React DOM en 19.3.1
npm install react@19.3.1 react-dom@19.3.1 --save-exact
Con pnpm o yarn el procedimiento es equivalente. Lo fundamental es usar --save-exact o su variante, ya que react y react-dom deben compartir exactamente la misma versión. Un rango permite resolver a versiones distintas entre integrantes del equipo o en el pipeline de CI.
Verificar copias duplicadas
Cuando hay múltiples versiones de React en el árbol, los hooks fallan sin errores claros de compilación. Tras instalar, conviene revisar el árbol y deduplicar:
npm ls react react-dom
npm dedupe
Si persisten duplicados, usa overrides en package.json (npm) o resolutions (yarn). También es importante limpiar cachés de build antes de compilar, ya que frameworks como Next.js pueden conservar artefactos contra la versión anterior:
rm -rf .next node_modules/.cache
npm run build
En monorepos hay que actualizar todos los workspaces en la misma pasada, prestando especial atención a los peerDependencies que puedan arrastrar una segunda copia.
Validación tras el despliegue
Compilar correctamente no significa que el parche esté funcionando. La superficie afectada es el camino del servidor, así que la verificación debe ejercitarlo directamente.
Puntos a probar
- Server Actions. Ejecuta formularios que usen
action={...}y confirma que la respuesta es correcta sin errores de deserialización. - Streaming y Suspense. Prueba páginas con
loading.tsxo límites de Suspense. Cualquier cambio en el formato del payload se manifiesta primero ahí. - Autenticación. Prueba rutas con sesión válida e inválida. Los errores deben ser controlados, sin exponer trazas internas del servidor.
- Caché en borde. Purga la caché de CDN tras el despliegue. Un payload cacheado antes del parche puede seguir sirviéndose aunque el origen ya esté actualizado.
- Logs del servidor. Vigila las primeras horas en busca de errores de deserialización o referencias inválidas, especialmente si la integración entre framework y runtime quedó desalineada.
Lo ideal es desplegar a un ambiente intermedio o con tráfico gradual. Ten el commit anterior del lockfile listo para revertir rápidamente si aparecen errores.
Casos donde actualizar no es suficiente
Existen escenarios en los que el npm install parece correcto pero el riesgo persiste:
- Código vendorizado. Si hay una copia interna del runtime de React en el repositorio, esa copia no recibe el parche.
- Imágenes Docker antiguas. Actualizar
package.jsonsin reconstruir la imagen deja el contenedor connode_modulesviejo. Reconstruye sin caché de capas de dependencias. - Lockfile no versionado. Sin
package-lock.jsonen el repositorio, cada build puede resolver versiones distintas, lo que impide garantizar lo que corre en producción. - Superficie mínima. En una SPA estática sin RSC, el riesgo es menor, pero seguir conviene para mantener compatibilidad con librerías que ya asumen el runtime 19.3.x.
Si por alguna razón no puedes actualizar de inmediato, reduce superficie deshabilitando Server Actions y RSC si no se usan, y limita el acceso a las rutas que sí los utilizan. Eso es contención, no un reemplazo. En todo caso, programa la actualización con fecha y responsable. Para referencia oficial, consulta las notas de versión en react.dev y la documentación de tu framework (como nextjs.org).
El siguiente paso es sencillo: identifica qué framework usas, actualiza en orden en una rama, valida con los puntos anteriores y despliega con monitoreo activo. Ese pequeño esfuerzo elimina la superficie más crítica ahora mismo.
Preguntas frecuentes
¿Basta con actualizar React o también hay que actualizar Next.js?
Hay que actualizar ambos. React 19.3.1 corrige el runtime, pero el framework integra RSC con su propio código de servidor y pipeline de build. Actualiza el framework a la versión parcheada de tu línea y luego fija react y react-dom en 19.3.1 con versiones exactas.
¿Cómo sé si mi aplicación usa React Server Components?
Revisa si hay la directiva "use client" en archivos, si usas Server Actions con action={...} o componentes async que consultan datos directamente. En Next.js con App Router, RSC está activo por defecto. En una SPA con Vite, normalmente no lo está, aunque conviene alinear versiones igualmente.
¿El parche afecta el rendimiento?
Puede haber diferencias menores en el tamaño de payload o en el tiempo de deserialización por el cambio de protocolo. No se puede asumir en ninguna dirección, así que mide con tus propias rutas antes y después del despliegue, prestando atención al tamaño de los payloads de Flight.
¿Qué hago si no puedo actualizar de inmediato?
Reduce superficie deshabilitando Server Actions y RSC si tu producto no los necesita, y restringe el acceso a las rutas que sí los usan. Programa la actualización con fecha y responsable, y revisa los logs del servidor en busca de intentos de deserialización anómala mientras tanto.
¿Necesito cambiar código de mi aplicación?
En la gran mayoría de casos no. El parche es de runtime y protocolo. Solo podrías necesitar ajustes si dependías de comportamientos internos del payload, si tienes tests que comparan respuestas serializadas o si usas overrides para forzar versiones. Corre la suite completa tras la actualización.
