PHP 四個版本同日推出安全更新：用 pg_select() 的網站有 SQL 注入風險，bccomp() 還可能寫壞記憶體

一句話看懂：PHP 在 7 月 30 日同時推出 8.2.33、8.3.33、8.4.24、8.5.9 四個安全更新，修掉兩個官方標為 High 的漏洞，其中一個讓連 PostgreSQL 的程式可能被 SQL 注入。

先用白話講：SQL 注入是什麼？

想像你在櫃台填表單，櫃台人員會把你寫的名字原封不動貼到一張「查詢單」上，交給後面的檔案室去找資料。如果你的名字欄寫的不是名字，而是「叫檔案室把所有人的資料都拿出來」，櫃台又沒有檢查就照貼，檔案室就會照做。

這就是 SQL 注入：網站把使用者輸入的文字，直接當成資料庫指令的一部分。防止它的方法，是在貼上之前先把危險的符號「轉義」，讓它只當成普通文字。

這次的問題，就是 PHP 自己的轉義做得不夠完整。

發生什麼事

PHP 在 7 月 30 日同時釋出 8.2.33、8.3.33、8.4.24、8.5.9 四個版本，官方說明都是安全更新。更新紀錄裡有 4 項有 CVE 編號的修正，其中兩個被官方標為 High：

另外兩項也一併修了：Phar 遇到遞迴符號連結會當機（CVE-2026-7260），以及升級內建的 libgd（CVE-2026-9672）。

第一個漏洞到底怎麼回事？

根據 GitHub 上的官方公告，這四個函式會先用 PostgreSQL 的轉義函式處理使用者資料，再包進 E'...' 這種「跳脫字串」的格式。

問題是：PostgreSQL 從 9.1 版起預設開啟 standard_conforming_strings，在這個預設下，轉義函式不會處理反斜線 \，卻把單引號變成兩個。結果攻擊者可以用一個反斜線，把其中一個單引號「吃掉」，另一個單引號就變成字串的結尾，後面的內容會被當成資料庫指令。

也就是說，用預設設定的 PostgreSQL、又在這四個函式裡塞使用者輸入的網站，就在這個漏洞的範圍內。修法是改成把參數包進「不處理跳脫」的一般字串常數。

第二個漏洞

bccomp() 是比較兩個大數字的函式。官方說明，當呼叫者指定了精度（scale），把數字截短、又去掉結尾的零時，程式只縮小了配置的空間，卻拿原本的長度去複製，造成寫到緩衝區之外。這個漏洞只在 PHP 8.4 與 8.5。

給開發者的技術細節

先確認版本與有沒有用到相關函式：

php -v
grep -rnE "pg_(insert|update|select|delete)\(" ./src

• 升級目標：8.2.33、8.3.33、8.4.24、8.5.9，也就是同一個系列的最新修補版
• 用主機商或作業系統套件的人，要確認套件有沒有已經回補修正；版本號沒變不代表沒修
• 用 Docker 的人，要重新建立映像檔，只升級本機開發環境沒有用
• 這四個函式本來就是「圖方便」的封裝；長期做法是改用 PDO 或 pg_query_params() 這類參數化查詢

我的看法

PHP 現在的新專案比以前少，但接案時一定會碰到維護舊網站的需求：WordPress、舊的客製後台，常常 PHP 版本很久沒動。這類網站的問題通常不是漏洞多難，而是「沒人記得它跑在哪台主機上」。

這次的實用做法很簡單：先 php -v 看版本，再 grep 有沒有用到這四個函式。沒用到，就在下次維護時一併升級；用到，就盡快升級並在這週內處理。

另外要提醒，公告列出的受影響與修補範圍只有 8.2 到 8.5。如果你的網站還跑在更舊的版本，這次官方公告裡沒有為它列出修補版本，更需要把升級排進計畫。

名詞小辭典

• SQL 注入（SQL Injection）：把惡意內容塞進輸入欄位，讓資料庫把它當指令執行的攻擊方式。
• 轉義（Escape）：把輸入裡有特殊意義的符號，改成普通文字的處理方式。
• 越界寫入（Out-of-bounds write）：程式把資料寫到配置好的記憶體範圍之外，可能造成當機，甚至被利用來執行惡意程式。
• CVE：全球通用的資安漏洞編號，方便各方用同一個名字討論同一個漏洞。

資料來源

• PHP.net：PHP 8.5.9 等版本釋出公告（2026-07-30）
• PHP ChangeLog：Version 8.5.9
• GitHub 安全公告：GHSA-7qpv-r5mr-78m4（CVE-2026-17543）
• GitHub 安全公告：GHSA-x692-q9x7-8c3f（CVE-2026-17544）