Seguridad de Next.js, Astro, Nuxt y WordPress Headless en 2026

Pasar a headless no eliminó la superficie de ataque. La movió. El registro de 2025-26 muestra dónde: React Server Components (CVE-2025-55182, ejecución remota de código sin autenticación, publicado el 3 de diciembre de 2025), server islands de Astro y endpoint de imagen, caché de payload de Nuxt detrás de un CDN, paquetes npm, y un backend de WordPress que aún ejecuta PHP. Una exportación completamente estática sin runtime de servidor sí elimina la mayoría del riesgo a nivel de framework. Sin embargo, muchos sitios "estáticos" no lo son. A continuación, obtienes los incidentes marco a marco, luego secretos, CSP, la cadena de suministro, el origen de WordPress y controles de edge, finalizando con una tabla de endurecimiento que puedes adaptar a tu propio stack.

Por qué "estático significa inpirateable" dejó de ser verdad

Dilo claramente primero: si tu build genera archivos HTML, CSS y JS simples, y un CDN los sirve, no hay servidor de framework para atacar. Sin endpoint de React Server Components. Sin server action. Sin middleware para eludir. Esa es genuinamente una superficie de ataque pequeña, y es por eso que el antiguo pitch de Jamstack tenía peso.

Pero mira qué despliegan realmente la mayoría de proyectos de Next.js, Astro y Nuxt en 2026. Una server action para el formulario de contacto. Middleware que verifica una cookie. Un endpoint de optimización de imágenes. Server islands para un encabezado personalizado. ISR o revalidación bajo demanda. Cada uno de esos significa que un proceso está escuchando solicitudes, analizando entrada, y almacenando variables de entorno. Eso es un servidor. Solo que no se parece a uno en tu repo.

Entonces la pregunta no es "¿es este sitio headless?" Es "¿qué se ejecuta en tiempo de solicitud?" Tres respuestas honestas existen:

• Nada. Output puramente estático. Tu riesgo está en el pipeline de build y el CMS, no en el framework.
• Un conjunto pequeño y conocido de endpoints. Optimización de imágenes, un manejador de formulario. Parcha, restringe, limita la tasa.
• Un runtime de aplicación completo. SSR, server actions, auth, acceso a base de datos. Trátalo como cualquier aplicación web, porque eso es.

He hecho la comparación arquitectónica con WordPress en otro lugar (ver headless vs WordPress security), así que no la repetiré. Este post es el registro de incidentes y qué hacer al respecto.

Next.js: React2Shell, server actions y la trampa del proxy

React2Shell

CVE-2025-55182 (React) y CVE-2025-66478 (Next.js) se publicaron el 3 de diciembre de 2025. Crítico. Ejecución remota de código sin autenticación a través de solicitudes manipuladas a React Server Components. Según el changelog de Vercel, las versiones afectadas de Next.js son >=14.3.0-canary.77, 15.x y 16.x usando el App Router. Los lanzamientos corregidos de Next.js son 15.0.5, 15.1.9, 15.2.6, 15.3.6, 15.4.8, 15.5.7 y 16.0.7, con React corregido en 19.0.1, 19.1.2 y 19.2.1.

La velocidad importa aquí. Datadog Security Labs reportó código de exploit público e intentos de explotación activa al 5 de diciembre de 2025. Dos días. Si tu proceso de parche se ejecuta en un ritmo mensual, esa brecha es la exposición.

Vercel distribuye npx fix-react2shell-next para actualizar versiones afectadas. Sea cual sea la ruta que tomes, confirma la versión corregida actual para tu línea de lanzamiento en el aviso vinculado, porque los seguimientos cambiaron los objetivos.

Los seguimientos del 11 de diciembre

El 11 de diciembre de 2025, el equipo de Next.js publicó otra actualización de seguridad cubriendo dos problemas más:

• CVE-2025-55184, denegación de servicio (alto). Una solicitud del App Router puede colgar el servidor. La primera corrección fue incompleta; la corrección completa se rastrea como CVE-2025-67779.
• CVE-2025-55183, exposición de código fuente (medio). Una solicitud fabricada puede hacer que una Server Function devuelva el código compilado de otras Server Functions. Todo lo codificado en ellas se filtra. Los secretos leídos del entorno en tiempo de ejecución no.

El Pages Router no fue afectado, y no hay solución temporal. Actualiza. Las versiones corregidas incluyen 14.2.35, 15.5.9 y 16.0.10 (consulta el aviso para tu línea).

La lección de server actions es contundente: una server action es un endpoint HTTP público con una convención de llamada más agradable. Trata sus argumentos como entrada hostil. Autoriza dentro de ella. Y nunca escribas un secreto como literal de cadena en un archivo al que una server function pueda acceder.

Middleware no es un límite de autorización

CVE-2025-29927, divulgado el 21 de marzo de 2025 (CVSS 9.1), permitía que un encabezado x-middleware-subrequest fabricado omitiera middleware por completo. Si tu única comprobación de autenticación vivía en middleware, fue eludida. El análisis de Datadog lista correcciones en 12.3.5, 13.5.9, 14.2.25 y 15.2.3. Las aplicaciones alojadas en Vercel estaban protegidas a nivel de infraestructura. Las aplicaciones auto-alojadas estuvieron expuestas hasta que se parcheron.

Next.js 16 renombra middleware.ts a proxy.ts y lo ejecuta en el tiempo de ejecución de Node.js por defecto; middleware.ts está deprecado. El cambio de nombre es honesto, creo. Un proxy se sitúa delante de la aplicación. Puede redirigir, reescribir, añadir encabezados. No debería ser lo único que se interpone entre un extraño y tus datos.

Dónde poner la comprobación real:

1. En la capa de datos, junto a la consulta que devuelve las filas.
2. En cada server action que muta algo.
3. En manejadores de ruta, por ruta.
4. En proxy solo como un redireccionamiento de conveniencia para usuarios desconectados, nunca como el candado.

Si quitar proxy.ts expondría datos, tu autorización está en el lugar equivocado.

Astro: server islands, endpoints de imagen y rutas de middleware

El estándar de Astro es estático, lo cual es una fortaleza. Pero tres avisos de 2025 golpearon los fragmentos que añaden un tiempo de ejecución.

XSS de server islands. CVE-2025-64764, publicado el 19 de noviembre de 2025, alto (CVSS 7.1). Un XSS reflejado a través del parámetro slots del endpoint de server islands. Afectó a cualquier aplicación usando server islands, incluso cuando el componente island no usa slots. Las versiones 5.15.6 y anteriores fueron afectadas; 5.15.8 lo parcheó. Los detalles están en el aviso de GitHub.

SSRF de endpoint de imagen. CVE-2025-58179 afectó al adaptador @astrojs/cloudflare (11.0.3 a 12.6.5). Con output 'server' y el servicio de compilación de imagen por defecto, el endpoint de imagen no validaba URLs, lo que habilitó falsificación de solicitud del lado del servidor. SSRF es desagradable porque el servidor hace la solicitud desde dentro de tu red, donde puede alcanzar servicios de metadatos o APIs internas.

Omisión de ruta de middleware. Astro 5.15.8 también corrigió una omisión de normalización de ruta usando URLs codificadas dobles (CVE-2025-64765). Misma familia de error que el truco del encabezado de Next.js: autorización que depende de que la URL se vea de cierta manera.

Consulta rangos exactos de versión en los avisos de seguridad de withastro/astro antes de decidir si te afecta. No voy a adivinar límites a los que no pueda señalar.

Astro 6 y CSP integrado

Astro 6 envía una API de CSP bajo security.csp. Según el anuncio beta de Astro 6, crea hash de scripts y estilos incluidos (SHA-256 por defecto), y funciona en build y preview pero no en dev. Ese último punto atrapa a la gente: una página que se ve bien bajo astro dev puede romperse cuando la política se aplica en un build de producción. Siempre prueba la salida construida.

