PHP 漏洞是指 PHP 運行環境、應用程式碼、第三方套件或伺服器設定中的弱點，可能導致網站面臨未經授權的存取、資料竊取或服務中斷。常見的例子包括 SQL 注入、跨網站指令碼、不安全的檔案上傳和存取控制缺陷。
區分漏洞類型很重要，因為修復方式不同。運行環境的安全缺陷需要修補後的 PHP 版本。授權錯誤則需要程式碼或政策變更。更新 PHP 是必要的，但它不會自動修復使用 PHP 開發的網站中的所有弱點。
對於加密貨幣服務而言，風險可能涉及提款控制、API 憑證以及向錢包使用者顯示的交易細節。網站本身被入侵並不意味著比特幣的共識規則或區塊鏈的密碼學已被破解。
從受支援、已修補的軟體開始
安全更新，2026 年 10 月 22 日：PHP 於 10 月 21 日的安全公告，識別出兩個嚴重的遠端程式碼執行漏洞，CVE-2026-109618 和 CVE-2026-109619。已修補的支援分支版本為 PHP 8.5.12、8.4.27、8.3.36 和 8.2.35。PHP 團隊敦促使用者更新；臨時緩解措施不能完全取代修補。請查閱官方安全公告和您的主機提供商的指南。
使用適用的已修補版本或更新的穩定版本。發行版供應商可能會向後移植安全修補程式，因此請驗證套件的公告狀態，而非僅憑版本號判斷。確認正在運作的運行環境（不僅是命令列 PHP）已更新，並且相關工作程序已重新啟動。
同時也要維持升級計畫。PHP 8.2 的上游安全支援將於 2026 年 12 月 31 日結束；獲得此特定修補程式並不代表其正常支援生命週期會延長。
SQL 注入：將資料與查詢結構分離
當不受信任的輸入成為資料庫命令的一部分時，就會發生 SQL 注入。主要修復方法是透過預備語句綁定資料值，而不是將使用者輸入串接到 SQL 字串中。PHP 的PDO 文件解釋了這種分離。
例如，私有文章查詢可以綁定已驗證的文章 ID 和已驗證使用者的伺服器端身份：
$stmt = $pdo->prepare(
'SELECT id, title FROM articles
WHERE id = :id AND owner_id = :owner'
);
$stmt->execute([
'id' => $articleId,
'owner' => $authenticatedUserId,
]);佔位符保護的是資料值，而不是任意的表格名稱、欄位名稱或排序方向。將這些選擇對應到固定的、允許的值。同時也要限制資料庫權限：應用程式通常不需要能夠管理整個資料庫的帳戶。
跨網站指令碼：根據輸出內容進行編碼
跨網站指令碼（XSS）發生在不受信任的內容被解釋為可執行的瀏覽器內容時。當頁面不正確地渲染註解、個人資料欄位或匯入的文件時，它們可能變得危險。
使用框架的自動跳脫功能，並將不受信任的資料保留在可執行內容之外。對於放置在普通 HTML 標籤之間的純文字，PHP 的 htmlspecialchars() 配合明確的 UTF-8 處理是一個適當的工具。它並非 JavaScript、CSS 或 URL 的通用解決方案。
如果使用者需要提交豐富的 HTML，請使用維護良好、基於允許清單的 HTML 清理器，而不是將整個輸入視為受信任的。內容安全策略（Content Security Policy）增加了另一層保護；它不能取代對內容的正確處理。這些區別在OWASP 的 XSS 防範指南中有詳細說明。
上傳與檔案處理：控制伺服器接受的內容
上傳功能不應讓使用者決定伺服器上出現哪個可執行檔案。僅允許產品所需的檔案類型，檢查內容而非信任瀏覽器宣告的 MIME 類型，設定大小限制並生成伺服器端檔案名。
將不受信任的上傳檔案儲存在 Web 根目錄之外或獨立儲存空間，並進行受控檢索。確保伺服器配置無法執行上傳的內容。身份驗證、授權以及適當的惡意軟體或內容檢查可提供額外的安全保障。OWASP 的檔案上傳指南建議結合使用這些控制措施。
對檔案路徑和匯入也應採取同樣的紀律。將使用者看到的檔案 ID 對應到核准的伺服器端檔案，而不是將原始請求值傳遞給檔案包含函數。避免將不受信任的輸入餵給 shell 命令、 或 PHP 物件反序列化。更安全的 API 和經過驗證的資料格式可以減少這些危險操作的需求。
身份驗證、會話和 CSRF 需要獨立的控制
身份驗證確立使用者是誰；授權決定該使用者可以做什麼。一個可運作的登入頁面並不代表帳戶記錄、下載或管理操作受到保護。請在伺服器上檢查每個敏感操作和物件的權限。
使用標準的密碼處理函數，如 password_hash() 和 password_verify()，使用 MFA 保護特權帳戶，並限制惡意登入嘗試。對於會話，強制使用 HTTPS，配置適當的 Secure、HttpOnly 和 SameSite Cookie 屬性，在身份驗證或權限變更後更新會話識別碼，並在登出時使會話失效。遵循OWASP 的會話管理指南，而不是自行設計自訂的會話方案。
需要 Cookie 身份驗證且會改變狀態的請求也需要 CSRF 保護。優先使用框架維護的實作，包括適用的伺服器端令牌驗證。SameSite Cookie 是有用的縱深防禦措施，但不應假設它們能保護所有部署或請求流程。請勿使用 GET 請求執行敏感的狀態變更。
設定和依賴項是應用程式的一部分
一個寫得很好的控制器仍然可能存在於不安全的部署中。將憑證、私鑰、設定機密和備份放在公共目錄之外。在生產環境中禁用詳細的錯誤顯示，同時保留可存取的日誌，以便在不收集不必要機密的情況下調查失敗。
檢查完整的依賴項清單：PHP 運行環境、擴充功能、框架、CMS、外掛程式和 Composer 套件。Composer 的 audit 命令可以識別依賴項中已報告的安全問題，但它無法保證自訂應用程式邏輯是安全的。
針對應用程式測試更新，並從經過審查的依賴項版本中可重現地部署。移除未使用的組件，而不是讓它們無限期暴露。限制檔案系統權限，使應用程式進程無法重寫伺服器上的所有內容，並將開發工具與生產環境分開。
PHP 漏洞如何影響加密貨幣網站
加密貨幣網站的應用程式層可以獨立於其連接的區塊鏈進行攻擊。以下是架構風險場景，而非針對任何特定交易所或錢包的發現。
| 加密貨幣風險 | 可能發生的問題 | 實際控制措施 |
|---|---|---|
| 託管帳戶或提款濫用 | 被劫持的會話或薄弱的伺服器端授權 | 對敏感操作進行重新驗證，並將批准綁定到確切的收款人與金額。 |
| 存款地址或簽署欺騙 | 修改的網頁內容或誤導性的交易描述 | 在受信任的錢包介面或可讀的硬體錢包顯示中，驗證網路、收款人、資產和金額。 |
| API 憑證暴露 | 透過程式碼、日誌或公開檔案洩漏的機密資訊 | 將金鑰保留在伺服器端，將權限範圍縮小，在不必要時省略提款權限，並輪換已暴露的憑證。 |
保護私鑰並不自動保護使用它的決策。Trezor 的清晰簽署指南解釋了為何被入侵的前端可能會錯誤描述交易。請勿批准您無法有意義驗證的請求，或將助記詞輸入聲稱需要安全更新的網站。
套用相關的修補程式或程式碼變更，然後測試安全控制措施和正常的使用者行為。包含負面測試：使用者不應僅透過更改識別碼就能存取他人的記錄。僅對您擁有或明確授權評估的系統執行安全測試。
如果懷疑遭到入侵，修補只是復原的一部分。遏制事件，保存有用證據，調查持久性與暴露的憑證，並從已驗證的乾淨狀態還原。防火牆規則或乾淨的掃描結果並不能證明攻擊者的存取已被移除。
常見問題
PHP 本身不安全嗎？
不是。風險取決於運行環境版本、應用程式設計、依賴項和部署方式。PHP 應用程式仍然需要例行的安全維護。
升級 PHP 會修復 SQL 注入和 XSS 嗎？
不一定。運行環境更新修復運行環境漏洞；不安全的查詢建構和輸出處理通常需要應用程式變更。
HTTPS 能防止 PHP 漏洞嗎？
不能。HTTPS 保護傳輸中的資料。它無法修正權限錯誤、不安全的上傳或有漏洞的伺服器端程式碼。
Web 應用程式防火牆可以取代修補嗎？
不能。它可以減少某些暴露，但無法可靠地修復底層軟體缺陷或應用程式邏輯。
結論
PHP 漏洞沒有單一的通用修復方法。修補運行環境和依賴項，將資料庫值與 SQL 分離，安全地處理瀏覽器輸出，限制上傳並強制執行伺服器端存取控制。
對於加密貨幣應用程式，還要保護提款授權、API 憑證和錢包端的交易細節。將每個弱點與正確的控制措施匹配，並在部署後驗證該控制措施。更新、安全編碼和營運監控是相輔相成的；沒有任何一項可以取代其他。
