Nuxt Nitro ‘__nuxt_island’ Shared-Cache Poisoning (CVE-2026-46342) — What WordPress Site Owners Need to Know

摘要： A recently disclosed vulnerability in the Nuxt Nitro server impacts versions ≥ 4.2.0 and ≤ 4.4.5. It can lead to shared-cache poisoning and Cross-Site Scripting (XSS) via the __nuxt_island 端点。该问题在 4.4.6 中已修复。如果您的 WordPress 网站与 JavaScript 前端、无头架构、CDN 边缘渲染集成，或在工具链中使用 Nuxt/Nitro 组件，本通知解释了风险、检测方法、缓解措施（包括紧急防火墙/边缘规则）和长期供应链加固策略。.

这对 WordPress 网站所有者的重要性

大多数 WordPress 部署仍然基于 PHP，使用 WordPress 堆栈进行服务器端渲染。然而，香港及该地区的运营商越来越多地使用现代 JavaScript 前端（Nuxt、Next、Remix）以提高性能和改善开发者工作流程——一种无头或解耦架构。这些前端通常依赖于基于 Node 的服务器、Nitro 中间件和边缘缓存/CDN。.

报告的问题 (CVE-2026-46342) 影响 Nuxt 前端使用的 Nitro 服务器端点： __nuxt_island. 当响应未与原始请求属性紧密绑定时，共享缓存可能会将为一个用户创建的响应提供给另一个用户。如果该响应包含攻击者控制的内容（例如，未清理的 HTML 或脚本片段），攻击者可以中毒缓存并对许多网站访问者触发跨站脚本攻击。.

即使您的 WordPress 后端没有直接运行 Node，当以下情况发生时，WordPress 系统也可能受到影响：

• 您的 WordPress 网站使用从 WordPress REST API 或 GraphQL 拉取数据的 Nuxt 或 Nitro 前端。.
• 您的托管环境使用包含基于 Nitro 组件的服务器端渲染或边缘渲染服务。.
• 您的 CI/CD、构建管道或第三方服务使用易受攻击的包生成预览、部署前端或在边缘渲染页面。.

本通知采取务实的立场，语气如同香港安全专家：直接、操作性强，专注于网站所有者和运营者现在必须做的事情。.

Technical overview — what’s broken

• 该 __nuxt_island 端点在 Nuxt 的混合渲染模型中渲染或水合孤立组件（小型交互片段）。.
• 脆弱的行为：来自端点的响应未与请求属性（来源、头部、Cookie、查询参数）充分绑定。如果缓存层在没有适当的 Vary/Cache-Control 头或缓存键的情况下存储该响应，则缓存的响应可能会被提供给在关键请求属性上有所不同的其他请求。.
• 如果攻击者能够构造一个包含攻击者控制内容的请求（例如，通过注入属性或反射数据）并导致该响应被缓存，攻击者可以中毒共享缓存。当其他用户接收到该缓存响应时，任何恶意脚本将在他们的浏览器中执行——导致潜在的广泛影响。.

最终结果：一次成功的利用可以通过一个中毒的缓存孤立片段转变为大规模 XSS。.

WordPress 网站的攻击面

使 WordPress 驱动的网站暴露于此问题的常见集成模式：

• 无头 WordPress + Nuxt 前端：
  • WordPress 通过 REST API / GraphQL 提供内容。.
  • Nuxt 前端使用 Nitro 服务器渲染包含 WP 内容的岛屿。.
  • 前端过程中使用的易受攻击的 Nitro 包可能导致缓存中毒。.
• 边缘渲染 / CDN 预览/OG 图像生成：
  • 一些边缘预览生成器或图像端点包括基于 Nitro 的渲染。.
  • 如果您的托管提供商或 CI 使用 Nitro 组件，这些端点可能会受到影响。.
• 开发者工具：
  • 安装易受攻击依赖项的构建和预览系统（storybook、SSR 预览、静态网站生成器）可能会创建或上传中毒的工件或缓存输出。.