Si estás construyendo sitios Astro para clientes y quieres que ese endurecimiento esté integrado desde el inicio, nuestra página de desarrollo Astro cubre cómo configuramos los proyectos.

Nuxt: envenenamiento de caché de payload y qué expone `runtimeConfig.public`

CVE-2025-27415

Publicado el 19 de marzo de 2025. Alto, CVSS 7.5, y el impacto es la disponibilidad. La condición: ejecutas Nuxt detrás de un CDN que ignora la cadena de consulta en su clave de caché. Un atacante solicita algo como /?/_payload.json . Nuxt renderiza JSON para esa solicitud. El CDN lo cachea bajo la clave para / y sirve ese JSON a cada visitante. Repetible en cada expiración de caché. Afectadas: versiones 3.0.0 a anteriores a 3.16.0; parcheado en 3.16.0 (aviso).

Observa qué tipo de bug es este. El código de Nuxt y la configuración del CDN se comportaron sensatamente cada uno por su cuenta. Juntos, rompieron tu página de inicio. Entonces la lección va más allá de "actualiza Nuxt": la configuración de la clave de caché del CDN es parte de la seguridad de la aplicación. Alguien en tu equipo debe ser responsable de ella, y debe estar documentada, no dejada como un default del panel de control.

Una verificación rápida de staging, usando solo tu dominio de staging: solicita la página con una cadena de consulta inusual, mira qué vuelve, luego solicita la URL limpia y confirma que sigue siendo HTML. Si tu capa de caché permite ignorar cadenas de consulta por rendimiento, asegúrate de que las rutas internas del framework estén excluidas de esa regla.

Qué expone `runtimeConfig.public`

Nuxt divide runtimeConfig en claves privadas (solo servidor) y runtimeConfig.public (enviado al navegador). El nombre es la advertencia. Cualquier cosa bajo public está en el payload de la página para que cualquiera la lea. Poner una clave publicable de Stripe ahí, está bien. Poner un token de administrador de CMS ahí y lo has publicado.

Secretos y variables de entorno en los tres

Cada framework tiene una regla de prefijo, y el prefijo significa "enviar al navegador":

Lee la documentación de cada framework sobre esto, porque los detalles difieren (Next.js incrustra valores NEXT_PUBLIC_ en el bundle en tiempo de compilación, lo que también significa que cambiar uno requiere una recompilación). El principio no difiere. Si una variable tiene un prefijo público, trátala como impresa en la página de inicio.

Tres hábitos capturan la mayoría de los errores:

• Nunca pongas un token con capacidad de escritura detrás de un prefijo público, ni siquiera "temporalmente".
• Busca en tu salida compilada (.next/static , dist/, .output/public) fragmentos de token antes de desplegar.
• Dale a tu front end una credencial de solo lectura, estrictamente limitada en alcance, para el CMS, separada de cualquier cosa que un editor use.

La lección de CVE-2025-55183

That Next.js source-exposure bug is a neat illustration. It could return compiled source of Server Functions. Secrets read from the environment at runtime weren't in that source. Secrets pasted into the code as literals were. The framework bug was the framework's fault; the leaked API key was ours. After patching, if a literal secret ever lived in a server function on an affected version, assume it was readable and rotate it. Moving it to an env var is the fix for next time, not for the past.

Security headers y CSP para sitios Jamstack

El hosting estático hace fácil olvidar los headers porque no hay archivo de configuración del servidor en el repo. Pero los headers son donde obtienes protección real y económica contra las consecuencias de XSS (como el problema de Astro server islands arriba).

Conjunto base para enviar en cada sitio: Content-Security-Policy, Strict-Transport-Security, X-Content-Type-Options: nosniff, una Referrer-Policy, y frame-ancestors (dentro de CSP) o X-Frame-Options.

Nonce o hash, no `unsafe-inline`

Un CSP que permite 'unsafe-inline' para scripts apenas ayuda contra XSS. Tienes dos opciones reales:

