應用程式安全性是 Progress® Kemp® LoadMaster® 解決方案的核心。在 Application Delivery Controller (ADC) 時代，負載平衡器不應只是扮演「單純反向代理」的角色：它也應該強化其前端應用程式的安全性。

Progress® Kemp® LoadMaster® 負載平衡器內建來自 OWASP、功能完整且符合業界標準的 Web Application Firewall (WAF)。（歡迎觀看我們全新的 WAF 短篇影片系列，快速了解相關基礎。）

LoadMaster WAF 提供卓越的彈性，這與多數雲端 WAF 平台及「WAF as a service」解決方案形成強烈對比。這些解決方案通常會提供精簡版的 WAF 功能，並為了追求「簡單」與「易用」而移除大部分的設定選項。

這是一種有缺陷的方法。

將安全性功能簡化，並不是讓安全性更容易使用的正確方式。當 WAF 被簡化成一或兩個滑桿時，其實質內容也隨之消失。WAF 的實用性降低、防護效果減弱，彈性也不復存在。

部分供應商確實提供「進階」WAF 層級，使用者必須支付更高費用，才能使用實用的 WAF 選項，並進行部分自訂 WAF 規則處理。LoadMaster 解決方案支援完全自訂的 WAF 邏輯，不限制規則數量或複雜程度。這使您能夠透過 LoadMaster WAF 實作虛擬修補，防禦已知存在漏洞的應用程式，包括舊版應用程式。多數雲端平台 WAF 並不具備這種程度的彈性。

什麼是虛擬修補？

虛擬修補是一種降低 Web 應用程式已知漏洞風險的方法，無需直接修補存在漏洞的應用程式本身。幾乎在所有情況下，直接修補實際漏洞都是最佳且正確的做法；然而，這並不總是可行（後文將進一步說明）。

讓已知存在漏洞的應用程式暴露於攻擊者面前，是十分不負責任的做法。與其等待修補程式發布（有些情況下甚至可能永遠不會發布），不如在存在漏洞的應用程式前方部署 WAF，例如 LoadMaster WAF，並套用虛擬修補。

虛擬修補是透過 WAF 安全性規則來實作，這些規則旨在協助封鎖已知的攻擊模式。例如，如果攻擊者可透過向 /foo/bar 傳送 PUT 要求來利用應用程式漏洞，則可強制套用 WAF 安全性規則，專門封鎖所有傳送至 /foo/bar 的 PUT 要求（或封鎖所有 PUT 要求，或封鎖所有傳送至 /foo/bar 的要求：可根據實際需求彈性設定）。

如此一來，就能在完全不修改應用程式的情況下，對漏洞進行「虛擬修補」。

何時（以及為什麼）應使用虛擬修補？

再次強調，最佳解決方案幾乎總是完整且正確地修補受影響的應用程式，以徹底修復漏洞。然而，在許多情況下，這可能暫時或永久無法實現。此時就需要採取其他解決方案（例如虛擬修補）。

• 存在漏洞的應用程式為專有軟體
  若無法存取原始碼來進行修正，修補時程將完全取決於軟體供應商，而供應商對緊急程度的看法可能與客戶截然不同。如果需要立即修正漏洞，虛擬修補可能是唯一可行的（權宜）解決方案。
• 應用程式為舊版／已達支援終止（End of Life）的軟體
  已達 End of Life (EoL) 的軟體很可能永遠不會收到修補程式。對專有的 EoL 應用程式而言，情況更是如此。
• 缺乏修正應用程式所需的技能
  軟體十分複雜。即使從技術上來說確實可以撰寫並套用修正程式，修正問題所需的技能（同時確保安全性，不留下任何漏洞，也不破壞既有功能）可能無法取得，或取得成本不具經濟效益。
• 無法套用修補程式（至少無法立即套用）
  即使已有官方且經驗證的修補程式，也可能無法套用。由於企業政策、維護時段要求，或必須安排人員駕車、搭機或運送設備前往伺服器所在地，並耗費相應時間，因此修改正式環境伺服器可能完全遭到禁止，或實務上根本不可行。

