Next.js, Astro, Nuxt e WordPress Headless — Segurança em 2026

Mudar para headless não removeu a superfície de ataque. Apenas a deslocou. O registro de 2025-26 mostra onde: React Server Components (CVE-2025-55182, execução remota de código não autenticada, publicada em 3 de dezembro de 2025), server islands do Astro e endpoint de imagem, cache de payload Nuxt atrás de um CDN, pacotes npm e um backend WordPress que ainda executa PHP. Uma exportação totalmente estática sem runtime de servidor remove a maioria do risco em nível de framework. Muitos sites "estáticos" não são, porém. Abaixo você encontra os incidentes framework por framework, depois secrets, CSP, a cadeia de suprimentos, a origem WordPress e controles de edge, terminando com uma tabela de hardening que você pode adaptar à sua própria stack.

Por que "estático significa unhackable" deixou de ser verdade

Dito claramente: se seu build gera arquivos HTML, CSS e JS simples, e um CDN os serve, não há servidor de framework para atacar. Nenhum endpoint de React Server Components. Nenhuma server action. Nenhum middleware a contornar. Essa é uma superfície de ataque genuinamente pequena, e é por isso que a proposta antiga de Jamstack tinha peso.

Mas veja o que a maioria dos projetos Next.js, Astro e Nuxt realmente implanta em 2026. Uma server action para o formulário de contato. Middleware que verifica um cookie. Um endpoint de otimização de imagem. Server islands para um header personalizado. ISR ou revalidação sob demanda. Cada um desses significa que um processo está escutando requisições, analisando entrada e mantendo variáveis de ambiente. Isso é um servidor. Ele apenas não parece um no seu repo.

Então a pergunta não é "este site é headless?" É "o que executa no momento da requisição?" Três respostas honestas existem:

• Nada. Output puramente estático. Seu risco fica no pipeline de build e no CMS, não no framework.
• Um conjunto pequeno e conhecido de endpoints. Otimização de imagem, um handler de formulário. Corrija-os, restrinja-os, aplique rate-limit neles.
• Um runtime de aplicação completo. SSR, server actions, auth, acesso a banco de dados. Trate-o como qualquer web app, porque é um.

Já fiz a comparação arquitetônica com WordPress em outro lugar (veja headless vs WordPress security), então não vou repetir. Este post é o registro de incidentes e o que fazer a respeito.

Next.js: React2Shell, server actions e a armadilha do proxy

React2Shell

CVE-2025-55182 (React) e CVE-2025-66478 (Next.js) foram publicadas em 3 de dezembro de 2025. Críticas. Execução remota de código não autenticada através de requisições criadas para React Server Components. Conforme o changelog do Vercel, as versões do Next.js afetadas são >=14.3.0-canary.77, 15.x e 16.x usando o App Router. Os lançamentos do Next.js corrigidos são 15.0.5, 15.1.9, 15.2.6, 15.3.6, 15.4.8, 15.5.7 e 16.0.7, com React corrigido em 19.0.1, 19.1.2 e 19.2.1.

Velocidade importa aqui. Datadog Security Labs reportou código de exploit público e tentativas de exploração ativa até 5 de dezembro de 2025. Dois dias. Se seu processo de patch funciona em um ritmo mensal, essa lacuna é a exposição.

Vercel distribui npx fix-react2shell-next para atualizar versões afetadas. Qualquer rota que você tome, confirme a versão corrigida atual para sua linha de lançamento no aviso vinculado, porque os follow-ups mudaram os alvo.

Os follow-ups de 11 de dezembro

Em 11 de dezembro de 2025, a equipe Next.js publicou outra atualização de segurança cobrindo mais dois problemas:

• CVE-2025-55184, negação de serviço (alta). Um pedido do App Router pode travar o servidor. A primeira correção foi incompleta; a correção completa é rastreada como CVE-2025-67779.
• CVE-2025-55183, exposição de código-fonte (média). Um pedido malformado pode fazer com que uma Server Function retorne o código-fonte compilado de outras Server Functions. Qualquer coisa codificada nelas vaza. Segredos lidos do ambiente em tempo de execução não vazam.

O Pages Router não foi afetado, e não há solução alternativa. Atualize. As versões corrigidas incluem 14.2.35, 15.5.9 e 16.0.10 (verifique a recomendação para sua versão).

A lição das server actions é clara: uma server action é um endpoint HTTP público com uma convenção de chamada mais agradável. Trate seus argumentos como entrada hostil. Autorize dentro dela. E nunca escreva um segredo como uma string literal em um arquivo que uma server function possa alcançar.

