React2Shell: La vulnerabilidad crítica que afectó cada proyecto con Next.js App Router

Desplegaste rápido. Usaste IA para armar el esqueleto de la app, Next.js para manejar la lógica del servidor, y Vercel para deployar en minutos. Funcionó. Tus usuarios quedaron contentos. Seguiste adelante.

Entonces alguien mandó una petición HTTP y obtuvo tu código fuente. Queries de base de datos. API keys. Lógica de negocio. Todo.

Esto no fue hipotético. Pasó.

Primero, ¿qué es un CVE?

Un CVE (Common Vulnerabilities and Exposures) es básicamente un registro público que dice: "Este software tiene una falla de seguridad conocida, esto es lo que hace, y qué tan seria es."

Se califican del 0 al 10. Un puntaje de 10 significa que un atacante puede hacer el daño máximo con cero esfuerzo y cero acceso. Sin login. Sin configuración especial.

React2Shell obtuvo un 10.

Qué pasó exactamente

En diciembre de 2025, un investigador llamado Lachlan Davidson reportó una falla crítica en React Server Components — la tecnología detrás de las Server Functions de Next.js (también llamadas Server Actions).

La vulnerabilidad quedó registrada como CVE-2025-55182 para React y CVE-2025-66478 para Next.js. El apodo: React2Shell — porque le daba a los atacantes un camino directo desde una petición del navegador hasta ejecutar código arbitrario en tu servidor.

La versión simple de lo que estaba roto:

Cuando una app de Next.js recibe una petición que involucra Server Functions, usa algo llamado el protocolo React Flight para deserializar (decodificar) los datos entrantes. El problema era que esta deserialización no validaba correctamente lo que recibía.

Un atacante podía armar una petición POST maliciosa que el servidor interpretaba como una instrucción interna de confianza — y la ejecutaba.

Sin autenticación. Sin headers especiales. Confiabilidad cercana al 100% en configuraciones por defecto.

La parte que los developers no vieron venir

Aquí hay una Server Function que podrías haber escrito — o que tu asistente de IA escribió por ti:

// app/actions.js
'use server'
 
import { db } from '@/lib/db'
 
export async function getUserData(userId) {
  const user = await db.query(
    `SELECT * FROM users WHERE id = $1`,
    [userId]
  )
  return user.rows[0]
}

Parece bien. Está en el servidor. No está expuesto en el bundle del frontend. Asumiste que era segura.

Con React2Shell, un atacante no necesitaba encontrar tu endpoint. Podía armar una petición que disparaba rutas de ejecución no deseadas dentro del runtime de React — saltándose tu lógica por completo y ejecutando su propio código en tu servidor.

Y ese no era el único problema.

La filtración de código fuente de la que nadie habló

Después de que React2Shell fue parcheado, los investigadores siguieron investigando. Encontraron una vulnerabilidad de seguimiento: CVE-2025-55183.

Esta era más silenciosa — calificada con severidad media (CVSS 5.3) — pero profundamente incómoda.

En condiciones específicas, una petición maliciosa podía hacer que una Server Function retornara su propio código fuente como parte de la respuesta HTTP. No la salida compilada. El código real. Con tus queries de base de datos, lógica condicional, y todo lo que tuvieras hardcodeado dentro.

'use server'
 
// Este string literal podría quedar expuesto
const INTERNAL_API_KEY = 'sk-prod-abc123xyz'
 
export async function fetchReport() {
  const res = await fetch('https://internal-api.company.com/report', {
    headers: { Authorization: `Bearer ${INTERNAL_API_KEY}` }
  })
  return res.json()
}

Si hardcodeaste secretos directamente en tus Server Functions — aunque sea temporalmente, aunque sea "solo para probar" — esos secretos podían ser filtrados.

Nota: Los secretos cargados desde variables de entorno (process.env.API_KEY) no quedaron expuestos. Solo los string literals dentro del archivo fuente.

El parche que no era un parche

Aquí es donde se pone peor.

React y Next.js lanzaron un fix rápido. Muchos developers actualizaron y siguieron adelante. Pero el fix inicial estaba incompleto.

Se encontró una variante del ataque DoS (CVE-2025-55184) en las versiones parcheadas. Luego otro fix incompleto llevó a CVE-2025-67779. Developers que ya habían actualizado seguían siendo vulnerables sin saberlo.

La secuencia de actualizaciones requeridas:

Si actualizaste una vez en diciembre y no volviste a revisar, hay buenas chances de que seguías expuesto.

Quiénes estaban afectados

• Cualquier app usando Next.js App Router con Server Functions o Server Actions
• Apps de React 19 usando React Server Components con cualquier framework compatible con RSC
• Apps deployadas con configuraciones por defecto — no se necesitaba ninguna configuración especial para ser vulnerable

Quiénes no estaban afectados:

• Apps con Next.js Pages Router
• Apps sin código de React del lado del servidor
• Apps que no usan React Server Components

Si construiste algo en los últimos dos años con App Router y Server Actions — y la mayoría de las apps Next.js lo hacen — estabas en el grupo afectado.

Qué significa esto si deployas rápido

El flujo de trabajo de mover rápido y deployar es real y es útil. Los asistentes de IA arman apps rápido, Next.js maneja mucha complejidad por ti, y puedes ir de idea a producción en un fin de semana.

Pero esa velocidad crea un punto ciego específico: confías en que el framework maneja la seguridad, y el framework tenía una vulnerabilidad CVSS 10 en su configuración por defecto.

No hiciste nada mal. Seguiste la documentación. Usaste los patrones recomendados. Y millones de apps seguían expuestas.

La respuesta no es dejar de deployar rápido. Es agregar una capa que detecte lo que no puedes ver.

Cómo revisar tu estado actual

Ejecuta esto en tu proyecto:

npm list next react-server-dom-webpack

Compara la salida con las versiones seguras de la tabla anterior. Si estás atrás, actualiza:

npm install next@latest

Luego verifica de nuevo.

Si querés un escaneo más profundo — uno que revise tus repos en busca de secretos expuestos, patrones vulnerables y CVEs conocidos sin búsqueda manual — eso es exactamente lo que hace Data Hogo. Escaneo gratuito, sin tarjeta de crédito.

TL;DR

• React2Shell (CVE-2025-55182) permitió a atacantes ejecutar código arbitrario en tu servidor con una sola petición HTTP. CVSS 10.
• Una falla de seguimiento (CVE-2025-55183) permitió a atacantes leer el código fuente de tus Server Functions, incluyendo secretos hardcodeados.
• El primer parche estaba incompleto. Muchos developers que actualizaron seguían siendo vulnerables.
• Si usás Next.js App Router con Server Actions, revisá tu versión ahora.
• Los secretos en process.env están seguros. Los string literals hardcodeados en Server Functions no lo están.