舊版 UEFI shim 從未被列入撤銷清單，Secure Boot 仍照單全收
LWN.net · 2026-07-15
CERT/CC 於 2026-07-15 發布 VU#616257，指出多個經 Microsoft 簽署的 UEFI shim bootloader（0.7、0.8、0.9 版）從未被加入撤銷清單，導致這些早已知有漏洞的版本至今仍能通過 Secure Boot 驗證。LWN 同日的報導整理了社群討論，重點不在單一漏洞本身，而是撤銷機制長期存在的維運缺口。shim 是 Linux 開機鏈中負責在啟用 Secure Boot 的機器上驗證並載入 bootloader／核心的中介元件，一旦 shim 本身可被繞過，後續整條信任鏈就形同虛設。
漏洞機制
CERT/CC 追蹤的核心問題編號為 CVE-2026-8863，另有影響 Red Hat 系發行版變體的 CVE-2026-10797。攻擊者若具備系統管理權限或能竄改開機流程，即可利用一個 Bring Your Own Vulnerable Driver（BYOVD）手法，把舊版 shim 當作跳板，在作業系統載入前執行任意程式碼。由於執行時機早於核心與防護軟體啟動，這類早期程式碼執行足以植入可在重灌或重開機後仍存續的惡意元件。撤銷理論上分兩層：韌體層的 dbx（禁用簽章雜湊清單）與較新的 SBAT（Secure Boot Advanced Targeting，依元件世代而非單一雜湊撤銷），但兩者都仰賴廠商實際推送更新，舊版 shim 因此長期未被下架。
受影響版本
- Red Hat Enterprise Linux / CentOS 7.2
- Oracle Linux 7.2
- openSUSE 多個版本
- Baramundi Management Suite ≤ 2024R1
- WhiteCanyon WipeDrive
8.0.0–8.1.3
修補與緩解
CERT/CC 建議透過 Microsoft dbx 更新撤銷已知有漏洞的 shim 二進位檔，並優先採用支援 SBAT 的較新 shim 版本，因為 SBAT 可依世代批次撤銷而不必逐一列舉雜湊。可用 Check-UEFISecureBootVariables、uefi-dbx-audit 等工具檢查機器上的撤銷清單是否已包含這些舊版本。目前多數硬體廠商尚未針對此輪揭露公開回應，僅 AMI、Baramundi、GIGABYTE 已表態處理。
原始來源：LWN.net、CERT/CC VU#616257
django-haystack 別名比對疏漏，Elasticsearch 結果反序列化可觸發 eval() 任意執行
GitHub Security Advisories · 2026-07-15
GitHub 發布安全公告 GHSA-r3hx-x5rh-p9vv，揭露 Django 搜尋抽象層套件 django-haystack 的 Elasticsearch 後端存在遠端程式碼執行漏洞，CVSS v3 評分 8.5、CVSS v4 評分 8.7，分類為 CWE-95（Eval Injection）。django-haystack 讓 Django 專案能以統一介面串接 Elasticsearch、Solr 或 Whoosh 等搜尋引擎，是不少 Django 站台實作全文檢索的常見選擇。
漏洞機制
問題出在 SearchField 使用 index_fieldname 設定與邏輯欄位名稱不同的別名時。後端在 haystack/backends/elasticsearch_backend.py:865 依邏輯名稱去 index.fields 查找對應欄位，但 Elasticsearch 實際是用別名鍵值儲存資料，查找因此失敗。比對失敗的值會被當成未匹配欄位，直接送進 _to_python()，而該函式對這類值會無條件呼叫 eval(value)。攻擊者只要能控制被索引的內容、且應用程式會將搜尋結果回傳給使用者，就能讓惡意字串在伺服器端被當作 Python 程式碼執行。
受影響版本
- django-haystack
< 3.4.0（存在漏洞，且需使用 Elasticsearch 後端並設定index_fieldname別名） - django-haystack
3.4.0（已修補）
修補與緩解
官方建議直接升級至 3.4.0。公告同時指出根本修法方向：查找邏輯應先建立欄位別名對照表（如同 Solr 後端既有的作法）再取值，並以 ast.literal_eval() 取代 eval() 安全解析序列化字串，避免任意程式碼被執行。
原始來源：GHSA-r3hx-x5rh-p9vv
Tomcat RewriteValve 十六進位解碼有誤，可繞過以規則實作的存取限制
oss-security mailing list · 2026-07-14
Apache Tomcat 開發者 Mark Thomas 於 2026-07-14 在 oss-security 郵件論壇公開 CVE-2026-59083，說明 Tomcat 的 RewriteValve 元件在處理 URL 路徑中的十六進位編碼字元時解碼方式有誤，可能讓原本應被規則擋下的請求繞過限制。RewriteValve 是 Tomcat 內建、類似 Apache mod_rewrite 的元件，管理員常用它依 URL pattern 改寫路徑或擋掉特定路徑存取，其比對邏輯若與實際解碼結果不一致，等於讓存取控制規則失效。
漏洞機制
RewriteValve 的規則比對在特定解碼階段進行，但當路徑中含有特定十六進位編碼序列時，元件解碼出的字元與 Tomcat 後續實際用來路由請求的路徑並不一致。管理員設計用來擋掉的路徑樣式因而比對不到編碼後的變形寫法，請求得以繞過該條規則。此問題被列為低嚴重性，因為前提是站台本身依賴 RewriteValve 規則做存取限制，且需要攻擊者知道確切的編碼繞過方式。
受影響版本
| 分支 | 受影響版本 | 修補版本 |
|---|---|---|
| Tomcat 11 | 11.0.0-M1 – 11.0.23 | 11.0.24 |
| Tomcat 10.1 | 10.1.0-M1 – 10.1.56 | 10.1.57 |
| Tomcat 9 | 9.0.0-M1 – 9.0.119 | 9.0.120 |
| Tomcat 8.5 | 8.5.0 – 8.5.100 | 建議升級至上述分支 |
修補與緩解
Apache Tomcat 官方修法是修正 RewriteValve 的解碼流程，使其與請求實際路由所用的解碼結果一致。使用受影響版本且以 RewriteValve 規則做存取控制的站台，應盡速升級至對應修補版本；8.0.0 以前版本不受影響。
原始來源：oss-security 郵件論壇