Nome do plugin	@nuxt/nitro-server
Tipo de vulnerabilidade	Script entre sites (XSS)
Número CVE	CVE-2026-46342
Urgência	Baixo
Data de publicação do CVE	2026-05-20
URL de origem	CVE-2026-46342

Nuxt Nitro ‘__nuxt_island’ Envenenamento de Cache Compartilhado (CVE-2026-46342) — O que os Proprietários de Sites WordPress Precisam Saber

Autor: Equipe de Segurança do Firewall WP
Data: 2026-05-20
Etiquetas: segurança, WordPress, WAF, Nuxt, headless, CVE-2026-46342

Resumo: Uma vulnerabilidade recentemente divulgada no servidor Nuxt Nitro impacta versões >= 4.2.0 e <= 4.4.5. Pode levar ao envenenamento de cache compartilhado e Cross-Site Scripting (XSS) via o __nuxt_island endpoint. O problema foi corrigido na versão 4.4.6. Se o seu site WordPress integra com front-ends JavaScript, arquiteturas headless, renderização em edge de CDN, ou usa componentes Nuxt/Nitro em sua cadeia de ferramentas, este aviso explica o risco, métodos de detecção, mitigação (incluindo regras de firewall/edge de emergência) e estratégias de fortalecimento da cadeia de suprimentos a longo prazo.

---

Por que isso é importante para os proprietários de sites WordPress

A maioria dos sites WordPress usa templates PHP e renderização do lado do servidor via a pilha WordPress. No entanto, um número crescente de sites WordPress está integrado com front-ends JavaScript modernos (Nuxt, Next, Remix) para desempenho e experiência do desenvolvedor — uma arquitetura “headless” ou “desacoplada”. Esses front-ends geralmente dependem de servidores baseados em Node, middleware Nitro e caches/CDNs em edge.

O problema relatado (CVE-2026-46342) afeta um endpoint do servidor Nitro usado por front-ends Nuxt: __nuxt_island. Quando o servidor falha em vincular respostas de forma rígida às propriedades da solicitação de origem, um cache compartilhado pode servir uma resposta criada para um usuário a outro usuário. Se essa resposta contiver conteúdo controlado pelo atacante (por exemplo, HTML não sanitizado ou fragmentos de script), um atacante pode envenenar caches e acionar Cross-Site Scripting para muitos visitantes do site.

Mesmo que seu backend WordPress não esteja executando Node diretamente, sistemas WordPress podem ser impactados quando:

• Seu site WordPress usa um front-end Nuxt ou Nitro que puxa dados da API REST do WordPress ou GraphQL.
• Seu ambiente de hospedagem usa serviços de renderização do lado do servidor ou serviços de renderização em edge que incluem componentes baseados em Nitro.
• Seu CI/CD, pipeline de construção ou serviços de terceiros usam o pacote vulnerável para gerar pré-visualizações, implantar front-ends ou renderizar páginas em edge.

Este aviso é escrito a partir de uma perspectiva de segurança do WordPress. Vamos nos concentrar em passos práticos de detecção e remediação que você pode aplicar imediatamente, além de orientações de fortalecimento a longo prazo e regras de WAF/edge.

---

Visão geral técnica — o que está quebrado

Em linhas gerais:

• O __nuxt_island O endpoint é responsável por renderizar ou hidratar componentes isolados (pequenos fragmentos interativos) no modelo de renderização híbrido do Nuxt.
• O comportamento vulnerável: as respostas retornadas pelo endpoint não estão suficientemente vinculadas às propriedades da solicitação (origem, cabeçalhos, cookies, parâmetros de consulta). Se uma camada de cache (CDN, proxy reverso ou cache compartilhado do lado do servidor) armazenar essa resposta sem os cabeçalhos Vary/Cache-Control apropriados ou chaves de cache, a resposta em cache pode ser servida a outras solicitações que diferem em propriedades críticas da solicitação.
• Se um atacante puder elaborar uma solicitação que inclua conteúdo controlado pelo atacante (por exemplo, via propriedades injetadas, payloads em parâmetros de consulta ou dados refletidos de respostas de API) e causar que essa resposta seja armazenada em cache, o atacante pode envenenar o cache compartilhado. Quando outros usuários recebem essa resposta em cache, qualquer script malicioso dentro será executado em seus navegadores (cenário de XSS refletido ou armazenado) — resultando em um impacto generalizado, uma vez que caches atendem a muitos usuários.

O resultado final: um único exploit pode se transformar em XSS em massa via uma página em cache envenenada ou fragmento isolado.

---

