8 września 2026 Apache ujawnił CVE-2026-73334 w org.apache.parquet.crypto.keytools (parquet-hadoop 1.12–1.18.0; fix 1.18.1). Klasyfikacja Moderate, ale najważniejsza jest granica zaufania. Parquet używa envelope encryption; opcjonalny URL KMS może być zapisany w samym pliku. Jeśli aplikacja pozwala na wariant file-controlled, URL z nieufnego pliku trafia do pluggable KmsClient — a jeśli custom klient nie waliduje hosta i używa tokenu, atakujący nakłania reader do wysłania tokenu na swój serwer.
To nie klasyczne SSRF do przypadkowego intranetu — celem jest przejęcie credential material do KMS. To przypadek, w którym dane wejściowe sterują endpointem systemu zaufania.
Sama wersja nie odpowiada „exploitable?”
Potrzeba czterech warunków: aplikacja używa encrypted Parquet / crypto.keytools; reader dopuszcza file-controlled KMS URL; pliki mogą pochodzić z nieufnego źródła; KmsClient honoruje URL bez walidacji hosta. VEX: not_affected / vulnerable feature not used albo KMS URL controlled exclusively by application.
Szyfrowanie pliku nie jest controlem
Ironiczny przypadek: mechanizm bezpieczeństwa (encryption/KMS) sam tworzy attack surface. „Dane są szyfrowane, więc bezpieczniejsze” — ale jeśli metadata w pliku steruje adresem usługi, do której aplikacja wyśle credential, encryption pipeline staje się kanałem exfiltration. security feature present != security architecture safe. I TLS nie pomoże, jeśli klient poprawnie zestawi TLS z serwerem atakującego i prześle mu token — liczy się nie „czy jest TLS?”, lecz „czy credential może trafić wyłącznie do zaufanego KMS endpointu?”.
Remediacja, egress i weryfikacja
Najlepiej: upgrade do 1.18.1+. Bez upgrade: KMS URL po stronie aplikacji, nie ufać URL z pliku, host validation w custom KmsClient, allowlist hostnames + HTTPS only + zablokowane/rewalidowane redirecty. Egress firewall bywa dobry (jeśli workload łączy się tylko do zatwierdzonego KMS — ale sprawdź DNS/proxy/service mesh/redirects/IPv6): control opisz jako „KMS token cannot leave to unapproved destination”, nie „firewall exists”. Negatywny test: plik z KMS URL do testowego endpointu → reader odrzuca / KmsClient odrzuca przed wysłaniem; zero requestów z credential (outbound telemetry).
Wniosek
CVE-2026-73334 nie jest historią o parserze plików, lecz o provenance konfiguracji. Pytanie VE: kto kontroluje KMS URL w runtime i czy udowodnimy, że token nigdy nie trafi poza zatwierdzony trust boundary?
Powiązane na blogu
- WooCommerce: „SSRF” do payment bypass — realny impact ukryty za CWE
- OpenAgents: SSRF do metadata/localhost — attacker-controlled destynacja
Źródła
- Apache / oss-security — CVE-2026-73334 (08.09.2026) — seclists.org
- CVE.org — CVE-2026-73334 — cve.org
Nota redakcyjna: stan informacji 8 września 2026. CVE-2026-73334 (parquet-hadoop 1.12–1.18.0, fix 1.18.1): file-controlled KMS URL może skierować KMS auth token na serwer atakującego; 1.18.1 wyłącza tę funkcję domyślnie. Artykuł koncentruje się na provenance konfiguracji i trust boundary destynacji tokenu.