Camunda 7 CVE-2026-109432 i 109433: wykonanie poleceń przez orQueries i Cockpit bez filtrowania uprawnień. Rekord CVE jako najsłabsze ogniwo decyzji

19 października VulnCheck opublikował dwa CVE dla Camunda 7 na podstawie badań CodeAnt AI. CVE-2026-109432 (9.3): wyrażenie JUEL włożone w podzapytanie OR w API zapytań o zadania omija blokadę wyrażeń i kończy się wykonaniem poleceń systemowych jako konto usługi silnika. CVE-2026-109433 (6.0): jedno dowolne ustawienie w disabledPermissions wyłącza filtrowanie uprawnień w zapytaniach Cockpit. Sam mechanizm jest dobrze opisany. Gorzej z rekordem CVE, na którym VM opiera decyzję. Opis mówi „authenticated”, a wektor PR:N. Zakres obejmuje tylko 7.23 i 7.24, choć kod pochodzi z 2017 i 2019 roku. Producent nie ma notice dla tych CVE, a wersja „naprawiona” jest starsza niż dwie kolejne poprawki bezpieczeństwa Camunda.

Dwa błędy, dwa profile ryzyka

Te CVE wyszły razem, ale do rejestru trafiają osobno. Jeden to wykonanie kodu przy bezpiecznej konfiguracji, drugi to wyciek metadanych przy niestandardowej:

CVE-2026-109432. API zapytań o zadania przyjmuje wyrażenia JUEL zamiast stałych wartości. Camunda wiedziała, że to wykonanie kodu, i w 2015 roku wprowadziła ustawienie enableExpressionsInAdhocQueries, domyślnie false, egzekwowane przez AdhocQueryValidator. Według CodeAnt warstwa REST buduje każde podzapytanie z pola orQueries konstruktorem, który nie podpina walidatora. Sprawdzenie dla podzapytań istnieje, ale iteruje po pustej liście, i tak jest od 2017 roku, gdy dodano zapytania OR. Skutek według badaczy: konto bez żadnych uprawnień, na instancji z włączonym uwierzytelnianiem i autoryzacją, wykonało polecenie systemowe jako konto usługi silnika.

CVE-2026-109433. Cockpit ma własną kopię predykatu „czy to uprawnienie jest wyłączone” z odwróconym porównaniem. Dla pustej listy odpowiada dobrze, dla każdej niepustej źle. Pusta lista to ustawienie domyślne, więc błąd przetrwał od marca 2019. Wystarczy jeden wpis w disabledPermissions, np. dodany dla wydajności, żeby zapytania pluginów Cockpit szły bez filtra autoryzacji. CodeAnt precyzuje skutek węziej niż rekord CVE: identyfikatory, klucze, nazwy, liczniki i czasy startu, bez zmiennych procesów i bez przejścia między tenantami. Szkic, z którego powstał ten wpis, sugerował wyciek danych osobowych z instancji procesów. Badacze tego nie twierdzą. Nazwy procesów i klucze biznesowe mogą jednak same w sobie zdradzać sporo, zależnie od tego, co w nich zapisujecie.

„Authenticated” w opisie, PR:N w wektorze

Rekord 109432 mówi w opisie „allowing authenticated users”, a wektor CNA ma PR:N. Oba zdania są prawdziwe, ale dla różnych instalacji. CodeAnt wyjaśnia to wprost: obraz camunda/camunda-bpm-platform:run w domyślnej konfiguracji nie włącza uwierzytelniania REST API. Klucz run.auth.enabled nie występuje w default.yml, tylko w production.yml. Na takim obrazie endpoint odpowiada bez poświadczeń, więc wektor opisuje „konfigurację zastaną”. Na instancji utwardzonej to eskalacja od konta bez uprawnień do konta usługi.

Badacze dodają uczciwą uwagę: na domyślnym obrazie bez uwierzytelniania atakujący i tak ma wykonanie kodu przez zwykłe API wdrożeń (proces z zadaniem skryptowym). Marginalny wkład tego CVE jest tam bliski zeru. Paradoks dla VM: 109432 jest najgroźniejszy tam, gdzie zrobiono wszystko dobrze. Na instancji bez uwierzytelniania właściwym findingiem jest sam brak uwierzytelniania, z CVE czy bez. Na instancji utwardzonej to CVE łamie model, któremu ufasz.

Tak samo jak przy Redis CVE-2026-81934 czy Spring SpEL: wektor i opis opisują różne ścieżki ataku. Wybierz ścieżkę, która pasuje do Twojej instalacji, i zapisz przy findingu, dlaczego.

Ustawienie, które nic nie daje