• 第三方集成：
  • 插件供应商、主题构建者或无头服务提供商可能正在运行基于 Nitro 的预览。如果他们使用的是易受攻击的版本，客户的网站可能会受到间接影响。.

If your WordPress site is purely classic (no headless front-end, no Node tooling in deployments), the risk is much lower. But in modern DevOps environments it’s worth checking.

攻击者如何利用它（实际场景）

• 通过缓存岛屿片段的反射 XSS：
  • 攻击者向发送一个精心制作的请求 __nuxt_island 带有攻击者控制的参数。.
  • Nitro 生成一个包含该参数的片段，但没有适当的清理。.
  • CDN 为共享密钥缓存该片段。.
  • 随后的访问者接收到缓存的片段；攻击者的 JavaScript 在他们的浏览器中运行。.
• 通过上游数据的存储型注入：
  • 如果前端从第三方 API 或用户输入（例如评论）渲染数据，攻击者会在上游存储恶意输入。.
  • 服务器渲染包含恶意内容的岛屿；响应被缓存并随后提供给其他人。.
• 大规模滥用： 边缘缓存意味着单个缓存对象可以影响成千上万的访客；缓存中毒路径放大了影响。.

修补和更新——最重要的修复

如果您在堆栈中的任何地方使用 Nuxt/Nitro，请立即更新受影响的包：

• 受影响： @nuxt/nitro-server ≥ 4.2.0 and ≤ 4.4.5
• 已修补于： 4.4.6 — 升级到 4.4.6 或更高版本

操作：

1. 对于使用 npm/yarn/pnpm 的项目：
   • 运行 npm install @nuxt/nitro-server@^4.4.6 （或更新 package.json 并运行您的包管理器）。.
   • 更新锁定文件（package-lock.json, yarn.lock, pnpm-lock.yaml）并提交它们。.
2. 对于容器化构建：
   • 更新包和锁定文件后，重建镜像并重新部署。.
   • 避免依赖隐式最新版本 — 使用固定版本并频繁重建镜像。.
3. 对于您无法控制的边缘或预览服务：
   • 联系您的提供商或服务所有者并请求确认修补。.
   • 请他们更新到 4.4.6+ 并在修补后使缓存失效。.

如果您无法立即更新，请应用以下缓解措施。.

您现在可以立即应用的缓解措施（即使在修补之前）

您可以快速实施的实际措施以减少暴露：

1. 禁用岛屿端点的共享缓存
   • 确保来自 __nuxt_island 的响应被标记为不可被共享缓存缓存：
     • 设置 Cache-Control: 私有, 不缓存, 不存储, 必须重新验证 （为您的环境选择适当的指令）。.
     • 添加 变化 头以包含 cookies/授权/主机，如果响应依赖于它们： Vary: Cookie, 授权, 接受编码, 主机.
   • 如果您控制 CDN 规则，请创建规则以绕过任何匹配的路径的缓存 /__nuxt_island 或类似的。.
2. 使用 WAF / 边缘规则进行虚拟修补
   • 创建防火墙规则以阻止或挑战对的请求 /__nuxt_island 包含可疑有效负载的：
     • 阻止包含的请求 <script, onerror=, onload=, encoded script tokens (%3Cscript), or obvious XSS patterns in query strings.
     • Rate-limit or CAPTCHA-challenge anomalous requests to that path.
   • 示例 ModSecurity 风格规则（概念）：

   SecRule REQUEST_URI "@contains /__nuxt_island" "id:100001,phase:1,log,deny,ctl:forceRequestBodyVariable=On,msg:'Block suspicious island requests'"
   SecRule ARGS|ARGS_NAMES|REQUEST_HEADERS|REQUEST_COOKIES "(?i)(<script|onerror=|onload=|javascript:|%3Cscript)" "id:100002,phase:2,log,deny,msg:'XSS pattern in request args targeting island endpoint'"
   

   Adapt IDs and severity to your environment. Test before production-blocking.

3. Purge caches
   • If poisoning may have occurred (or as precaution), purge caches at all tiers:
     • CDN edge caches
     • Reverse proxy caches (Varnish)
     • Application caches
   • Use cache-busting headers or versioning for island fragments if necessary.