基於這些原因以及其他許多因素，套用虛擬修補往往是處理安全性漏洞的最佳（或唯一）方式。

WordPress CVE-2026-63030

研究人員於 2026 年 7 月發布了兩個相關的 WordPress 漏洞，分別為 CVE-2026-63030 與 CVE-2026-60137，其中一個漏洞被評為重大。這兩個漏洞搭配使用時，攻擊者便能利用 WordPress REST API 批次處理機制中的缺陷，進而可能執行遠端程式碼 (RCE)。

WordPress 管理員應已完成更新，以修補這些問題；完整且正確地執行更新是正確的處理方式。然而，這個情況也充分說明了虛擬修補的用途：在問題公開後，到所有伺服器完成修補前的這段期間，虛擬修補可以協助防禦攻擊。

目前已知的攻擊形式，是向特定 API 端點 /wp-json/batch/v1 傳送 POST 要求。此外，也已知攻擊會使用參數「rest_route」，其值為 /batch/v1。利用這兩項資訊，可以立即撰寫並套用 WAF 安全性規則，封鎖這類要求，在攻擊與探測行為抵達後端 WordPress 伺服器之前，就先予以阻擋。

請務必注意，受影響的 API 端點 /wp-json/batch/v1 具有合法用途，封鎖對其存取可能會導致部分使用者的功能無法運作。套用虛擬修補時，您可以視需求進行細部調整，例如允許特定受信任的 IP 位址或使用者略過虛擬修補中的特定部分。

您可以利用上述資訊，撰寫以下兩項自訂 WAF 安全性規則：

# Virtual patch to defend against known attacks against
# WordPress CVE-2026-63030/CVE-2026-60137
SecRule REQUEST_URI "@beginsWith /wp-json/batch/v1" \
    "id:1000,\
    phase:1,\
    deny,\
    t:none,t:lowercase,\
    log,\
    msg:'Detected possible WordPress attack to exploit CVE-2026-63030/60137'"

SecRule ARGS:rest_route "@streq /batch/v1" \
    "id:1010,\
    phase:2,\
    deny,\
    t:none,t:lowercase,\
    log,\
    msg:'Detected possible WordPress attack to exploit CVE-2026-63030/60137'"

將這些自訂規則儲存至檔案，然後上傳至 LoadMaster 的操作如下：

接著，您可以立即將這些自訂規則新增至虛擬服務上的 WAF 並套用，如下所示：

若要測試虛擬修補中的兩項規則是否如預期運作，可以傳送測試要求，確認這些要求是否會在 LoadMaster WAF 被拒絕：

$ curl 192.168.2.150/wp-json/batch/v1
<html><head><title>403 Forbidden</title></head><body>Access denied</body>
$ curl 192.168.2.150/?rest_route=/batch/v1
<html><head><title>403 Forbidden</title></head><body>Access denied</body>

為什麼具備彈性的 WAF 功能對虛擬修補至關重要

雖然針對存在漏洞的軟體進行完整且正確的修正，幾乎總是最佳解決方案，但如上文所述，許多情況下並不可行。在這種情況下，部署虛擬修補可以提供有效的暫時性緩解策略。.

具備彈性的 WAF 是關鍵， 因為它能讓您視需求使用自訂 WAF 邏輯及任意數量的自訂安全性規則。相較之下，雲端 WAF 往往會將自訂規則等實用的 WAF 功能隱藏在更高價的服務層級後方；有些甚至完全不提供自訂 WAF 規則。

想使用 LoadMaster WAF 功能，但沒有 Enterprise Plus 授權層級？請聯絡您的業務代表，他們很樂意為您說明。

您是否有其他軟體想套用虛擬修補？是否擁有已達支援終止、永遠無法取得官方修補程式的舊版軟體？或者需要在下次維護時段前，先為漏洞套用暫時性的虛擬修補？LoadMaster WAF 是具備高度彈性的平臺，十分適合支援上述需求，無論部署於硬體、虛擬環境或雲端。

 立即聯絡經驗豐富的 LoadMaster 代表 ，瞭解您的 WAF 與安全性需求。