Middleware não é um limite de autorização

CVE-2025-29927, divulgada em 21 de março de 2025 (CVSS 9.1), permitia que um header x-middleware-subrequest malformado contornasse middleware completamente. Se sua única verificação de autenticação estava no middleware, ela foi contornada. O relatório da Datadog lista correções em 12.3.5, 13.5.9, 14.2.25 e 15.2.3. Aplicativos hospedados no Vercel foram protegidos no nível de infraestrutura. Aplicativos auto-hospedados ficaram expostos até serem corrigidos.

Next.js 16 renomeia middleware.ts para proxy.ts e o executa no runtime Node.js por padrão; middleware.ts está descontinuado. Acho que o renome é honesto. Um proxy fica na frente do aplicativo. Pode redirecionar, reescrever, adicionar headers. Não deveria ser a única coisa entre um estranho e seus dados.

Onde colocar a verificação real:

1. Na camada de dados, ao lado da query que retorna as linhas.
2. Em cada server action que modifica algo.
3. Em route handlers, por rota.
4. No proxy apenas como um redirecionamento conveniente para usuários não autenticados, nunca como a fechadura.

Se remover proxy.ts expusesse dados, sua autorização está no lugar errado.

Astro: server islands, image endpoints e caminhos de middleware

O padrão do Astro é estático, o que é uma força. Mas três recomendações de segurança de 2025 atingiram as peças que adicionam um runtime.

XSS em server islands. CVE-2025-64764, publicada em 19 de novembro de 2025, alta (CVSS 7.1). Um XSS refletido através do parâmetro slots do endpoint de server islands. Afetou qualquer app usando server islands, mesmo quando o componente island não usa slots. As versões 5.15.6 e anteriores foram afetadas; 5.15.8 corrigiu. Os detalhes estão na recomendação de segurança do GitHub.

SSRF em image endpoint. CVE-2025-58179 afetou o adaptador @astrojs/cloudflare (11.0.3 através de 12.6.5). Com output 'server' e o serviço de imagem de compilação padrão, o endpoint de imagem não validava URLs, o que habilitava falsificação de requisição do lado do servidor. SSRF é desagradável porque o servidor faz a requisição de dentro da sua rede, onde pode alcançar serviços de metadados ou APIs internas.

Bypass de caminho no middleware. Astro 5.15.8 também corrigiu um bypass de normalização de caminho usando URLs duplo-codificadas (CVE-2025-64765). Mesma família de erro que o truque de header do Next.js: autorização que depende da URL parecer de uma certa forma.

Verifique os intervalos exatos de versão nas recomendações de segurança withastro/astro antes de decidir se você é afetado. Não vou adivinhar limites que não consigo indicar.

Astro 6 e CSP integrado

Astro 6 inclui uma API CSP em security.csp. De acordo com o anúncio da beta do Astro 6, ele faz hash de scripts e estilos agrupados (SHA-256 por padrão), e funciona em build e preview mas não em dev. Esse último ponto pega as pessoas: uma página que parece bem sob astro dev pode quebrar quando a política se aplica em um build de produção. Sempre teste a saída compilada.

Se você está construindo sites Astro para clientes e quer esse reforço desde o início, nossa página de desenvolvimento Astro cobre como configuramos os projetos.

Nuxt: envenenamento de cache de payload e o que `runtimeConfig.public` expõe

CVE-2025-27415

Publicado em 19 de março de 2025. Alto, CVSS 7,5, e o impacto é disponibilidade. A condição: você executa Nuxt atrás de um CDN que ignora a query string em sua chave de cache. Um atacante solicita algo como /?/_payload.json. Nuxt renderiza JSON para essa solicitação. O CDN o armazena em cache na chave para / e entrega esse JSON para cada visitante. Repetível a cada expiração do cache. Afetadas: versões 3.0.0 a antes de 3.16.0; corrigido na 3.16.0 (consultoria).

Observe que tipo de bug este é. O código Nuxt e a configuração do CDN se comportaram sensatamente isoladamente. Juntos, quebraram sua página inicial. Então a lição vai além de "atualize Nuxt": a configuração da chave de cache do CDN é parte da segurança da aplicação. Alguém na sua equipe deve ser responsável por ela, e deve estar documentada, não deixada como padrão do dashboard.