• Hashes. SHA-256 hashes en tiempo de compilación de cada script y estilo inline. Funciona bien para salida estática porque el contenido no cambia por solicitud. Esto es lo que Astro 6's security.csp automatiza.
• Nonces. Un valor aleatorio generado por solicitud, agregado al header y a cada etiqueta script. Necesita un servidor o función edge para generarlo, así que se adapta mejor a SSR que a archivos estáticos. Next.js documenta un patrón de nonce usando su capa proxy.

Elige por modelo de renderizado. Estático puro: hashes. Dinámico: nonces.

Enumera cada origen de terceros, por directiva

Esta es la parte tediosa y es donde las políticas fallan. Analytics, tag managers, fuentes, embeds de video, widgets de chat, proveedores de formularios, tu host de imágenes del CMS. Cada uno necesita listarse bajo la directiva correcta: script-src, connect-src, img-src, font-src, frame-src. Un widget que carga un script de un origen y llama una API en otro necesita ambos.

Un header de ejemplo, solo para mostrar la estructura (reemplaza con tus orígenes reales, y el nonce debe generarse por solicitud):

Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-RANDOM' https://analytics.example.com; connect-src 'self' https://api.example.com; img-src 'self' data: https://cms.example.com; frame-ancestors 'none'; base-uri 'self'

Comienza con Content-Security-Policy-Report-Only, recopila violaciones durante una o dos semanas, corrige la lista, luego aplica. Y mantén un archivo de inventario corto de orígenes de terceros y quién solicitó cada uno. Seis meses después, nadie recuerda por qué un widget de chat está en script-src.

La cadena de suministro de npm: chalk, debug y Shai-Hulud

Tu framework puede estar parcheado y tu servidor asegurado, y una dependencia aún puede arruinarte la semana. Dos eventos de 2025 muestran cómo.

chalk y debug, 8 de septiembre de 2025. Un mantenedor fue suplantado con un correo falso de restablecimiento de 2FA desde npmjs.help. Los atacantes publicaron versiones maliciosas de aproximadamente 18 paquetes, incluyendo chalk y debug. El payload apuntaba a robar actividad de cripto-carteras desde bundles del navegador. Los paquetes fueron removidos dentro de aproximadamente 2 a 2.5 horas, según el análisis de Upwind. Dos horas es poco. Pero un trabajo de CI que resolvió versiones recientes en esa ventana envió el payload a producción.

Shai-Hulud, septiembre de 2025. La alerta de CISA del 23 de septiembre de 2025 describe un gusano autorreplicante que comprometió más de 500 paquetes de npm. Recolectó tokens de GitHub y claves en la nube (AWS, GCP, Azure), los publicó en repos públicos de GitHub llamados Shai-Hulud, y se republicó a sí mismo en otros paquetes usando las propias credenciales de npm de las víctimas. Una segunda ola en noviembre de 2025 supuestamente afectó aproximadamente 796 paquetes (reportería secundaria, así que trata la cifra como reportada).

Controles que los hubieran contenido

Ningún incidente necesitó un exploit ingenioso. Ambos se basaron en confianza automática en "latest". Así que:

1. Confirma tu lockfile e instala con `npm ci`. Instala exactamente lo que el lockfile dice y falla si package.json no está de acuerdo. Sin cambio silencioso a una versión envenenada.
2. Añade un cooldown. No adoptes versiones la hora que se publican. pnpm documenta una configuración de edad mínima de versión para esto. Un retraso de incluso un día hubiera evitado la ventana de chalk/debug completamente.
3. Deshabilita scripts de instalación donde puedas. Gusanos como Shai-Hulud se ejecutan a través de scripts de ciclo de vida. Una línea de ejemplo .npmrc: ignore-scripts=true. Luego lista blanca los pocos paquetes que realmente necesitan un paso de compilación.
4. Delimita los tokens de CI. Un trabajo de compilación raramente necesita derechos de publicación o claves amplias en la nube. Las credenciales de corta duración y con privilegios mínimos significan que un token robado permite poco.
5. Sigue los consejos de CISA. Revisa archivos de bloqueo incluyendo dependencias anidadas, verifica cachés de artefactos, fija versiones conocidas como seguras, rota credenciales de desarrolladores, requiere MFA resistente a phishing en npm y GitHub, y activa escaneo de secretos, Dependabot y protección de ramas.

