CVE-2026-14199 dotyczy wyłącznie self-managed Grafana używającej Auth Proxy authentication wraz z identity caching (sync_ttl > 0). Problem wynika z konstrukcji klucza cache: username oraz przekazywane atrybuty tożsamości były konkatenowane bez jednoznacznego separatora. Dwie różne tożsamości mogły więc wygenerować ten sam klucz cache. Uwierzytelniony użytkownik, który potrafił ukształtować własne forwarded attributes tak, aby kolidowały z cache entry użytkownika uprzywilejowanego, mógł zostać rozpoznany jako ten użytkownik — nawet jako Administrator. CVSS 3.1: 7.1 High.
sync_ttl > 0) + możliwość kształtowania forwarded attributes.Dlaczego to świetny przypadek dla VE?
Scanner wersji odpowie tylko „czy wersja Grafany jest w affected range?”. Ale realna exploitable state wymaga: self-managed? Auth Proxy enabled? identity caching enabled? sync_ttl > 0? attacker can influence forwarded identity attributes? privileged identity currently cached? Brak któregokolwiek z kluczowych warunków może usunąć attack path. I nie wystarczy pole authentication = enabled — vulnerability istnieje wewnątrz mechanizmu uwierzytelnienia i zależy od jego implementacji oraz cache.
Dlaczego cache key jest security boundary?
Klucz cache działa jak skrót tożsamości. Jeżeli dwie semantycznie różne tożsamości mogą zostać odwzorowane na tę samą reprezentację, cache przestaje być tylko optymalizacją wydajnościową — staje się elementem authorization path. Lekcja architektoniczna: jeżeli cache przechowuje decyzję bezpieczeństwa, sposób budowania jego klucza jest częścią modelu kontroli dostępu.
Mitigation i configuration drift
Jeżeli organizacja nie może od razu aktualizować, wyłączenie identity caching (sync_ttl = 0) usuwa warunek podatności — dobry machine-verifiable compensating control. Ale to nie to samo co usunięcie podatnego kodu, więc status to Mitigated / Not exploitable while condition holds, nie Fixed. A ponieważ administrator może jutro włączyć caching, evidence powinno mieć trigger:
Permanentne false positive byłoby niebezpieczne.
CVSS 7.1 a realny impact; jakość danych
CVSS uwzględnia Attack Complexity High i PR:L (attacker musi skonstruować kolizję i trafić w moment, gdy odpowiedni cache entry istnieje), ale skutkiem mogą być uprawnienia Administratora. Lokalny priorytet zależy od sposobu generowania forwarded attributes, tego kto kontroluje upstream proxy, długości sync_ttl, liczby administratorów i ekspozycji Grafany. Uwaga na dane: GitHub Advisory pokazuje Affected/Patched: Unknown, mimo że rekord CVE ma konkretne zakresy — warto zachowywać dane z kilku źródeł.
Wniosek
CVE-2026-14199 to niemal modelowy przykład configuration-aware VM. Nie wystarczy „Grafana + CVE” — trzeba wiedzieć „Grafana + Auth Proxy + identity cache + sync_ttl + identity attributes + runtime cache state". To właśnie różnica między prostym vulnerability scanningiem a Vulnerability Engineering.
Powiązane na blogu
- Keycloak: CVE tylko przy niebezpiecznej konfiguracji — configuration-aware VM i conditional VEX
- „Upgrade: websocket” wyłącza uwierzytelnianie — kontrola zależna od konfiguracji/inputu
Źródła
- Grafana — vendor advisory CVE-2026-14199 (02.09.2026) — grafana.com
- GitHub Advisory — GHSA-9758-8g25-vw94 — github.com/advisories
Nota redakcyjna: stan informacji 3 września 2026. CVE-2026-14199 (Grafana, CVSS 7.1) dotyczy self-managed z Auth Proxy i identity caching (sync_ttl>0); kolizja klucza cache umożliwia uwierzytelnienie jako inny użytkownik. Artykuł koncentruje się na configuration-aware affectedness i cache key jako authorization boundary.