Uma verificação de staging rápida, usando apenas seu domínio de staging: solicite a página com uma query string incomum, veja o que volta, depois solicite a URL limpa e confirme que ainda é HTML. Se sua camada de cache permite ignorar query strings por desempenho, certifique-se de que as rotas internas do framework sejam excluídas dessa regra.

O que `runtimeConfig.public` expõe

Nuxt divide runtimeConfig em chaves privadas (apenas servidor) e runtimeConfig.public (enviadas ao navegador). O nome é o aviso. Qualquer coisa sob public está no payload da página para qualquer um ler. Coloque uma chave Stripe publicável lá, tudo bem. Coloque um token admin de CMS lá e você o publicou.

Secrets e variáveis de ambiente nos três

Cada framework tem uma regra de prefixo, e o prefixo significa "enviar para o navegador":

Leia a documentação de cada framework sobre isso, porque os detalhes diferem (Next.js insere valores NEXT_PUBLIC_ no bundle em tempo de compilação, o que também significa que mudar um requer uma recompilação). O princípio não difere. Se uma variável tem um prefixo público, trate-a como impressa na página inicial.

Três hábitos pegam a maioria dos erros:

• Nunca coloque um token com capacidade de escrita atrás de um prefixo público, nem mesmo "temporariamente".
• Pesquise sua saída compilada (.next/static, dist/, .output/public) por fragmentos de token antes de fazer o deploy.
• Dê ao seu front end uma credencial somente leitura, com escopo estreito, para o CMS, separada de qualquer coisa que um editor use.

A lição do 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.

Headers de segurança e CSP para sites Jamstack

Hospedagem estática facilita esquecer headers porque não há arquivo de configuração de servidor no repositório. Mas headers são onde você consegue proteção real e barata contra consequências de XSS (como o problema das server islands do Astro acima).

Conjunto baseline para enviar em todo site: Content-Security-Policy, Strict-Transport-Security, X-Content-Type-Options: nosniff, uma Referrer-Policy, e frame-ancestors (dentro de CSP) ou X-Frame-Options.

Nonce ou hash, não `unsafe-inline`

Uma CSP que permite 'unsafe-inline' para scripts dificilmente ajuda contra XSS. Você tem duas opções reais:

• Hashes. Hashes SHA-256 em tempo de build de cada script e estilo inline. Funciona bem para saída estática porque o conteúdo não muda por requisição. Isto é o que o Astro 6's security.csp automatiza.
• Nonces. Um valor aleatório gerado por requisição, adicionado ao header e a cada tag de script. Precisa de um servidor ou função edge para gerar, então se encaixa melhor em SSR do que em arquivos estáticos. Next.js documenta um padrão de nonce usando sua camada proxy.

Escolha pelo modelo de renderização. Estático puro: hashes. Dinâmico: nonces.

Liste cada origem de terceiros, por diretiva

Esta é a parte tediosa e é onde as políticas falham. Analytics, tag managers, fontes, embeds de vídeo, widgets de chat, provedores de formulários, seu host de imagens do CMS. Cada um precisa ser listado sob a diretiva correta: script-src, connect-src, img-src, font-src, frame-src. Um widget que carrega um script de uma origem e chama uma API em outra precisa de ambas.

Um exemplo de header, para mostrar apenas a forma (substitua suas origens reais, e o nonce deve ser gerado por requisição):

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'

Comece com Content-Security-Policy-Report-Only, colete violações por uma ou duas semanas, corrija a lista, depois force. E mantenha um arquivo de inventário curto de origens de terceiros e quem requisitou cada uma. Seis meses depois, ninguém lembra por que um widget de chat está em script-src.

A cadeia de suprimento npm: chalk, debug e Shai-Hulud

Seu framework pode estar corrigido e seu servidor travado, e uma dependência ainda pode arruinar sua semana. Dois eventos de 2025 mostram como.

chalk e debug, 8 de setembro de 2025. Um mantenedor foi phishing com um email falso de reset de 2FA do npmjs.help. Atacantes publicaram releases maliciosas de cerca de 18 pacotes, incluindo chalk e debug. O payload tinha como alvo roubar atividade de crypto-wallet de bundles de navegador. Pacotes foram removidos em aproximadamente 2 a 2,5 horas, conforme análise da Upwind. Duas horas é pouco. Mas um job de CI que resolveu versões novas naquele período enviou o payload para produção.

