2026-08-08 — GitPython 六洞齊發、Apache Fory 三記憶體安全漏洞、CodeIgniter4 Query Builder SQL 注入等協同揭露解析

GitPython 一次補六個洞：設定值名稱藏一個等號就能偽造 core.sshCommand 執行任意指令

GitHub Advisory Database · 2026-08-07

GitPython 專案於 2026-08-07 一次公開六份資安通報，全部影響最新穩定版 GitPython <= 3.1.57，並在同一個版本 3.1.58 中修補。六個編號各自獨立，但攻擊面高度相似：GitPython 把呼叫端傳入的字串（設定值名稱、指令選項、子模組名稱）直接轉發給底層 git 執行檔，卻沒有徹底阻擋能被 git 剖析成「新指令選項」的特殊字元，形成一系列引數注入（argument injection）漏洞。

漏洞機制

最主要的 GHSA-jm78-9fvv-mhgr 出在 _assure_config_name_safe()：這個名稱驗證函式只有在處理 section 標籤時才會啟用完整的括號／引號狀態機檢查，處理 option 標籤時卻只用一個正規表示式擋掉 \r\n\x00，完全放行等號、井字號與空白。問題在於 write_section 會把 option 名稱原封不動寫進設定檔的 "\t%s = %s\n" 樣板，於是攻擊者只要把 option 名稱寫成 sshCommand = touch /tmp/RCE #，就能讓 git 把井字號後面的內容當成註解吃掉，偽造出一行合法的 core.sshCommand 指令。

with repo.config_writer() as cw:
    cw.set_value("core", "sshCommand = touch /tmp/RCE #", "x")
# 寫入設定檔的實際內容：
#   sshCommand = touch /tmp/RCE # = x
# git 剖析後等於：core.sshCommand = touch /tmp/RCE

下一次觸發 SSH 相關的 git 操作時，core.sshCommand 就會被當成 shell 指令執行，等同遠端程式碼執行；同樣手法也能偽造 core.hooksPath 搭配預先放置的 hook 檔案。另一個高風險編號 GHSA-wvpp-8hx9-p66j 則是先前修補（GHSA-r9mr-m37c-5fr3）的繞過：呼叫端傳入 split_single_char_options=False 搭配單字元參數時，安全檢查函式只會產生 ['-n'] 這種無值候選字串，真正組出來的合併引數 -nutouch ...;git-upload-pack 從未被送進黑名單比對，git 會把它剖析成 --upload-pack=<cmd> 直接執行任意指令。

GHSA-hmq2-w58f-27jc 屬於另一類問題：GitPython 用 .gitmodules 裡未經檢查的 submodule 名稱組出 .git/modules/<name> 路徑，若名稱是 ../../../../tmp/xxx 之類的路徑穿越字串，os.path.join 不會正規化，結果是在受害者硬碟任意位置建立完整 git repo；官方 git CLI 早已擋下這類名稱並顯示警告，GitPython 的獨立實作卻從未補上等效檢查。GHSA-4gmw-gg2m-w46p 則是 IndexFile.from_tree/reset/merge_tree 把字串位置參數直接接到 git read-tree，未加 -- 分隔也未做黑名單檢查，可注入 --index-output=/path 覆寫任意檔案。

受影響版本

六份通報影響版本一致，皆為 GitPython <= 3.1.57，修補版本一致為 3.1.58：

修補與緩解

六個編號全部在 3.1.58 一次修補，官方建議所有使用 GitPython 的專案立即升級。值得注意的共同前提是：這批漏洞多數要求呼叫端把外部可控的字串（設定名稱、指令關鍵字參數、submodule 名稱等）轉發進 GitPython 的 API，因此在升級之外，也應檢視程式中是否有把使用者輸入直接當成 git 選項名稱或 kwargs 傳入的路徑。

原始來源：GHSA-jm78-9fvv-mhgr、GHSA-wvpp-8hx9-p66j、GHSA-hmq2-w58f-27jc、GHSA-4gmw-gg2m-w46p、GHSA-9rj7-rf2p-w77r、GHSA-hh9p-6wh2-4mfc

Apache Fory 同日爆三個記憶體安全漏洞：多型指標偽裝、Go 解碼器崩潰與堆積越界讀取

oss-security · 2026-08-07

Apache Fory（跨語言序列化框架，前身為 Fury）開發者於 2026-08-07 透過 oss-security 郵件論壇連續發出三封通報，一次揭露 CVE-2026-71558、CVE-2026-71559、CVE-2026-71560 三個記憶體安全問題，全部在 1.5.0 版修補。三者分別出在 C++ 多型物件反序列化、Go 版 meta-string 解碼器、以及 C++ struct 反序列化的整數快速路徑。

漏洞機制

Apache Fory 的賣點是讓 Java、Python、Go、Rust、C++ 等語言之間可以直接互通物件圖，其中一項核心能力是在序列化資料中保留執行期的多型型別資訊，讓 C++ 端能透過 std::is_polymorphic 偵測並經由 std::shared_ptr／std::unique_ptr 還原出物件的真實子類別，而不需要手動標註型別。這個設計代價是反序列化端必須嚴格核對「資料聲稱的型別」與「目標基底型別」是否相容。

