Apache Impala 4.5.2: klient z uprawnieniami do Data Source może załadować własną klasę Java i uzyskać RCE — kiedy „authenticated/privileged” nie znaczy niskiego ryzyka

Apache ujawnił 8 września 2026 CVE-2026-65181 (Impala 2.7.0–4.5.1, fix 4.5.2). Opis jest krótki, ale konkretny: niewystarczająca autoryzacja Data Source tables pozwala klientowi z odpowiednimi uprawnieniami załadować plik do zdalnego storage, utworzyć tabelę i wykonać arbitralny kod Java. Severity: important. To nie jest unauthenticated RCE — i właśnie dlatego jest ciekawsze dla VE.

CVE-2026-65181: External Data Source → upload artefaktu + create table referencing attacker-controlled code → class load → arbitrary Java jako Impala daemon.

Affected/fix: 2.7.0–4.5.1 / 4.5.2 (wspólny release z CVE-2026-56207 SAML bypass).

Data Source to security boundary

External Data Source z natury jest blisko code execution — pozwala wskazać zewnętrzny JAR/class. Bezpieczeństwo nie zależy od tego, czy class loader „bezpiecznie” ładuje kod (robi dokładnie to, do czego został zaprojektowany), lecz od tego: kto ma prawo doprowadzić do załadowania nowej klasy? To wzorzec dangerous-by-design capability + incorrect authorization = RCE.

Scanner wykryje wersję, nie priorytet

Dwie instancje 4.5.1 wyglądają w SCA identycznie. Ale środowisko A (Data Source nieużywany, ograniczone CREATE, brak uploadu, wąski scope daemona) i środowisko B (wielu analystów tworzy Data Source, wspólny bucket, szerokie credentials daemona) mają inne ryzyko. Zamiast PR:L potrzeba precyzji:

requires: authenticated_impala_user: true remote_storage_upload: true data_source_table_create: true

To można zestawić z RBAC/grants i storage ACL — exploitability liczona z evidence, nie z ogólnego CVSS.

Blast radius = tożsamość daemona

Po RCE kod działa w kontekście usługi. VE sprawdza: pod jakim userem działa Impala, jakie ma Kerberos tickets i Hadoop credentials, jakie storage paths są writable, czy host jest współdzielony, jakie sekrety są montowane. To zmienia „RCE in analytics engine” w application user → Impala daemon → Hadoop / storage / secrets / lateral movement.

Controls i weryfikacja

Podstawa: upgrade do 4.5.2. Jeśli niemożliwy — uderzaj w predykaty: ogranicz CREATE/Data Source privileges, ogranicz upload do storage (przerywa chain), zawęź service account (redukuje post-exploitation, ale to nie „not exploitable”). VEX not_affected tylko, gdy feature wyłączony lub uprawnienie nieosiągalne; „daemon runs as non-root” to affected, impact reduced. Po patchu: restart wszystkich daemonów, negatywny test (zwykły analyst nie tworzy nieautoryzowanego Data Source → brak class loading).

Wniosek

CVE-2026-65181 pokazuje, że etykieta „authenticated user with privileges” bywa źle interpretowana. Model dla VE: principal privilege → dangerous feature reachability → code-loading authority → service identity → downstream blast radius. Dopiero ten graph mówi, czy finding jest w danym środowisku naprawdę krytyczny.

Powiązane na blogu

Budibase: admin aplikacji ≠ root — deklarowane vs efektywne uprawnienie
Pimcore: „low privilege”, które generuje PHP — capability blisko code execution

Źródła

Apache Impala / oss-security — CVE-2026-65181 (08.09.2026) — seclists.org
CVE.org — CVE-2026-65181 — cve.org

Nota redakcyjna: stan informacji 9 września 2026. CVE-2026-65181 (Apache Impala 2.7.0–4.5.1, fix 4.5.2): niewystarczająca autoryzacja External Data Source pozwala uprawnionemu klientowi na wykonanie kodu Java jako daemon. Artykuł koncentruje się na privilege boundary violation i zależności blast radius od tożsamości usługi.