4. Add Content Security Policy (CSP)
   • Implement or tighten CSP for pages that include island fragments:
     • 示例： 内容安全策略: default-src 'self'; script-src 'self' 'nonce-...'; object-src 'none'; base-uri 'self';
   • A strict CSP can limit the impact of XSS even if an attacker injects a script tag.
5. Increase response validation/sanitization
   • On the server side (Nuxt or downstream services), ensure any data bound into responses is properly escaped or sanitized before inclusion in server-rendered HTML.
6. 监控日志和流量
   • Look for sudden increases in requests to __nuxt_island.
   • Inspect for recurring patterns in query strings or POST bodies that include script tokens.
   • Monitor edge cache hit patterns and cache keys.

WAF and edge rule suggestions (concrete)

Below are practical rules and snippets you can adapt. They are intentionally generic and should be tested in staging first.

Nginx snippet to set cache headers for island endpoint:

location ~* /__nuxt_island {
    proxy_pass http://backend;
    proxy_set_header Host $host;
    add_header Cache-Control "private, no-cache, no-store, must-revalidate";
    add_header Vary "Cookie, Authorization, Accept-Encoding, Host";
}

ModSecurity 概念规则：

# Deny requests containing obvious XSS patterns to island endpoint
SecRule REQUEST_URI "@contains /__nuxt_island" "phase:2,chain,id:900100,msg:'Block XSS patterns to island endpoint'"
  SecRule REQUEST_BODY|ARGS|ARGS_NAMES|REQUEST_COOKIES|REQUEST_HEADERS "(?i)(<script|%3Cscript|onerror=|onload=|javascript:)" "t:none,deny,log"

Response-hardening via edge worker (pseudo-code):

• Intercept responses for /__nuxt_island.
• 如果响应包含 <script or suspicious inline JS AND the request lacks expected authentication or headers, drop/challenge response and do not cache.
• Otherwise, ensure response has Cache-Control: private.

Cache key hardening: Ensure cache keys include user-specific properties where content varies (Cookie, Authorization header, Accept-Language, etc.). A misconfigured cache key that ignores cookies is a major root cause of poisoning.

速率限制： Apply rate limits on requests to __nuxt_island, e.g., 5 requests per minute per IP, to reduce poisoning feasibility.

Note: WAF rules are blunt instruments — take incremental steps in staging and monitor for false positives to avoid breaking legitimate traffic.

Detection: how to know if you are affected

1. 清点您的堆栈
   • Search your codebase, CI/CD configurations, and build logs for references to @nuxt/nitro-server, nuxt, nitro, 并且 __nuxt_island.
   • 使用 npm ls @nuxt/nitro-server or equivalent to list installed versions.
   • Check lockfiles (package-lock.json, yarn.lock, pnpm-lock.yaml) to find transient dependencies.
2. Inspect server and CDN logs
   • Look for traffic to paths like /__nuxt_island (or similar island/hydration endpoints).
   • Look for requests with suspicious query strings containing script, onerror, or encoded variants (%3C, <).
3. Review cached responses
   • Fetch cached edge HTML for pages and inspect for injected <script> tags or inline event handlers that you did not author.
   • If your CDN supports cache inspection, verify cached objects for unusual content.
4. 自动扫描
   • Run dependency scanners (npm audit, SCA tools) to locate vulnerable package versions.
   • Use web scanners (XSS detectors) to probe render endpoints safely in staging.

If you think you’ve been hit — immediate incident steps

1. Take the vulnerable endpoint out of public caching
   • Temporarily set Cache-Control: no-store on island endpoints.
   • Purge caches across CDN and proxies.
2. Rebuild & patch
   • 更新 @nuxt/nitro-server to 4.4.6+.
   • Rebuild containers and redeploy.
3. 控制并调查
   • Isolate suspicious servers or processes.
   • Dump logs for the time window of suspected poisoning.
   • Identify and list affected cache keys and purge them.
4. 清理和加固
   • Remove or sanitize any malicious payloads persisted in upstream data sources.
   • Rotate secrets that may have been exposed.
   • Reassess CSP and input sanitization.