Superfície de ataque para sites WordPress

Aqui estão padrões de integração comuns que expõem sites alimentados por WordPress a esse problema:

• WordPress sem cabeça + front-end Nuxt:
  • WordPress serve conteúdo via REST API / GraphQL.
  • O front-end Nuxt usa Nitro para renderizar no servidor ilhas que incluem conteúdo do WP.
  • Pacote Nitro vulnerável usado no processo de front-end pode causar envenenamento de cache.
• Renderização de borda / pré-visualização de CDN / geração de imagem OG:
  • Alguns geradores de pré-visualização de borda ou endpoints de imagem incluem renderização baseada em Nitro.
  • Se seu provedor de hospedagem ou CI usa componentes Nitro, esses endpoints podem ser afetados.
• Ferramentas de desenvolvedor:
  • Sistemas de construção e pré-visualização (storybook, pré-visualizações SSR, geradores de sites estáticos) que instalem a dependência vulnerável podem criar ou enviar artefatos envenenados ou saída em cache.
• Integrações de terceiros:
  • Fornecedores de plugins, construtores de temas ou provedores de serviços sem cabeça podem estar executando pré-visualizações baseadas em Nitro. Se eles forem comprometidos ou usarem versões vulneráveis, os sites dos clientes podem ser impactados indiretamente.

Se seu site WordPress for puramente clássico (sem front-end sem cabeça, sem ferramentas Node em implantações), o risco é muito menor. Mas em ambientes modernos de DevOps, vale a pena verificar.

---

Como os atacantes podem explorá-lo (cenários práticos)

• XSS refletido via fragmento de ilha em cache:
  • O atacante envia uma solicitação especialmente elaborada para __nuxt_island com parâmetro controlado pelo atacante.
  • Nitro gera um fragmento contendo o parâmetro sem a devida sanitização.
  • O CDN armazena em cache o fragmento para uma chave compartilhada.
  • Visitantes subsequentes recebem o fragmento em cache; o JavaScript do atacante é executado em seus navegadores.
• Envenenamento semelhante ao armazenado via dados de upstream:
  • Se o front-end renderiza dados de uma API de terceiros ou de um sistema de comentários que aceita entrada do usuário, um atacante armazena entrada maliciosa nessa fonte.
  • O servidor renderiza a ilha com o conteúdo malicioso; a resposta é armazenada em cache e depois servida a outros.
• Abuso em larga escala:
  • Os caches de borda significam que um único objeto em cache pode afetar milhares de visitantes. Os atacantes preferem rotas de envenenamento de cache, pois o impacto é amplificado.

---

Patch e atualização — a correção mais importante

Se você usar Nuxt/Nitro em qualquer parte de sua pilha, atualize o pacote afetado imediatamente:

• Afetados: @nuxt/nitro-server ≥ 4.2.0 e ≤ 4.4.5
• Corrigido em: 4.4.6 (atualize para 4.4.6 ou posterior)

Ações:

1. Para projetos que usam npm/yarn/pnpm:
   • Execute npm install @nuxt/nitro-server@^4.4.6 (ou atualize seu package.json e execute seu gerenciador de pacotes).
   • Atualize os arquivos de bloqueio (package-lock.json, yarn.lock, pnpm-lock.yaml) e os envie.
2. Para builds em contêiner:
   • Reconstrua as imagens e reimplante após atualizar o pacote e o arquivo de bloqueio.
   • Evite depender de versões implícitas mais recentes — use versões fixas e reconstrua imagens com frequência.
3. Para serviços de borda ou de pré-visualização que você não controla:
   • Entre em contato com seu provedor ou proprietário do serviço e solicite confirmação da correção.
   • Instrua-os a atualizar para 4.4.6+ e a invalidar caches após a correção.

Se você não puder atualizar imediatamente, use as mitig ações abaixo.

---

Mitigações imediatas que você pode aplicar agora (mesmo antes da correção)

Estas são medidas práticas que você pode implementar rapidamente para reduzir a exposição.

1. Desative o cache compartilhado para o endpoint da ilha
   • Certifique-se de que as respostas de __nuxt_island estão marcadas como não cacheáveis por caches compartilhados:
   • Definir Cache-Control: privado, sem-cache, sem-armazenar, deve-revalidar (escolha a diretiva apropriada para o seu ambiente).
   • Adicionar Vary cabeçalhos para incluir cookies/autorização/anfitrião se as respostas dependerem deles: Vary: Cookie, Autorização, Aceitar-Codificação, Host.
   • Se você controla as regras do CDN, crie uma regra para ignorar o cache para qualquer caminho que corresponda /__nuxt_island ou similar.
