CVE-2026-36849：libtiff SamplesPerPixel 標籤引發記憶體耗盡型拒絕服務漏洞
oss-security · 2026-06-17
2026 年 6 月 16 日，安全研究員 Satriyo Utomo（aleens-lab）透過 oss-security 郵件列表揭露了 libtiff 函式庫中一個可遠端觸發的拒絕服務漏洞，CVE 編號為 CVE-2026-36849。該漏洞影響 libtiff 4.7.1 及更早版本，攻擊者只需讓目標應用程式開啟或處理一個惡意構造的 TIFF 檔案，即可導致程序崩潰或記憶體耗盡。此漏洞的根本原因在於函式庫在解碼 TIFF 影像條帶時，對 SamplesPerPixel 標籤的數值缺乏合理上限驗證。
漏洞機制
TIFF 格式透過標籤（Tag）描述影像的屬性，其中 SamplesPerPixel（標籤 0x0115） 用於指定每個像素所包含的樣本數量。在正常的影像檔案中，此數值通常為 1（灰階）或 3（RGB），極少超過個位數。然而 libtiff 在處理此標籤時，並未強制限制其最大值，攻擊者可以在構造的 TIFF 檔案中將其設為 0xFFF9（即 65529）。
當應用程式呼叫 TIFFReadRGBAImageOriented() 讀取一張 500×500 像素的影像時，記憶體分配的計算式變為：
500 × 500 × 65529 × 1 = ~16.4 GB (0x3d0754c10 bytes)此請求沿著以下呼叫鏈傳遞，最終抵達 malloc()：
TIFFReadRGBAImageOriented()
→ gtStripContig()
→ _TIFFReadEncodedStripAndAllocBuffer()
→ malloc(0x3d0754c10)在大多數 64 位元系統上，malloc 會嘗試向作業系統請求超過 16 GB 的虛擬記憶體，即便物理記憶體不足以滿足，此操作也可能導致系統大量佔用 swap 空間，拖垮其他進程，或在記憶體過量提交（overcommit）停用的環境中直接回傳 NULL 導致程序崩潰。此漏洞的 CWE 分類為 CWE-400（不受控資源消耗）與 CWE-789（不受控記憶體分配）。
受影響版本
- libtiff 4.7.1 及以下所有版本
- libtiff git master 分支（修補前）
由於 libtiff 廣泛被上游套件依賴，幾乎所有使用 libtiff 進行圖片解碼的應用程式均受到影響，包括影像轉換工具、文件處理程式庫、地圖軟體（GeoTIFF）及多媒體框架。
修補與緩解
libtiff 主要維護者 Even Rouault 於 2026 年 4 月 21 日提交了修補提交 eedba405d3695b52faae65994c5904f228eca0bf。修補核心策略是引入新函式 TIFFGetMaxCompressionRatio()，用以在實際分配記憶體前，評估已壓縮條帶的大小是否與預期未壓縮尺寸相符，從而阻止不現實的超大分配請求。
新函式簽名與回傳值語意如下：
uint64_t TIFFGetMaxCompressionRatio(TIFF *tif);
// 回傳 0：壓縮比率未知
// 回傳 1：未壓縮資料
// 回傳 >1：已知最大壓縮比率，可據此驗算分配大小此函式整合至 _TIFFReadEncoded[Tile|Strip]AndAllocBuffer() 中，於呼叫 malloc() 前執行防護性判斷。此外，研究員 Satriyo Utomo 建議採用雙重防護：將 SamplesPerPixel 限制為最大值 32，同時將單次分配上限設為 256 MB。在修補套件正式發布前，使用者可於部署上游設置沙箱（如 seccomp）或在讀取前對 TIFF 來源進行可信度驗證，以降低風險。
原始來源：oss-security mailing list、GitLab Issue #781、修補提交 eedba405
CVE-2026-41280 與 CVE-2026-49050：Apache DolphinScheduler 雙重授權缺陷允許跨專案操作與管理員 Token 偽造
oss-security · 2026-06-17
2026 年 6 月 17 日，Apache DolphinScheduler 安全團隊透過 oss-security 郵件列表公開揭露了兩個獨立的授權邏輯缺陷：CVE-2026-41280 與 CVE-2026-49050，兩者皆影響 3.4.2 版本以前的所有 DolphinScheduler 發行版本。前者允許已驗證使用者刪除非授權專案的任務定義；後者允許已驗證使用者鑄造（mint）任意管理員等級的存取 Token。官方建議所有部署立即升級至 3.4.2 版本。
漏洞機制
DolphinScheduler 是一套廣泛用於大數據作業流程排程的分散式系統，其多租戶模型依賴專案層級（project-level）的存取控制將不同團隊的工作流程彼此隔離。CVE-2026-41280 的根本原因在於任務定義刪除端點缺少充分的專案歸屬驗證：API 僅確認請求者已通過身份驗證（系統登入），但未核實請求者是否隸屬於目標任務所屬的專案。
CVE-2026-49050 則是一個更為嚴重的授權升級問題。後端 Token 生成端點未正確驗證請求者是否具有管理員角色，使得任何持有有效登入憑證的一般使用者，均可直接呼叫該端點並取得具管理員權限的長效 Token，進而以最高系統權限執行後續操作。
這兩個漏洞的共同模式是：系統在身份驗證（Authentication）與授權（Authorization）之間存在明顯的邏輯斷層——系統確認了「你是誰」，但未充分驗證「你是否被允許對此資源執行此操作」。
受影響版本
| CVE | 元件 | 受影響版本 | 嚴重性 |
|---|---|---|---|
| CVE-2026-41280 | dolphinscheduler-api（任務定義刪除） | < 3.4.2 | 中等（Moderate） |
| CVE-2026-49050 | dolphinscheduler-api（管理員 Token 鑄造） | < 3.4.2 | 中等至高（Moderate–High） |
CVE-2026-49050 的實際危害程度應視部署規模而定：在多租戶的生產環境中，一名低權限使用者一旦取得管理員 Token，即可存取所有專案的任務定義、修改全域配置、新增或刪除使用者帳號，影響範圍遠超個別專案。
修補與緩解
官方修補已整合至 DolphinScheduler 3.4.2 版本。針對 CVE-2026-41280，修補在任務定義刪除路徑上新增專案歸屬校驗邏輯，確保操作對象的 projectCode 必須與請求者已授權的專案集合一致。針對 CVE-2026-49050，修補在 Token 生成端點加入角色斷言（role assertion），拒絕非管理員角色的 Token 鑄造請求。
- 立即升級至 Apache DolphinScheduler 3.4.2
- 升級前可考慮於反向代理層對 Token 生成端點（
/dolphinscheduler/access-tokens）套用 IP 白名單限制 - 稽核現有長效 Token，撤銷所有非預期的管理員等級 Token
- 啟用 DolphinScheduler 的操作審計日誌，回溯是否有異常的跨專案任務刪除紀錄
漏洞發現者 Yicheng Yu 向 Apache 安全回應團隊進行了負責任揭露（responsible disclosure）。兩個漏洞均不需要特殊網路位置即可利用，任何能夠向 DolphinScheduler API 伺服器發送 HTTP 請求並持有有效帳戶的攻擊者皆可嘗試利用。
原始來源：oss-security mailing list、CVE-2026-41280 記錄、Apache DolphinScheduler 官網
我本可以 Rickroll 整屆世界盃：FIFA 直播基礎設施授權繞過完整技術揭露
bobdahacker.com · 2026-06-17
一名安全研究員於 2026 年 FIFA 世界盃賽事期間發現，FIFA 多個關鍵內部平台存在嚴重的「前端授權、後端無驗證」（client-side authorization with no server-side enforcement）漏洞。受影響系統涵蓋足球資料平台（fdp.fifa.org）、評論員資訊系統（cis.fifa.org）及 MediaKind 串流管理基礎設施。攻擊者可透過公開的球員經紀人申請入口取得 FIFA Microsoft Entra 租戶成員資格，進而完全存取所有世界盃比賽的直播攝影機串流控制介面，在理論上可對全球廣播訊號執行任意訊號替換。
漏洞機制
FIFA 的多個內部應用程式建構於 Microsoft Azure 與 Entra ID（原 Azure Active Directory）之上，使用 Angular 前端框架。系統的存取控制完全依賴 JWT Token 中的角色聲明（role claims）在前端進行渲染決策：若 JWT 中缺乏對應角色，Angular 應用程式會顯示拒絕存取的畫面，阻止使用者看到操作介面。然而後端 API 服務的設計存在根本性缺陷——它只驗證請求者是否為合法的 Entra 租戶成員（即「身份驗證」成功），卻從未在服務端對應 HTTP 請求中的角色聲明進行授權判斷。
攻擊鏈的起點出乎意料地簡單。研究員透過 agents.fifa.org 公開的球員經紀人申請入口完成申請後，帳號被自動納入 FIFA 的 Entra 租戶。此後，使用者取得的 Entra Bearer Token 雖在 JWT Payload 中不包含任何特殊角色聲明，但已足夠通過所有後端 API 的身份驗證中間件。研究員直接對後端 API 發送帶有此 Token 的 HTTP 請求，繞過前端的角色渲染邏輯，即可取得完整的資料回應。
暴露的攻擊面
透過上述攻擊鏈，研究員得以存取以下資產：
- 串流管理介面：每場比賽的五個攝影機角度（PGM、Tactical、Camera1、High Behind Left、High Behind Right）的 RTMP 推流地址及內嵌的串流金鑰（stream keys），以及直播預覽 manifest 與攝影機開關控制
- 賽事資料寫入：可寫入比賽評論、開賽時間、技術陣容、比分及統計數據，這些資料直接輸入廣播字幕系統
- 評論員系統：即時顯示球員位置、隊形佈陣及賽前簡報的直播儀錶板
- 內部文件：23 份 FIFA 文件（含轉會報告、財務資料），透過 Azure Blob Storage 直接 URL 可下載
最具破壞性的攻擊場景是：持有 RTMP 串流金鑰後，攻擊者可同時向所有攝影機的推流端點傳送任意視訊內容，在全球廣播訊號中植入未經授權的畫面——研究員以「Rickroll 整屆世界盃」作為具象描述。
揭露過程與回應
研究員嘗試聯繫 FIFA 的揭露過程充滿阻礙。向超過 10 個 FIFA 電子郵件地址發送報告，其中 5 個直接退信，其餘未獲任何回覆。研究員最終透過 MediaKind 的技術支援電話完成報告交接，並同步知會美國網路安全暨基礎設施安全局（CISA）24 小時行動中心及 FBI 聯絡窗口。漏洞在報告後約 24 小時內完成修補。
然而 FIFA 始終未對研究員的報告給予任何形式的官方確認、致謝或漏洞獎勵（bug bounty）。修補完成後，FIFA 甚至持續將研究員保留在其官方郵件發送清單中，繼續定期傳送比賽相關文件。此案例再次凸顯大型體育組織在安全回應流程與漏洞揭露政策方面的嚴重不足，儘管攻擊面涵蓋了具有全球廣播影響力的核心直播基礎設施。
技術根因與設計建議
此漏洞的核心在於一個在企業 SaaS 與雲端原生應用程式中反覆出現的反模式：信任前端渲染邏輯作為唯一的授權防線。正確的設計應在每個 API 端點的伺服器端中介件（middleware）獨立執行授權決策，確保即使攻擊者繞過前端、直接構造 HTTP 請求，後端也能正確拒絕未授權操作。對於使用 Microsoft Entra 的組織，應將角色聲明的驗證移至 Azure API Management 或應用程式本身的授權中介件層，而非依賴前端 Angular Guard。此案例中不涉及 CVE 編號，亦無公開的安全通報，修補細節由 FIFA 與 MediaKind 私下處理。