5. 沟通
   • If user data was at risk or exploit went public, follow your incident disclosure policy and notify stakeholders.

Long-term supply-chain and deployment hardening for WordPress owners

• Maintain a dependency inventory: Track Node and PHP dependencies used by your site and CI pipeline. Periodically run SCA scans across all packages.
• 固定并锁定依赖项： Use exact version pins in package.json for production-critical packages. Commit lockfiles and run regular rebuilds.
• Automate updates: Use automated tools to propose updates; test and deploy regularly. Consider pipelines that rebuild images and run integration tests when patches are released.
• Limit caching surface: Only enable aggressive shared caching for truly static assets. For dynamic fragments or user-personalized fragments, use Cache-Control: private or bypass caching.
• Harden front-end rendering: Ensure server-rendered fragments escape user data by default. Adopt template engines that auto-escape, or explicitly sanitize dangerous fields.
• Require secure headers: CSP, X-Content-Type-Options, Referrer-Policy, X-Frame-Options, Strict-Transport-Security — enforce these across the site.
• 监控和记录： Aggregated logs for endpoint access and cache behavior help detect anomalies sooner. Monitor WAF/edge events and keep rules under review.

Specific WordPress recommendations (practical checklist)

• If your site is headless:
  • Confirm which front-end versions and packages are used; upgrade Nitro where necessary.
  • Ensure your WordPress REST API responses encode and sanitize HTML fields properly.
  • Ensure preview and CI environments are as secured as production.
• If your site uses a Jamstack or SSR pipeline (Netlify, Vercel, other providers):
  • Contact your provider for confirmation of Nitro package status in their environments.
  • Purge edge caches after updates.
• If your site is classic WordPress but relies on third-party plugins or services that might render at the edge:
  • Check plugin vendors for notifications and updates.
  • Ask hosting or platform teams about Nitro usage in their stack.

Monitoring signals to watch for in the coming weeks

• Increased requests hitting __nuxt_island with payloads that include encoded <script forms.
• Sudden appearance of inline scripts in cached HTML served by your CDN.
• Elevated WAF/edge rule hits tied to island endpoints.
• Reports of popups, redirects, or unexpected JavaScript on pages that were previously static.

If you see these signs, treat them seriously: purge caches, apply virtual patches, and update packages.

常见问题解答（简短）

问： My site is classic WordPress with no Node front-end — am I affected?
答： If no Nuxt/Nitro components are in your stack, direct exposure is minimal. But check developer tools, preview services, or CDNs used by your site for Nitro usage.

问： I updated to 4.4.6 but still see suspicious scripts in cached pages — what next?
答： Purge caches across all tiers (edge, CDN, reverse proxy). An update may not remove previously cached poisoned assets automatically.

问： Can Content Security Policy fully mitigate this?
答： CSP reduces the impact of injected scripts but doesn’t solve cache poisoning. Use CSP + cache-control + patching for full mitigation.

问： How urgent is this update?
答： Prioritise patching if you run Nuxt/Nitro in any part of your delivery chain. The CVE is low-severity by CVSS but enables scalable cache-poisoning attacks that can affect many users.

最终建议 — 优先检查清单

1. Inventory: Search for Nitro/Nuxt usage across your site, CI, and hosting provider.
2. Patch: Update @nuxt/nitro-server to 4.4.6+ everywhere it appears.
3. Protect: Apply WAF rules and set appropriate 缓存控制 和 变化 headers to prevent shared cache usage for dynamic fragments.
4. Purge: Clear caches at CDN and edge layers.
5. Harden: Implement/strengthen CSP, sanitize server-rendered content, and ensure cache keys vary on user-sensitive headers.
6. Automate: Add routine SCA scans and automated dependency updates to your pipeline.

If you would like an operations playbook tailored to your WordPress hosting architecture (classic vs. headless vs. hybrid), I can provide one that maps the steps to your stack and includes WAF rule snippets and testing scripts you can run in staging before production rollout. Reply with details of your architecture and I will prepare a practical playbook.