2. Correção virtual com suas regras WAF / de borda
   • Crie uma ou mais regras de firewall para bloquear ou desafiar solicitações para /__nuxt_island que contenham cargas úteis suspeitas:
   • Bloqueie solicitações contendo <script, onerror=, onload=, tokens de script codificados (por exemplo, <script), ou padrões XSS flagrantes em strings de consulta.
   • Limite a taxa ou desafie com CAPTCHA solicitações anômalas para esse caminho.
   • Se viável, bloqueie solicitações onde Aceitar os cabeçalhos indicam renderização HTML mais valores de consulta suspeitos.
   • Exemplo de regra estilo ModSecurity (conceitual):

   SecRule REQUEST_URI "@contains /__nuxt_island" "id:100001,phase:1,log,deny,ctl:forceRequestBodyVariable=On,msg:'Bloquear solicitações de ilha suspeitas'"
         

   Adapte IDs e severidade ao seu ambiente. Teste antes de bloquear em produção.

3. Limpe caches
   • Se você acredita que a contaminação ocorreu (ou como precaução), limpe caches em todos os níveis:
     • caches de borda CDN
     • caches de proxy reverso (Varnish)
     • caches de aplicação (se houver)
   • Use cabeçalhos de quebra de cache ou versionamento para fragmentos de ilha, se necessário.
4. Adicione Política de Segurança de Conteúdo (CSP)
   • Implemente ou aperte CSP para páginas que incluem fragmentos de ilha:
     • Exemplo: Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-...'; object-src 'none'; base-uri 'self';
     • Um CSP rigoroso pode limitar o impacto de XSS mesmo que um atacante injete uma tag de script.
5. Aumente a validação/sanitização de respostas
   • No lado do servidor (Nuxt ou serviços a jusante), certifique-se de que qualquer dado vinculado às respostas esteja devidamente escapado ou sanitizado antes de ser incluído no HTML renderizado pelo servidor.
6. Monitore logs e tráfego
   • Procure por aumentos súbitos nas solicitações para __nuxt_island.
   • Inspecione padrões recorrentes em strings de consulta ou corpos POST que incluam tokens de script.
   • Monitore padrões de acerto de cache de borda e chaves de cache.

---

Sugestões de WAF e regras de borda (concretas)

Abaixo estão regras práticas que você pode adaptar. Elas são intencionalmente genéricas e devem ser testadas em staging primeiro.

Trecho Nginx para definir cabeçalhos de cache para o endpoint island:

location ~* /__nuxt_island {

Regras simples de ModSecurity (conceituais):

# Negar solicitações contendo padrões XSS óbvios para o endpoint da ilha"

Dureza de resposta via trabalhador de borda (pseudo-código):

• Interceptar respostas para /__nuxt_island.
• Se a resposta contiver <script ou JS inline suspeito E a solicitação não tiver autenticação adequada ou cabeçalho esperado, rejeitar/desafiar a resposta e não armazenar em cache.
• Caso contrário, garantir que a resposta tenha Cache-Control: privado.

Dureza da chave de cache:

• Garantir que as chaves de cache incluam propriedades específicas do usuário onde o conteúdo varia (Cookie, cabeçalho de Autorização, Accept-Language, etc.). Uma chave de cache mal configurada que ignora cookies é uma das principais causas de envenenamento.

Limitação de taxa:

• Aplicar limites de taxa em solicitações para __nuxt_island, por exemplo, 5 solicitações por minuto por IP, para reduzir a viabilidade de tentativas de envenenamento.

Lembre-se: tome medidas incrementais em staging e monitore falsos positivos. As regras do WAF são instrumentos imprecisos; teste para evitar quebrar o tráfego legítimo.

---

Detecção: como saber se você foi afetado

1. Faça um inventário da sua pilha
   • Pesquise em seu código-fonte, configurações de CI/CD e logs de construção por referências a @nuxt/nitro-server, nuxt, nitro, e __nuxt_island.
   • Usar npm ls @nuxt/nitro-server ou equivalente para listar versões instaladas.
   • Verificar package-lock.json, yarn.lock, pnpm-lock.yaml para encontrar dependências transitórias.
2. Inspecione logs do servidor e CDN
   • Procure por tráfego para caminhos como /__nuxt_island (ou endpoints de ilha/hidratação semelhantes).
   • Procure por solicitações com strings de consulta suspeitas contendo script, onerror, ou variantes codificadas (%3C, <).
3. Revise respostas em cache
   • Busque HTML de borda em cache para páginas e inspecione por 4. tags ou manipuladores de eventos inline que você não escreveu.
   • Se seu CDN suportar inspeção de cache, verifique objetos em cache para conteúdo incomum.
4. Escaneamento automatizado
   • Execute scanners de dependência (npm audit, ferramentas SCA) para localizar versões de pacotes vulneráveis.
   • Use scanners da web (detectores de XSS) para investigar endpoints de renderização com segurança em staging.

---

Se você acha que foi atingido — passos imediatos de incidente

1. Retire o endpoint vulnerável do cache público:
   • Defina temporariamente Cache-Control: no-store em pontos finais da ilha.
   • Limpar caches em CDN e proxies.
2. Reconstruir e corrigir:
   • Atualizar @nuxt/nitro-server para 4.4.6+.
   • Reconstruir contêineres e reimplantar.
3. Contenha e investigue:
   • Isolar servidores ou processos suspeitos.
   • Despejar logs para o intervalo de tempo de suspeita de contaminação.
   • Identificar e listar chaves de cache afetadas e purgá-las.
4. Limpe e endureça:
   • Remover ou sanitizar quaisquer cargas úteis maliciosas persistidas em fontes de dados upstream.
   • Rotacionar segredos que podem ter sido expostos.
   • Reavaliar CSP e sanitização de entrada.
5. Comunicar:
   • Se os dados do usuário estavam em risco ou a exploração era pública, siga sua política de divulgação de incidentes e notifique as partes interessadas.

---

Fortalecimento de longo prazo da cadeia de suprimentos e implantação para proprietários do WordPress

• Manter um inventário de dependências:
  • Rastrear dependências de Node e PHP usadas pelo seu site e seu pipeline de CI.
  • Executar periodicamente varreduras SCA (Análise de Composição de Software) em todos os pacotes.
• Fixar e bloquear dependências:
  • Usar pinos de versão exatos em pacote.json para pacotes críticos de produção.
  • Comite arquivos de bloqueio e execute reconstruções regulares.
• Automatize atualizações:
  • Use ferramentas automatizadas (estilo renovate ou auditorias programadas) para propor atualizações; teste e implante regularmente.
  • Considere um pipeline automatizado que reconstrua imagens e execute testes de integração quando patches de dependência forem lançados.
• Limite a superfície de cache:
  • Ative o cache compartilhado agressivo apenas para ativos verdadeiramente estáticos.
  • Para fragmentos dinâmicos ou fragmentos personalizados para o usuário, use Cache-Control: privado ou evite o cache.
• Reforce a renderização do front-end:
  • Garanta que fragmentos renderizados no servidor escapem dados do usuário por padrão.
  • Adote motores de template que auto-escapem ou sanitizem explicitamente campos perigosos.
• Exija cabeçalhos seguros:
  • CSP, X-Content-Type-Options, Referrer-Policy, X-Frame-Options, Strict-Transport-Security — mantenha esses aplicados em todo o site.
• Monitore e registre:
  • Logs agregados para acesso a endpoints e comportamento de cache ajudam a detectar anomalias mais cedo.
  • Monitore eventos WAF/edge e mantenha regras sob revisão.

---

Recomendações específicas para WordPress (lista de verificação prática)

• Se seu site for headless:
  • Confirme quais versões e pacotes de front-end estão sendo usados; atualize o Nitro quando necessário.
  • Garanta que as respostas da sua API REST do WordPress codifiquem e sanitizem campos HTML corretamente.
  • Garanta que os ambientes de pré-visualização e CI sejam tão seguros quanto a produção.
• Se o seu site usa um pipeline Jamstack ou SSR (por exemplo, Netlify, Vercel, outros provedores):
  • Entre em contato com seu provedor para confirmação do status do pacote Nitro em seus ambientes.
  • Limpe os caches de borda após as atualizações.
• Se o seu site é WordPress clássico, mas você depende de plugins ou serviços de terceiros que podem renderizar páginas na borda:
  • Verifique os fornecedores de plugins para notificações e atualizações.
  • Pergunte às equipes de hospedagem ou plataforma sobre o uso do Nitro em sua pilha.

---

Sinais de monitoramento a serem observados nas próximas semanas

• Aumento de solicitações atingindo __nuxt_island com cargas úteis que incluem codificadas 4. formulários.
• Aparição repentina de scripts inline no HTML em cache servido pelo seu CDN.
• Aumentos de hits de regras WAF/borda ligados a endpoints de ilha.
• Relatórios de pop-ups, redirecionamentos ou javascript inesperado em páginas que eram anteriormente estáticas.

Se você ver esses sinais, trate-os seriamente: limpe caches, aplique patches virtuais e atualize pacotes.

---

Proteja seu site gratuitamente — Comece com WP-Firewall Basic

Se você deseja um ponto de partida simples e eficaz para proteger o WordPress enquanto valida e corrige componentes upstream, considere nosso plano Básico (Gratuito). Ele oferece proteções essenciais que reduzem a exposição a ameaças de aplicativos da web enquanto você implementa as mitig ações direcionadas acima.

O que obtém com o plano Básico (Gratuito):

• Firewall gerenciado protegendo superfícies de ataque comuns
• WAF para bloquear padrões comuns de injeção e XSS
• Scanner de malware para detectar cargas úteis suspeitas injetadas
• Largura de banda ilimitada e varredura contínua
• Cobertura de mitigação para os 10 principais riscos da OWASP

Inscreva-se e ative o plano gratuito para adicionar uma camada de proteção enquanto você aplica o patch Nuxt/Nitro e as etapas de endurecimento: https://my.wp-firewall.com/buy/wp-firewall-free-plan/

---

Exemplo: Como responderíamos na camada WAF (manual operacional)

1. Triagem:
   • Identifique se o site usa versões vulneráveis do Nitro.
   • Se sim, ative imediatamente o conjunto de regras WAF que visa padrões de XSS de caminho de ilha.
2. Aplique regras de patch virtual:
   • Marque temporariamente /__nuxt_island as respostas como não cacheáveis para caches compartilhados via a borda.
   • Adicione regras de entrada para bloquear solicitações contendo tokens de script.
3. Alerta:
   • Notifique os proprietários e desenvolvedores do site para atualizar para 4.4.6+.
   • Agende uma janela de implantação para atualizar a dependência e reconstruir os contêineres.
4. Verificação:
   • Após implantar a atualização + regras WAF, execute a suíte de testes automatizados e simulações de sondas XSS em staging.
   • Após passar nos testes, remova regras WAF excessivamente restritivas que podem bloquear tráfego válido e confie na correção upstream.
5. Pós-morte:
   • Revise por que a chave de cache ou os cabeçalhos Vary foram mal configurados.
   • Melhore os controles de implantação para garantir que as atualizações de dependência sejam aplicadas mais rapidamente.

---

Perguntas frequentes (curtas)

Q: Meu site é WordPress clássico sem front-end Node — estou afetado?
A: Se não houver componentes Nuxt/Nitro em sua pilha, sua exposição direta é mínima. Mas verifique as ferramentas de desenvolvedor, serviços de visualização ou CDNs usados pelo seu site para uso do Nitro.

Q: Atualizei para 4.4.6, mas ainda vejo scripts suspeitos em páginas em cache — e agora?
A: Limpe os caches em todos os níveis (borda, CDN, proxy reverso). A atualização pode não remover automaticamente ativos envenenados em cache anteriormente.

Q: A Política de Segurança de Conteúdo pode mitigar isso completamente?
A: CSP reduz o impacto de scripts injetados, mas não resolve a contaminação de cache. Use CSP + controle de cache + correção para mitigação completa.

Q: Quão urgente é essa atualização?
A: É importante: a exploração tem baixa severidade no CVSS, mas pode ser usada para ataques de contaminação de cache escaláveis que afetam muitos usuários. Priorize a correção se você executar Nuxt/Nitro em qualquer parte da sua cadeia de entrega.

---

Recomendações finais — lista de verificação priorizada

1. Inventário: Procure por uso de Nitro/Nuxt em todo o seu site, CI e provedor de hospedagem.
2. Correção: Atualize @nuxt/nitro-server para 4.4.6+ em todos os lugares onde aparecer.
3. Proteja: Aplique regras de WAF e defina cabeçalhos Cache-Control/Vary para evitar o uso de cache compartilhado para fragmentos dinâmicos.
4. Limpeza: Limpe caches em CDN e camadas de borda.
5. Reforce: Implemente/fortaleça CSP, sane conteúdo renderizado pelo servidor e garanta que as chaves de cache variem em cabeçalhos sensíveis ao usuário.
6. Automatize: Adicione varreduras SCA de rotina e atualizações automáticas de dependências ao seu pipeline.

---

Se você gostaria de um manual de operações adaptado à sua arquitetura de hospedagem WordPress (clássica vs. sem cabeça vs. híbrida), nossa equipe de segurança pode mapear os passos para sua pilha e fornecer trechos recomendados de regras de WAF e scripts de teste que você pode executar em staging antes do lançamento em produção.