CVE-2026-71558（Important）正是這道相容性檢查被繞過：一個精心構造的輸入可以讓反序列化器在還原智慧指標時，把一個不相容型別的物件當成宣告的基底型別使用，造成堆積型別混淆（heap type confusion），後續存取可能導致未定義行為，進而引發阻斷服務甚至任意程式碼執行。此問題只影響有使用 C++ 多型智慧指標反序列化功能的應用，影響版本為 Apache Fory C++ 0.14.0 到 1.5.0 之前。

CVE-2026-71559（moderate）發生在 Go 語言實作：攻擊者送出帶有異常型別中繼資料（malformed type metadata）的資料，會讓 meta-string 解碼器在解析階段觸發未被攔截的 panic，導致處理該請求的服務直接崩潰，形成遠端阻斷服務，影響 Apache Fory Go 0.16.0 到 1.5.0 之前。CVE-2026-71560（moderate）則是 C++ struct 反序列化中，針對帶有 tagged 整數欄位的結構所設計的「快速路徑」在讀取前未做邊界檢查，構造輸入可觸發堆積越界讀取（out-of-bounds heap read），可能造成資訊洩漏或服務中斷，影響版本同為 Apache Fory C++ 0.14.0 到 1.5.0 之前。

受影響版本

修補與緩解

三個 CVE 都在 Apache Fory 1.5.0 一次修補，官方通報都建議直接升級到該版本。各 CVE 的影響面其實互不重疊：不使用 C++ 多型智慧指標反序列化的應用不受 CVE-2026-71558 影響，不使用 Go 版實作的不受 CVE-2026-71559 影響，不使用 C++ 或不使用 tagged 整數欄位的則不受 CVE-2026-71560 影響，但由於三者共用同一個修補版本，升級一次即可全部涵蓋。

原始來源：CVE-2026-71558 (oss-security)、CVE-2026-71559 (oss-security)、CVE-2026-71560 (oss-security)

CodeIgniter4 同批修四個漏洞：Query Builder 批次刪除漏掉了一個逸境旗標

GitHub Advisory Database · 2026-08-07

CodeIgniter4 團隊於 2026-08-07 同時發布四份資安通報，核心是 Query Builder 的 deleteBatch() 方法在搭配 where() 條件使用時會導致 SQL 注入，同批通報還包含上傳檔案副檔名檢查繞過、UploadedFile::move() 路徑穿越、以及可被偽造的 HTTPS 標頭判斷。四者影響版本都落在 codeigniter4/framework 4.x 系列，並統一在 4.7.4 版修補。

漏洞機制

CodeIgniter4 的 Query Builder 平常會替 where() 綁定的每個值標記一個「是否需要逸境（escape）」旗標，交由資料庫驅動在組出最終 SQL 前先加上引號並跳脫特殊字元，行為類似參數化查詢。GHSA-c9w5-rwh3-7pm9（CVE-2026-63221，CVSS 9.4）的問題在於 deleteBatch() 這條路徑會直接把 where() 綁定值塞進產生的 SQL，卻完全忽略了逸境旗標，等於把使用者輸入原封不動當成 SQL 片段拼接，只要應用程式把外部輸入傳進 where() 再呼叫 deleteBatch() 就會中招；一般的 delete() 呼叫並未受影響，因為那條路徑仍正確逸境。

// 危險寫法：$id 來自使用者輸入
$builder->where('id', $id)->deleteBatch($data);
// $id 被直接拼進 SQL，未逸境，等同字串串接

同批中嚴重度最高的是 GHSA-mmj4-63m4-r6h5（CVE-2026-63223，CVSS 9.8）：當應用只用 is_image 或 mime_in 驗證上傳檔案、沒有另外用 ext_in 做副檔名白名單，又把檔案以使用者提供的原始檔名存進可被 PHP 執行的公開目錄，攻擊者就能繞過影像/MIME 檢查上傳可執行的 PHP 檔案，達成遠端程式碼執行。GHSA-hhmc-q9hp-r662（CVE-2026-63222，CVSS 7.5）是 UploadedFile::move() 省略第二個參數（目標檔名）時直接使用未淨化的用戶端檔名，帶有 ../../public/shell.php 之類路徑穿越序列即可寫到預期目錄之外；官方修補只淨化這條省略參數的預設路徑，若應用自行傳入 getClientName() 仍需自行淨化。第四份 GHSA-7wmf-pw8j-mc78（CVE-2026-63220，CVSS 4.8）較輕微：IncomingRequest::isSecure() 無條件信任 X-Forwarded-Proto 與 Front-End-Https 標頭，反向代理若未過濾，攻擊者偽造標頭即可讓應用誤判成安全連線。

受影響版本

四份通報的影響版本範圍一致，皆為：

• codeigniter4/framework >= 4.3.0, < 4.7.4（SQL 注入 CVE-2026-63221）
• codeigniter4/framework < 4.7.4（其餘三項）

修補與緩解

官方針對四個問題都給出 4.7.4 以外的暫時緩解措施：deleteBatch() 應改用一般 delete() 搭配 Query Builder 綁定值處理使用者可控條件；上傳檔案應改用 $file->getRandomName() 產生的隨機檔名而非客戶端檔名，並將上傳目錄移出可被腳本執行的公開路徑；反向代理應在轉發請求前清除或覆寫用戶端送來的 X-Forwarded-Proto／Front-End-Https 標頭。這些都只是暫時繞過，四個問題最終都需要升級到 4.7.4 才算修復完整。

原始來源：GHSA-c9w5-rwh3-7pm9、GHSA-mmj4-63m4-r6h5、GHSA-hhmc-q9hp-r662、GHSA-7wmf-pw8j-mc78