Szkic zalecał „przejrzeć konfigurację enableExpressionsInAdhocQueries”. To dobry odruch, ale tu chybiony. Ten błąd omija właśnie to ustawienie w jego bezpiecznej pozycji. Według CodeAnt żadna konfiguracja nie łagodzi 109432. Przegląd ustawienia nie jest więc kontrolą kompensującą i nie powinien uzasadniać wyjątku ryzyka. Ten sam wzorzec, kontrola obecna, ale niedziałająca, opisywałem przy Ignition.

Odwrotnie przy 109433: tu konfiguracja decyduje o wszystkim. Pusta disabledPermissions oznacza brak ekspozycji. Niepusta oznacza, że filtrowanie w Cockpit nie działa dziś. Sprawdzenie jednej właściwości w konfiguracji silnika daje pełną odpowiedź.

Zakresy wersji: rekord, badacze i producent mówią co innego

Trzy problemy dla VM:

1. defaultStatus: unaffected przy kodzie z 2017 roku. Rekord wymienia tylko 7.23 i 7.24. Skaner czytający pole affected uzna 7.22, 7.21 i starsze za niepodatne. Badacze testowali tylko 7.24.0. Pochodzenie kodu sugeruje, że starsze gałęzie mogą mieć ten sam błąd, ale nikt tego publicznie nie potwierdził. Jeśli masz 7.22 lub starsze, status powinien brzmieć „pod analizą”, a nie „not affected”. To niepotwierdzone w obie strony.
2. Wersja „naprawiona” jest starsza niż kolejne poprawki producenta. 7.24.14 według notice 168 Camunda jest podatna na inny CVE (fix w 7.24.15). Według notice 171 7.24.15 jest podatna na kolejne dwa (fix w 7.24.16). Zamknięcie ticketu na 7.24.14 oznacza zamknięcie go na wersji z dwoma znanymi lukami. Cel: ≥ 7.24.16 albo najnowsza dostępna.
3. Producent milczy. Camunda publikuje notices „po udostępnieniu poprawek”. Dla CVE-2026-77226 (inny błąd zgłoszony przez VulnCheck) notice jest. Dla 109432 i 109433 na 20.10.2026 nie ma. Nie wiem, czy fix rzeczywiście jest w 7.24.14 i 7.23.17, bo nie udało mi się sprawdzić commitów w repozytorium. Do czasu notice wersja naprawiona pochodzi tylko od CNA.

EOL: łatka dla klientów enterprise, lokalna łatka dla reszty

Strona dokumentacji Camunda ma baner „Camunda 7 is reaching End of Life”, a notices mówią, że poprawki są dostępne „as patches to the enterprise platform”. CodeAnt pisze, że Camunda 7 Community Edition jest już EOL i realnym środkiem jest lokalna łatka. Dla VM to dwa różne tickety:

• Camunda 7 Enterprise: ticket na patch release (cel ≥ 7.24.16), z potwierdzeniem w notices lub u wsparcia producenta, że zawiera fix tych dwóch CVE.
• Camunda 7 Community: to nie jest ticket na patch, tylko decyzja o ryzyku. Opcje: własny build z poprawką (CodeAnt opisuje jej miejsce), filtr na brzegu dla zapytań o zadania z wyrażeniami w podzapytaniach OR (propozycja CodeAnt, sami nazywają ją „crude”), albo przyspieszona migracja do Camunda 8. Sam EOL jest tu findingiem, co opisywałem przy UpTrain.

Daty końca wsparcia Camunda 7 CE nie zweryfikowałem w źródle producenta. W rejestrze oprzyj się na stronie z harmonogramem EOL Camunda, a nie na tym wpisie.

Dlaczego silnik procesów to nie „aplikacja pomocnicza”

Konto usługi silnika BPM zwykle ma dostęp do bazy procesów, poświadczeń integracji, kolejek i usług wewnętrznych, które procesy wywołują. Wykonanie poleceń jako to konto to dostęp do sekretów integracyjnych, a nie tylko do jednego hosta. Przy ocenie blast radius zapytaj: co silnik może wywołać, jakie sekrety ma w zmiennych środowiskowych lub konfiguracji i czy REST API jest wystawione poza strefę aplikacyjną, np. dla Tasklist dostępnego z internetu.

Co powinien zrobić VE