La misma sospecha aplica a las herramientas de IA ahora en entornos de desarrollo. Escribí cómo evaluar habilidades de Claude Code, plugins y servidores MCP porque son otra forma en que el código de terceros se acerca a tus tokens.

WordPress headless: desacoplar no esconde el PHP

Aquí está la parte que sorprende a los equipos. Pasar a headless elimina la capa de tema público. No elimina WordPress. La aplicación PHP, la base de datos, la API REST y wp-admin siguen ahí, usualmente en un nombre de host público, porque el front end necesita alcanzarlos.

wp2shell

El ejemplo de 2026 es directo. CVE-2026-63030 (confusión de ruta por lotes de REST API, CVSS 9.8) encadenado con CVE-2026-60137 (inyección SQL en WP_Query author__not_in, CVSS 5.9) da ejecución remota de código sin autenticación en WordPress 6.9.0 a 7.0.1. Instalaciones por defecto. Sin plugins necesarios. El punto de entrada es /wp-json/batch/v1. Las correcciones llegaron el 17 de julio de 2026 en 7.0.2, 6.9.5 y 6.8.6, como detalla las preguntas frecuentes de Tenable.

Los atacantes fueron rápidos. Patchstack vio los primeros intentos de explotación cerca de 90 minutos después del lanzamiento de 7.0.2, bloqueó más de 65,000 intentos desde más de 1,500 IPs, y encontró que el 97% se dirigía al punto de acceso por lotes. Un detalle más importa para quien confía en un firewall: las reglas WAF solo por URL no son suficientes, porque WordPress acepta rest_route en el cuerpo POST. Una regla que coincida con /wp-json/batch/v1 en la ruta lo pierde.

Asegurar el backend

El objetivo: hacer que el origen de WordPress sea algo que los extraños no puedan alcanzar, en lugar de algo que solo espera ser parcheado a tiempo.

• Mantén el origen fuera de internet pública donde sea posible. Lista de IP permitidas, un proxy con autenticación, o una red privada entre front end y CMS. Si extraes contenido en tiempo de compilación para un sitio estático, el origen solo necesita comunicarse con tu ejecutor de compilación.
• Expone solo los campos que el front end usa. Reduce respuestas REST y esquemas GraphQL. Menos datos afuera, menos para abusar.
• Desactiva rutas no usadas, el punto de acceso por lotes incluido, si nada en tu stack lo llama.
• Restringe WPGraphQL. Desactiva introspección pública y consultas sin autenticación a menos que realmente las necesites.
• Delimita contraseñas de aplicación y tokens de vista previa. Una por integración, privilegios mínimos, revocada cuando la integración termina.
• Mantén las actualizaciones automáticas de núcleo activas. Con una ventana de explotación de 90 minutos, un día de parches semanal manual es el cadencia equivocado.

Si prefieres dejar esta parte a especialistas, nuestro servicio de seguridad de WordPress cubre asegurar y monitorear el backend. Para la arquitectura alrededor, consulta la guía headless WordPress 2026 y nuestra página de desarrollo WordPress headless.

Hosting y controles de edge

Las plataformas difieren en lo que protegen, y vale la pena conocer los detalles en lugar de asumir. Toma CVE-2025-29927: las aplicaciones alojadas en Vercel estaban protegidas a nivel de infraestructura mientras que las autohospedadas no. Ese es un beneficio real y documentado de una plataforma gestionada. Netlify y Cloudflare también ejecutan capas protectoras en su edge (características WAF, mitigación de DDoS, reglas gestionadas, dependiendo del plan). El autohospedaje te da control y pone esas capas en tu lista de tareas.