Shai-Hulud, setembro de 2025. O alerta da CISA de 23 de setembro de 2025 descreve um worm autorreplicante que comprometeu mais de 500 pacotes npm. Ele colheu tokens do GitHub e chaves de cloud (AWS, GCP, Azure), publicou-os em repositórios públicos do GitHub nomeados Shai-Hulud, e republicou a si mesmo em outros pacotes usando as próprias credenciais npm das vítimas. Uma segunda onda em novembro de 2025 supostamente atingiu aproximadamente 796 pacotes (relato secundário, então trate a figura como relatada).

Controles que teriam contido ambos

Nenhum incidente precisou de um exploit inteligente. Ambos confiavam em confiança automática em "latest". Então:

1. Faça commit do seu lockfile e instale com `npm ci`. Instala exatamente o que o lockfile diz e falha se package.json discorda. Sem drift silencioso para uma release envenenada.
2. Adicione um cooldown. Não adote versões na hora em que são publicadas. pnpm documenta um setting de idade mínima de release para isto. Um atraso de até um dia teria deixado a janela chalk/debug inteiramente de fora.
3. Desabilite scripts de instalação onde você puder. Worms como Shai-Hulud rodam através de scripts de lifecycle. Uma linha de exemplo .npmrc: ignore-scripts=true. Depois liste com permissão os poucos pacotes que realmente precisam de um passo de build.
4. Escopo tokens de CI. Um job de build raramente precisa de direitos de publicação ou chaves cloud amplas. Credenciais de curta duração e menor privilégio significam que um token roubado compra pouco.
5. Siga o conselho da CISA. Revise lockfiles incluindo dependências aninhadas, verifique caches de artefatos, fixe versões conhecidas como seguras, rotacione credenciais de desenvolvedores, exija MFA resistente a phishing no npm e GitHub, e ative verificação de secrets, Dependabot e proteção de branch.

A mesma desconfiança se aplica às ferramentas de IA agora sentadas em ambientes de dev. Escrevi sobre como avaliar skills, plugins e servidores MCP do Claude Code porque são outra forma de código de terceiros chegar perto dos seus tokens.

WordPress Headless: desacoplamento esconde o tema, não o PHP

Aqui está a parte que surpreende times. Ir headless remove a camada de tema público. Não remove WordPress. A aplicação PHP, o banco de dados, a REST API e wp-admin ainda estão lá, geralmente em um hostname público, porque o front end precisa alcançá-los.

wp2shell

O exemplo de 2026 é direto. CVE-2026-63030 (confusão de rota em lote da REST API, CVSS 9.8) encadeada com CVE-2026-60137 (SQL injection em WP_Query author__not_in, CVSS 5.9) oferece execução remota de código não autenticada no WordPress 6.9.0 até 7.0.1. Instalações padrão. Nenhum plugin necessário. O ponto de entrada é /wp-json/batch/v1. Correções chegaram em 17 de julho de 2026 nas versões 7.0.2, 6.9.5 e 6.8.6, como a FAQ da Tenable descreve.

Atacantes foram rápidos. Patchstack viu as primeiras tentativas de exploração cerca de 90 minutos após o lançamento da 7.0.2, bloqueou mais de 65.000 tentativas de mais de 1.500 IPs, e encontrou que 97% visavam o endpoint de lote. Um detalhe a mais importa para quem depende de um firewall: regras WAF apenas de URL não são suficientes, porque WordPress aceita rest_route no corpo do POST. Uma regra que corresponde /wp-json/batch/v1 no caminho a perde.

Travando o backend

O objetivo: fazer a origem WordPress ser algo que estranhos não podem alcançar, em vez de algo que meramente espera ser corrigido a tempo.

• Mantenha a origem fora da internet pública onde possível. IP allowlist, um proxy autenticado, ou uma rede privada entre front end e CMS. Se você puxa conteúdo no tempo de build para um site estático, a origem precisa apenas se comunicar com seu build runner.
• Exponha apenas os campos que o front end usa. Corte respostas REST e schemas GraphQL. Menos dados para fora, menos para abusar.
• Desabilite rotas não usadas, o endpoint de lote incluído, se nada na sua stack a chama.
• Restrinja WPGraphQL. Desligue introspection pública e queries não autenticadas a menos que você realmente precise delas.
• Escopo senhas de aplicação e tokens de preview. Um por integração, menor privilégio, revogado quando a integração termina.
• Mantenha auto-updates de core ligadas. Com uma janela de exploração de 90 minutos, um dia de patch semanal manual é o ritmo errado.

Se você prefere deixar essa parte para especialistas, nosso serviço de segurança WordPress cobre travar e monitorar o backend. Para a arquitetura ao redor, veja o guia headless WordPress 2026 e nossa página de desenvolvimento WordPress headless.