1. Inwentarz: wszystkie instancje Camunda 7 z wersją, edycją (Enterprise czy Community), informacją, czy REST API i Cockpit są osiągalne i skąd, oraz czy uwierzytelnianie i autoryzacja są włączone. Obrazy run z domyślną konfiguracją traktuj jako nieuwierzytelnione, dopóki nie sprawdzisz.
2. 109432: priorytet najwyższy dla instancji z włączonym uwierzytelnianiem, do których mają konta osoby spoza wąskiego zespołu, i dla każdej instancji z REST API spoza strefy zaufanej. Bez uwierzytelniania otwórz osobny finding na brak uwierzytelniania, bo on jest groźniejszy.
3. 109433: odczytaj disabledPermissions. Puste: „not affected” z uzasadnieniem konfiguracyjnym. Niepuste: finding z priorytetem zależnym od tego, co zdradzają nazwy i klucze procesów, i kandydat do natychmiastowej zmiany konfiguracji.
4. Cel ticketu: ≥ 7.24.16 (Enterprise), z potwierdzeniem u producenta. Nie 7.24.14. Dla 7.23 i starszych: status „pod analizą” zamiast automatycznego „not affected” i pytanie do wsparcia Camunda.
5. Community Edition: decyzja o ryzyku z właścicielem biznesowym, plan migracji z datą, do tego czasu ograniczenie dostępu do REST API i Cockpit do sieci zaufanych.
6. Detekcja: według CodeAnt obie ścieżki są w logach prawie niewidoczne. Nie obiecuj analizy wstecznej opartej na logach aplikacji. Jeśli podejrzewasz nadużycie, zacznij od procesów potomnych JVM silnika i ruchu wychodzącego z hosta.
7. Higiena danych: CVE-2026-77228 jest odrzucony jako duplikat 109433. Jeśli Twoje narzędzie go zaciągnęło, zamknij jako „rejected”, nie jako „fixed”.

Powiązane na blogu

• Redis CVE-2026-81934 — rekord mówi unauthenticated, vendor authenticated
• Spring CVE-2026-59283 — CVSS opisuje inny attack path niż advisory
• Craft CMS i VulnCheck — czyje CVSS jest Twoje
• Ignition: pusta rola, kontrola, która nic nie robi — insecure default ważniejszy niż błąd w kodzie
• IBM ContextForge CVE-2026-78573 — Critical, który nie jest Critical dla każdego wdrożenia
• UpTrain: EOL jako finding — kiedy brak wsparcia jest problemem samym w sobie

Źródła

• CVE.org — CVE-2026-109432 (CNA VulnCheck, CVSS 4.0 9.3 PR:N, CWE-917, CWE-78, zakresy 7.23/7.24, SSVC CISA-ADP) — cve.org
• CVE.org — CVE-2026-109433 (CNA VulnCheck, CVSS 4.0 6.0, CWE-863) — cve.org
• CVE.org — CVE-2026-77228 (zarezerwowany 20.08.2026, odrzucony 19.10.2026) — cve.org
• CodeAnt AI — CVE-2026-109432: The Validator That Had Nothing to Validate (16.10.2026) — codeant.ai
• CodeAnt AI — CVE-2026-109433: How One Disabled Permission Disabled Them All (14.10.2026) — codeant.ai
• VulnCheck — Camunda Expression Injection via orQueries RCE — vulncheck.com
• VulnCheck — Camunda Broken Access Control via Cockpit — vulncheck.com
• Camunda — Security Notices (notices 163, 168, 171; brak notice dla CVE-2026-109432/109433 na 20.10.2026) — docs.camunda.org
• NVD — CVE-2026-109432 (status Deferred, bez CPE) — nvd.nist.gov
• CISA Known Exploited Vulnerabilities Catalog (brak obu CVE w wersji 2026.10.21) — cisa.gov

Nota redakcyjna: wpis powstał na podstawie szkicu VMRT Radar z 19.10.2026 i został zweryfikowany ze źródłami 20 października 2026 (ok. 18:30–19:10 CEST): rekordy CVE-2026-109432, CVE-2026-109433, CVE-2026-77228 i CVE-2026-77226 w API CVE.org, NVD API 2.0 (statusy Deferred, wektory VulnCheck, CWE-863 dla 109433), opisy badań CodeAnt AI dla obu CVE (mechanizm, warunki, wektory autorów, uwagi o konfiguracji domyślnej obrazu run, EOL Community Edition), advisories VulnCheck, strona Camunda Security Notices (notices 163, 168 i 171, brak notice dla tych CVE), katalog CISA KEV w wersji 2026.10.16 i API EPSS. 22 października 2026 ponownie sprawdziłem katalog CISA KEV (wersja 2026.10.21: nadal brak wpisu) oraz rekordy CVE i stronę Camunda Security Notices (bez zmian, nadal brak notice dla obu CVE). Względem szkicu poprawiłem: ustawienie enableExpressionsInAdhocQueries nie łagodzi 109432, skutek 109433 to metadane bez zmiennych procesów, wektor 109432 ma PR:N mimo opisu „authenticated”, cel aktualizacji to ≥ 7.24.16, a nie 7.24.14. Nie potwierdziłem: czy 7.24.14 i 7.23.17 faktycznie zawierają poprawki (nie sprawdziłem commitów), czy gałąź 7.22 i starsze są podatne, stanowiska Camunda, daty EOL Camunda 7 Community Edition ani wykorzystania poza dowodem badaczy. Ocena priorytetów, interpretacja PR:N i podział na tickety Enterprise i Community to opinia autora.