Cloudflare WAF 攔截 WordPress 兩個高風險核心漏洞，涵蓋 SQL 注入與未授權 RCE
Cloudflare Blog · 2026-07-17
Cloudflare 於 2026 年 7 月 17 日發布公告，說明其 WAF（Web Application Firewall）已針對 WordPress 核心兩個高風險漏洞部署防護規則。這兩個漏洞並非出自第三方外掛，而是存在於 WordPress 核心的 REST API 功能中，影響範圍涵蓋大量以預設設定運作的網站。Cloudflare 表示相關規則已在漏洞細節公開前於受管防火牆規則集中生效，讓客戶在原廠修補程式尚未全面部署前先取得緩解。
漏洞機制
第一個漏洞編號為 CVE-2026-60137，屬於 SQL 注入（SQL Injection），嚴重程度為 High。攻擊者可透過刻意構造的輸入，改變 WordPress 後端執行的資料庫查詢邏輯，進而讀取或竄改不應存取的資料。由於漏洞點位於 REST API 的查詢處理路徑，一般不需要複雜的前置條件即可觸發。第二個漏洞編號為 CVE-2026-63030，是未經驗證即可觸發的遠端程式碼執行（RCE），嚴重程度列為 Critical。Cloudflare 指出，攻擊者不需要登入帳號，就能透過 REST API 的 batch 端點執行任意程式碼，這代表任何對外開放 REST API 的 WordPress 站台都可能在完全沒有帳號權限的情況下被入侵。
受影響版本
SQL 注入漏洞 CVE-2026-60137 影響 WordPress 6.8 及之後的版本；RCE 漏洞 CVE-2026-63030 影響 6.9 及之後的版本。由於兩者都是核心層級的問題，凡是未套用修補程式的近期主線版本都在受影響範圍內，而非侷限於特定外掛或佈景主題組合。官方已釋出的修補版本為 6.8.6、6.9.5、7.0.2 與 7.1 Beta 2，尚未升級到上述版本的站台都應視為暴露在風險之中。
修補與緩解
Cloudflare 在 WAF 中新增兩條規則因應：SQL 注入規則名為「WordPress - SQL Injection」，代管規則 ID 為 1c060d3a371549219ee290d7ed933fcc，Free 方案對應 ID 為 db003b39b7774859a8d588ce33697a1a；RCE 規則名為「WordPress - Remote Code Execution」，代管規則 ID 為 7dfb2bd4708d4b88b9911dc0550664b6，Free 方案對應 ID 為 ebd3f2df15c74ddcbf6220c9b5ec246a。兩條規則的動作皆設為 Block，且會在請求路徑上的兩個不同檢查點分別偵測攻擊特徵，形成縱深防禦。
Cloudflare 強調 WAF 規則屬於暫時性緩解措施，網站管理者仍須儘快將 WordPress 升級到對應的修補版本，才能從根本上消除這兩個漏洞。對於暫時無法立即升級、或使用客製化外掛與整合而擔心升級相容性的站台,WAF 規則可作為升級前的過渡防護。
原始來源：Cloudflare Blog
GitHub Copilot 新增 C++ 迭代建置分析功能，鎖定「小改動、頻繁重建」的真實開發情境
Microsoft C++ devblog · 2026-07-17
微軟於 2026 年 7 月 17 日發布文章，介紹整合進 GitHub Copilot 的 C++ 建置效能新功能，鎖定 Visual Studio 上的迭代建置（iterative build）情境。這項功能已在 Visual Studio 2026 版本 18.6.1 Stable 與 18.7 Insiders 中提供，開發者只需在 Copilot Chat 中輸入「make my build faster」即可觸發分析流程。
原本的問題
微軟指出，C++ 開發者長期反映建置速度是最大痛點之一，但過去建置效能的量測與優化多半只看「乾淨全量建置」（clean build）的耗時。問題在於乾淨建置的量測方式並不能反映真實開發流程——工程師日常工作多半是修改單一或少數幾個檔案後立即重建，而非每次都從零開始編譯整個專案。這導致部分號稱能加速建置的變更，在乾淨建置測試中看似變慢，但實際上反而能讓迭代重建更快，反之亦然。過去缺乏工具能同時衡量兩種情境下的影響,使得優化建置設定時容易做出錯誤判斷。
採用的方法
新的迭代建置工具（Iterative Build Tool）被整合進 GitHub Copilot 的建置效能功能中，運作方式是由 Copilot 代理自動擷取建置追蹤（build trace）資料，分析後提出具體的優化建議。其關鍵設計是在提出建議前，會同時針對乾淨建置與迭代建置兩種情境進行測試，確保優化方向不會顧此失彼。整個流程以互動方式呈現在 Visual Studio 介面中，開發者只需要打一句自然語言指令,後續的追蹤擷取、分析與變更套用前的核可,都由 Copilot 引導完成,形成一套五步驟的核可流程。
實際效果
微軟在文章中並未公布具體的建置時間縮短百分比或量化基準數字,而是著重說明這項功能「能夠衡量」迭代建置與乾淨建置各自受到的影響,而非單純追求乾淨建置數字好看。這代表微軟希望開發者依照自己的實際工作模式來評估優化效果,而不是套用單一的通用基準。文章內容以 Visual Studio 圖形介面的操作截圖為主,未提供對應的程式碼片段或命令列範例,顯示這項功能目前定位為 IDE 內建的互動工具,而非可獨立於 Visual Studio 之外呼叫的命令列元件。
微軟推 Dev Proxy 攔截測試法，讓 AI Agent Skill 評估不再打到正式環境 API
Microsoft devblog · 2026-07-17
微軟於 2026 年 7 月 17 日發布文章，說明如何使用 Dev Proxy 工具測試會呼叫外部 API 的 AI agent skill，避免評估過程中產生真實 API 呼叫。文章以一個串接產品目錄 API 的 skill 為範例，並展示如何分別替 GitHub Copilot CLI、Claude Code CLI 與 Codex CLI 建立對應的 skill 定義與測試環境。
原本的問題
微軟指出,評估會呼叫真實 API 的 agent skill 存在三個具體困難。第一,單次完整評估可能累積多達 750 次以上的 API 呼叫,成本迅速堆疊;第二,若 skill 內含 PATCH、DELETE 等寫入操作,直接對正式環境資料執行會造成資料汙染,難以復原;第三,若資料來源被其他系統同時修改,評估結果會出現不可重現的非決定性(non-deterministic)差異。這三個因素疊加的結果,是多數團隊乾脆略過嚴謹的評估流程,直接把未經測試的 skill 上線。
採用的方法
微軟提出的解法是 Dev Proxy——一個輕量級的 HTTP 攔截工具,透過 JSON 設定檔在本地端模擬 API 行為,不需要另外架設專用的 mock server。設定檔內容包含目標 API 的 base URL、作為種子資料的 JSON 檔案,以及支援 GET、PATCH、DELETE 等動作並可用 JSONPath 篩選查詢條件的 action 定義。範例設定如下：
{
"baseUrl": "https://api.contoso.com/products",
"dataFile": "products-data.json",
"actions": [
{ "action": "getAll" },
{ "action": "getOne", "url": "/{product-id}" }
]
}這種攔截機制的關鍵優勢是 skill 本身呼叫的 API 網址完全不需要更動,Dev Proxy 在網路層攔截請求並回傳模擬資料,對 skill 程式碼而言與呼叫真實 API 沒有差異。每次測試執行時,種子資料都能重置回初始狀態,確保多次評估之間互不干擾,也徹底排除了對正式環境資料造成任何影響的可能性。
實際效果
文章提供了一套完整的範例實作,以產品目錄 API 為場景,分別為 GitHub Copilot CLI、Claude Code CLI 與 Codex CLI 三種 agent 執行環境撰寫對應的 skill 定義。這代表 Dev Proxy 的攔截設定並非綁定單一 agent 框架,而是可以套用在不同廠商的 CLI agent 工具鏈上,只要 skill 是透過標準 HTTP 呼叫外部 API,就能用同一份 JSON 設定檔案進行模擬。文章未提供具體的評估耗時或成本節省百分比,重點放在示範這套攔截測試方法的可重複性與可移植性。
原始來源：Microsoft devblog