Hosting e controles de edge

Plataformas diferem no que protegem, e vale a pena conhecer os detalhes em vez de assumir. Pegue CVE-2025-29927: aplicativos hospedados no Vercel eram protegidos no nível de infraestrutura enquanto auto-hospedados não eram. Esse é um benefício real e documentado de uma plataforma gerenciada. Netlify e Cloudflare igualmente executam camadas de proteção na sua edge (features WAF, mitigação DDoS, regras gerenciadas, dependendo do plano). Auto-hosting oferece controle e coloca essas camadas na sua lista de tarefas.

O enquadramento honesto: proteções de edge ganham tempo. Elas não substituem patching. Uma regra de plataforma que bloqueia um padrão de exploração hoje nada diz sobre o próximo advisory, e uma configuração auto-hospedada com um pipeline de patch bem executado pode ser perfeitamente robusta.

O que configurar, independentemente de onde você hospeda:

• Regras WAF que inspecionam corpos, não apenas caminhos. O detalhe rest_route do wp2shell é o exemplo a lembrar.
• Limites de taxa em manipuladores de formulários, ações do servidor, rotas de login e qualquer endpoint que dispara trabalho custoso. Isso também reduz bugs de negação de serviço como CVE-2025-55184.
• `remotePatterns` de imagem. No Next.js, images.remotePatterns restringe quais hosts remotos o otimizador de imagem buscará. Astro tem configurações equivalentes de domínio e padrão de imagem. Permita apenas seu host de CMS. Um proxy de imagem aberto é um convite a SSRF.
• Revisão de chave de cache. Conforme o incidente Nuxt, saiba o que sua CDN ignora.
• Proteção de origem. Faça a origem do app aceitar tráfego apenas de sua CDN ou plataforma onde a configuração permite, para que invasores não possam ignorar a borda.

Se você está construindo no Next.js com um banco de dados atrás dele, a página de desenvolvimento Next.js e Supabase mostra como escopo de acesso do lado do servidor.

A lista de verificação de hardening

Adapte isso à sua stack. Cada incidente nomeado abaixo vem das fontes citadas anteriormente; confirme versões corrigidas atuais em cada aviso vinculado em vez de confiar em qualquer tabela (incluindo esta) para números de versão.

FAQ

O Pages Router é afetado pelos problemas do Next.js de dezembro de 2025?

Para CVE-2025-55183 (exposição de código-fonte) e CVE-2025-55184 (negação de serviço), o aviso do Next.js descreve o caminho afetado como o App Router com Server Functions, e diz que o Pages Router não é afetado pela exposição de código. Não leia isso como "seguro para sempre". React2Shell também direcionou React Server Components no App Router, e você ainda precisa estar em uma versão corrigida. Verifique o aviso de dezembro de 2025 para sua linha de versão exata.

Devo girar secrets após aplicar o patch?

Se um secret foi alguma vez hard-coded em uma server function em uma versão afetada do Next.js, sim. Assuma que poderia ter sido lido, porque o bug retornou o código-fonte compilado. Gire-o e mova o substituto para uma variável de ambiente em runtime. Secrets que foram apenas lidos do ambiente não estavam nesse código-fonte, então o argumento de exposição é muito mais fraco para eles.

Como posso manter-me atualizado com avisos sem ler todo changelog?

Monitore os security advisories do GitHub para os repos dos quais você depende (Next.js, withastro/astro, Nuxt), e ative alertas do Dependabot para seus próprios repositórios. Inscreva quem é responsável por patching nesses feeds, não uma caixa de entrada compartilhada que ninguém lê. Para o núcleo do WordPress, mantenha auto-updates ativo e adicione um feed de vulnerabilidades como o do Patchstack.

Posso deixar wp-admin público se o front end só puxa conteúdo em tempo de construção?

Pode, mas não deveria. Se o front end só precisa da origem durante construções, não há razão para expô-la a todos. Allowlist os IPs do seu build runner e dos editores, ou coloque um proxy autenticado na frente. Editores com IPs variáveis são a reclamação usual, e um proxy com single sign-on resolve.

Velocidade de patch e configuração de cache-key são as duas coisas que times mais frequentemente fazem errado: exploits do Next.js e WordPress chegaram dias ou horas após a divulgação, e o bug do Nuxt só existiu porque um CDN ignorou a query string. Verifique o que realmente executa em tempo de requisição, autorize na camada de dados em vez de no proxy, e mantenha a origem do WordPress fora da internet aberta.