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 並運行您的包管理器）。.
   • 更新鎖定文件（16. yarn.lock, 17. pnpm-lock.yaml, 18. ）已提交並在 CI 中強制執行。）並提交它們。.
2. 對於容器化構建：
   • 更新包和鎖定文件後，重建映像並重新部署。.
   • 避免依賴隱式最新版本 — 使用固定版本並經常重建映像。.
3. 對於您無法控制的邊緣或預覽服務：
   • 聯繫您的提供商或服務擁有者，請求確認修補。.
   • 請他們更新到 4.4.6+ 並在修補後使緩存失效。.

如果您無法立即更新，請應用以下緩解措施。.

立即可以應用的緩解措施（即使在修補之前）

您可以快速實施的實際措施以減少暴露：

1. 禁用島嶼端點的共享緩存
   • 確保來自 __nuxt_island 的響應被標記為不可被共享緩存緩存：
     • 設定 Cache-Control: 私有, 不緩存, 不儲存, 必須重新驗證 （根據您的環境選擇適當的指令）。.
     • 添加 Vary 標頭以包含 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. Inventory your stack
   • 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 (16. yarn.lock, 17. pnpm-lock.yaml, 18. ）已提交並在 CI 中強制執行。) 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, 14. 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 快取控制 和 Vary 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.