El marco honesto: las protecciones de edge te compran tiempo. No reemplazan el parcheado. Una regla de plataforma que bloquea un patrón de explotación hoy no dice nada sobre el próximo aviso, y una configuración autohospedada con un pipeline de parches bien ejecutado puede ser perfectamente sólida.

Qué configurar, sin importar dónde alojes:

• Reglas WAF que inspeccionen cuerpos, no solo rutas. El detalle rest_route de wp2shell es el ejemplo a recordar.
• Límites de velocidad en manejadores de formularios, acciones del servidor, rutas de inicio de sesión y cualquier endpoint que dispare trabajo costoso. Esto también mitiga bugs de denegación de servicio como CVE-2025-55184.
• `remotePatterns` de imagen. En Next.js, images.remotePatterns restringe qué hosts remotos usará el optimizador de imágenes. Astro tiene configuraciones equivalentes de dominio e patrones de imagen. Permite solo tu host CMS y nada más. Un proxy de imagen abierto es una invitación a SSRF.
• Revisión de cache-key. Por el incidente de Nuxt, sabe qué ignora tu CDN.
• Protección de origen. Haz que el origen de la aplicación acepte tráfico solo desde tu CDN o plataforma donde la configuración lo permite, para que los atacantes no puedan saltar el edge.

Si estás construyendo en Next.js con una base de datos detrás, la página de desarrollo de Next.js y Supabase muestra cómo limitamos el acceso del lado del servidor.

La lista de verificación de endurecimiento

Adapta esto a tu stack. Cada incidente nombrado abajo proviene de las fuentes citadas antes; confirma versiones corregidas actuales en cada aviso vinculado en lugar de confiar en ninguna tabla (incluyendo esta) para números de versión.

FAQ

¿Está afectado el Pages Router por los problemas de Next.js de diciembre de 2025?

Para CVE-2025-55183 (exposición de código fuente) y CVE-2025-55184 (denegación de servicio), el aviso de Next.js describe la ruta afectada como el App Router con Server Functions, y dice que el Pages Router no está afectado por la exposición de código. No lo interpretes como "seguro para siempre". React2Shell también apuntó a React Server Components en el App Router, y aún necesitas estar en una versión parcheada. Consulta el aviso de diciembre de 2025 para tu línea de versión exacta.

¿Debería rotar secretos después de aplicar el parche?

Si un secreto estuvo alguna vez hardcodeado en una server function en una versión afectada de Next.js, sí. Asume que pudo haber sido leído, porque el bug devolvía código compilado. Rotalo, luego mueve el reemplazo a una variable de entorno de runtime. Los secretos que solo se leyeron del entorno no estaban en esa fuente, así que el argumento de exposición es mucho más débil para ellos.

¿Cómo me mantengo al día con los avisos sin leer cada changelog?

Observa los avisos de seguridad de GitHub para los repos de los que dependen (Next.js, withastro/astro, Nuxt), y activa alertas de Dependabot para tus propios repositorios. Suscribe a quién sea responsable de parches a esas fuentes, no a una bandeja de entrada compartida que nadie lee. Para WordPress core, mantén las actualizaciones automáticas activadas y agrega un feed de vulnerabilidades como el de Patchstack.

¿Puedo dejar wp-admin público si el front end solo extrae contenido en tiempo de compilación?

Puedes, pero no deberías. Si el front end solo necesita el origen durante compilaciones, no hay razón para exponerlo a todos. Allowlist tu runner de compilación y las IPs de tus editores, o pon un proxy autenticado adelante. Los editores con IPs cambiantes son la queja habitual, y un proxy con single sign-on lo resuelve.

Velocidad de parche y configuración de cache-key son las dos cosas que los equipos más suelen hacer mal: los exploits de Next.js y WordPress llegaron días u horas después de la divulgación, y el bug de Nuxt solo existió porque un CDN ignoró la query string. Verifica qué realmente se ejecuta en tiempo de solicitud, autoriza en la capa de datos en lugar del proxy, y mantén el origen de WordPress fuera de internet abierta.