Airflow Kafka provider 補上 callback 允許清單，封住 Scheduler 端 RCE
oss-security · 2026-09-15
Apache Airflow 的 apache-airflow-providers-apache-kafka，把連線設定裡任意字串都能解析成 Python callable 的做法，改成預設關閉、要靠允許清單才能啟用，堵上一個能讓只有連線編輯權限的使用者在 Scheduler 端跑任意程式碼的洞。這項修補以 CVE-2026-86792 公布，影響版本 1.15.0 到 2.0.0 之前，修補版本 2.0.0 已於 2026-09-08 合併進 PR #72208，oss-security 於 2026-09-15 公開揭露。對有開放自助建立連線的多租戶 Airflow 部署來說，這是一個能直接從「編輯連線」跳到「控制 Scheduler」的權限升級漏洞。
漏洞機制
Kafka provider 允許在連線的 extra 欄位裡填一段模組路徑字串，例如 oauth_cb，執行時用 import_string 把這段字串解析成 Python callable，再拿去當 SASL OAUTHBEARER 的認證 callback。這個字串解析機制本身是 PR #68082 加進去的功能，用意是讓使用者能接自訂的 token 取得邏輯，不必為每種驗證方式各寫一個 provider 分支。
問題出在解析時完全沒有做任何允許清單或型別檢查：只要 extra 裡塞得進去的路徑，import_string 就會照樣 import 並在建立 Kafka client 時呼叫，不管這個路徑指向的是驗證用的 callback，還是 os.system 這種跟 Kafka 完全無關的內建函式。呼叫時機也沒有任何沙箱或權限降級。
// 惡意的連線 extra 設定
{"oauth_cb": "os.system", "sasl.mechanism": "OAUTHBEARER"}更關鍵的是執行位置：一旦 DAG 啟用了 dag_run_events_enabled 或 task_instance_events_enabled，Airflow 會在Scheduler 行程本身建立 Kafka producer 來發送生命週期事件，而不是像一般 task 那樣丟給 worker 執行。import_string 對 oauth_cb 的解析，也就跟著在 Scheduler 裡跑。
正常情況下，Airflow 的 RBAC 權限模型假設只能編輯連線（can_edit on Connection）的使用者，頂多影響自己 DAG 底下 worker 執行的 task，不該碰到 Scheduler 這個管理所有 DAG 排程的核心行程。這個洞把 callback 解析搬進 Scheduler 之後，等於讓連線編輯權限直接升級成 Scheduler 端的任意程式碼執行，超出原本設計的權限邊界，也讓一個租戶的惡意連線設定能影響到整個 Airflow 部署。
受影響版本
| 套件 | 受影響版本 | 修補版本 |
|---|---|---|
apache-airflow-providers-apache-kafka | 1.15.0 至 2.0.0 之前 | 2.0.0 |
oss-security 的公告把嚴重度標為Moderate。受影響範圍分兩種：連到一般的 Kafka broker或Amazon MSK、且在連線 extra 裡設定 SASL OAUTHBEARER callback 的部署會中招；使用Google Managed Kafka的部署則因為認證路徑不同，不受影響。值得注意的是，Amazon MSK 走 IAM 驗證時本來就常需要自訂 OAUTHBEARER token provider，等於這條路徑在真實產線環境裡並不罕見，不是只有少數特殊設定才會踩到。
修補與緩解
PR #72208 的做法是加一個部署層級的允許清單設定，只有清單裡列出的模組路徑才會被 import_string 解析，其餘一律拒絕。允許清單預設是空的，代表升級後字串型 callback 解析預設整個關閉，要自訂 callback 的部署得自己把信任的路徑加回清單，等於把「哪些程式碼可以被連線設定觸發」的決定權，從連線編輯者手上收回到部署管理者手上。
// 修補後：allowlist 為空 -> 字串 callback 解析預設關閉
// 需要自訂 callback 的部署，須在 allowlist 設定中明列信任路徑對還在用 apache-airflow-providers-apache-kafka 1.x、且啟用了 dag_run_events_enabled 或 task_instance_events_enabled 的部署，該做的事很具體：先升級到 2.0.0 以上；升級前，先盤點誰有連線編輯權限，並檢查現有連線的 extra 欄位有沒有已經被塞入可疑的模組路徑，例如指向 os、subprocess 之類跟驗證無關的模組。若暫時無法升級，至少要把連線編輯權限收緊到可信任的少數帳號，並留意 Scheduler 行程有沒有出現非預期的 import 或子行程，這類異常在正常的 Kafka 事件發送流程裡不應該出現。這次漏洞由 Claude Security Scans 這個掃描工具找出，修補由 Christos Bisias 完成，於 2026-09-08 合併進主線。