這篇文章將探討近期兩個截然不同但同樣危險的資安漏洞案例。第一個是針對 WordPress 插件的遠端程式碼執行攻擊，第二個則是利用知名第三方服務作為指令控制伺服器的隱蔽攻擊。對於工程師來說，這兩個案例分別揭示了後端處理輸入值的致命錯誤，以及前端信任機制如何被反向利用。
從 eval 函數看 RCE 漏洞的成因
近期 WordPress 的 Everest Forms Pro 插件被發現存在一個極其嚴重的漏洞（CVE-2026-3300），其 CVSS 評分高達 9.8 分。這個漏洞屬於典型的 RCE，即 Remote Code Execution（遠端程式碼執行）。簡單來說，攻擊者不需要登入網站，就能在伺服器上執行任意的 PHP 程式碼。
漏洞的核心在於該插件的 Calculation Addon（計算擴充功能）中的 process_filter 函數。這個功能允許使用者在表單中進行複雜計算，但開發者在實作時犯了一個低級且致命的錯誤：將使用者提交的表單欄位值直接拼接成一個 PHP 程式碼字串，然後將其傳遞給 eval 函數執行。
eval 是 PHP 中一個極其危險的函數，它會將傳入的字串當作 PHP 程式碼來執行。雖然開發者使用了 sanitize_text_field 函數來清理輸入，但這個函數的主要目的是去除 HTML 標籤，它並沒有對單引號或其他 PHP 語法符號進行轉義。
這導致攻擊者只要在文本、電子郵件或 URL 等字串類型的欄位中輸入精心構造的惡意代碼，就能突破原有的邏輯，強行插入自己的 PHP 指令。一旦成功，攻擊者可以輕而易舉地建立一個名為 diksimarina 的管理員帳號，或者部署 Web Shell（一種允許遠端控制伺服器的後門程式），從而完全掌控整個網站。
這給我們的啟發是：絕對不要將使用者可控的輸入值傳遞給 eval 或類似的執行函數。即便經過了初步的清理，只要邏輯上允許執行動態代碼，漏洞就永遠存在。
利用信任域將 Stripe 轉化為 C2 伺服器
除了後端的 RCE 漏洞，另一個案例則展示了攻擊者如何利用前端的信任機制來規避安全偵測。這是一種 Web Skimmer（網頁側錄器）攻擊，目標是竊取電商網站使用者的信用卡資訊。
通常，為了防止惡意腳本外傳數據，網站會設定 CSP，即 Content Security Policy（內容安全策略）。CSP 就像是一張白名單，告訴瀏覽器只能與哪些信任的域名交換數據。
攻擊者發現，幾乎所有的電商網站都信任 Stripe（全球知名的金流服務商）和 Google Tag Manager (GTM)。於是，他們採取了一套非常巧妙的策略：他們不建立自己的惡意伺服器，而是直接使用 Stripe 的合法帳戶作為 C2，即 Command and Control（指令與控制伺服器）。
具體流程是這樣：攻擊者先透過 GTM 在目標網站載入惡意腳本，然後該腳本會從 Stripe 的客戶元數據（Metadata）欄位中讀取經過混淆的惡意代碼。由於 api.stripe.com 在 CSP 白名單中，瀏覽器完全不會攔截這個請求。
當受害者在結帳頁面輸入信用卡資訊時，腳本會將這些敏感數據暫存在瀏覽器的 localStorage 中，隨後將其發送回攻擊者的 Stripe 帳戶，將每張被盜的信用卡偽裝成一個 Stripe 客戶記錄。
這種攻擊方式極其隱蔽，因為所有流量都發生在受信賴的域名之間，傳統的網路過濾器和安全監控幾乎無法察覺。
工程實務的總結與建議
這兩起事件提醒我們，安全性不能只依賴單一的防線。
在後端開發中，應採取白名單機制來處理輸入，而非試圖透過黑名單或簡單的清理函數來過濾惡意字元。對於需要動態計算的需求，應使用專門的表達式解析庫（Expression Parser），而非直接調用 eval。
在前端安全方面，我們不能盲目信任第三方服務。即便域名在白名單中，如果該服務允許使用者定義內容（如元數據、配置檔），它就可能被用作惡意代碼的載體。對於高風險頁面（如支付頁），應實施更嚴格的 CSP 策略，並對載入的第三方腳本進行完整性校驗（Subresource Integrity, SRI）。
來源：thehackernews.com
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。