CVE-2026-63087: krytyczna luka Grafana OnCall

CVE-2026-63087 w Grafana OnCall OSS otrzymała ocenę krytyczną. Według rekordu NVD dla CVE-2026-63087 nieuwierzytelniony atakujący może uzyskać prawidłowy PluginAuthToken przez wewnętrzny mechanizm instalacji wtyczki. Token daje dostęp do wewnętrznego API, a opis podatności wskazuje możliwość utworzenia konta administratora, unieważnienia prawidłowego tokenu wtyczki i zmiany konfiguracji organizacji.

To poważny scenariusz przejęcia warstwy zarządzania incydentami, ale wymaga precyzyjnej komunikacji. Na moment aktualizacji tego tekstu 17 lipca 2026 roku metadane CISA-ADP nie potwierdzają wykorzystania luki w atakach. W rekordzie widnieje exploitation: none, przy jednoczesnym automatable: yes i technicalImpact: total. Krytyczność techniczna nie jest więc dowodem aktywnej kampanii. Jest natomiast wystarczającym powodem, aby natychmiast ustalić, czy organizacja nadal utrzymuje Grafana OnCall OSS i czy jego interfejsy są osiągalne z niezaufanej sieci.

Najważniejsze fakty o CVE-2026-63087

Pole	Potwierdzona informacja
Produkt	Grafana OnCall OSS
Podatne wersje	do 1.16.11 włącznie według rekordu CVE
Klasa błędu	CWE-306 — brak uwierzytelnienia dla funkcji krytycznej
Wektor	zdalny, bez wcześniejszego uwierzytelnienia
CVSS	9,3 w CVSS 4.0 oraz 9,8 w CVSS 3.1 według danych CNA
Możliwy skutek	prawidłowy token wtyczki, konto administratora i zmiana zaufanej konfiguracji
Potwierdzone ataki	brak potwierdzenia w metadanych CISA-ADP na 17 lipca 2026
Stan projektu	Grafana OnCall OSS został zarchiwizowany 24 marca 2026

Źródłem opisu technicznego jest rekord CVE przygotowany przez CNA VulnCheck oraz analiza VulnCheck. NVD oznacza rekord jako oczekujący na pełne wzbogacenie, dlatego wnioski należy ograniczyć do danych, które są już opublikowane. Nie należy dopisywać niepotwierdzonego łańcucha ataku, IOC ani rzekomej aktywnej eksploatacji.

Dlaczego ten błąd jest tak groźny

Sednem problemu nie jest pojedynczy formularz ani zwykły wyciek informacji. To naruszenie granicy zaufania między Grafaną a silnikiem OnCall. Publicznie dostępny kod zawierał domyślne wartości identyfikatorów stack_id i org_id. Mechanizm instalacji wtyczki miał na tej podstawie wydawać prawidłowy token, mimo że żądający nie przeszedł właściwego uwierzytelnienia.

CWE-306 opisuje właśnie brak uwierzytelnienia przy funkcji, która wykonuje operację o znaczeniu bezpieczeństwa. Jeżeli endpoint tworzący albo przekazujący poświadczenie przyjmuje żądanie od anonimowego klienta, późniejsze kontrole autoryzacji niewiele pomagają: atakujący wchodzi do systemu z tokenem uznawanym za zaufany.

Według opisu CVE pozyskany PluginAuthToken może zostać wykorzystany do wywołania wewnętrznego API. Mechanizm inicjalizacji kontekstu użytkownika pozwala następnie utworzyć dowolnego administratora. Dodatkowo możliwe jest unieważnienie prawidłowego tokenu wtyczki oraz nadpisanie pól grafana_url i api_token organizacji. Ostatni element jest szczególnie istotny: zmiana docelowego adresu może skierować komunikację OnCall z Grafaną do infrastruktury kontrolowanej przez przeciwnika.

To łańcuch o potencjalnie pełnym wpływie na poufność, integralność i dostępność. Konto administratora daje trwały punkt kontroli. Zmiana tokenu może zakłócić prawidłową integrację i utrudnić reakcję. Przekierowanie ruchu może wystawić dane przesyłane przez zaufany komponent. Z tego powodu sama kontrola wersji nie wystarcza — potrzebne są również przegląd konfiguracji, kont i ruchu wychodzącego.

Kogo dotyczy ryzyko

Opis CVE dotyczy samodzielnie utrzymywanego Grafana OnCall OSS, a nie automatycznie każdej usługi Grafana Cloud. Najpierw trzeba potwierdzić produkt, wariant wdrożenia i wersję. Organizacje często mają starsze instancje poza główną CMDB: laboratorium, środowisko odzyskiwania awaryjnego, kopię po migracji albo instalację utrzymywaną przez pojedynczy zespół SRE.

Wyszukiwanie powinno objąć:

repozytoria IaC, pliki Compose, manifesty Kubernetes i obrazy kontenerów;
DNS, reverse proxy, load balancery i reguły WAF;
sekrety o nazwach związanych z OnCall, Grafaną i tokenem wtyczki;
rejestry usług, CMDB i platformy obserwowalności;
kopie zapasowe, klastry zapasowe i nieużywane środowiska testowe;
publiczne oraz partnerskie zakresy adresowe wykryte w procesie External Attack Surface Management.

Nie ograniczaj inwentaryzacji do hostów dostępnych bezpośrednio z Internetu. Podatny endpoint może być osiągalny przez VPN, sieć partnerską, wspólny ingress Kubernetes albo przejętą stację administratora. Ekspozycja jest właściwością całej ścieżki dostępu, nie tylko flagą „publiczny/prywatny” w arkuszu.

Ważny kontekst: projekt jest zarchiwizowany

Oficjalna dokumentacja Grafana OnCall OSS podaje, że projekt wszedł w tryb utrzymania 11 marca 2025 roku, a 24 marca 2026 został w pełni zarchiwizowany. Repozytorium jest tylko do odczytu, a aktywny rozwój przeniesiono do Grafana Cloud IRM. Zakończono również obsługę Cloud Connection dla instalacji OSS.

Ten fakt zmienia sposób zarządzania ryzykiem. Rekord CVE wymienia wersje do 1.16.11 włącznie, ale nie wskazuje wprost dostępnej, wspieranej wersji naprawczej. Nie wolno zakładać, że zwykłe pull latest rozwiąże problem. Administrator powinien sprawdzić oficjalne kanały producenta, a jeśli poprawka nie została udostępniona, zastosować izolację i zaplanować migrację lub wycofanie systemu.

Zarchiwizowane oprogramowanie może nadal działać poprawnie funkcjonalnie. Nie oznacza to jednak, że jego przyszłe podatności będą obsługiwane w przewidywalnym cyklu. W procesie zarządzania podatnościami stan wsparcia produktu powinien być osobnym czynnikiem priorytetyzacji, obok CVSS, ekspozycji i wartości chronionych zasobów.

Plan działania na pierwsze cztery godziny

1. Potwierdź wersję i ścieżki dostępu

Zidentyfikuj wszystkie instancje i odczytaj wersję z działającego artefaktu, nie tylko z deklaracji w repozytorium. Zapisz, jakie proxy, ingressy, tunele i sieci umożliwiają dojście do silnika OnCall. Ustal właściciela biznesowego oraz technicznego każdej instancji.

2. Ogranicz osiągalność bez destrukcyjnego testu

Jeśli nie możesz natychmiast potwierdzić bezpieczeństwa, ogranicz dostęp do zaufanych segmentów administracyjnych albo tymczasowo wyłącz publiczną publikację. Nie testuj produkcji payloadem wykorzystującym lukę. Taki test może utworzyć konto, zmienić token lub konfigurację, a więc sam stać się incydentem.

3. Zabezpiecz dane dowodowe

Przed restartem i rotacją sekretów zachowaj logi aplikacyjne, logi reverse proxy/WAF, zdarzenia platformy kontenerowej, historię zmian sekretów, listę użytkowników i konfigurację organizacji. Synchronizuj znaczniki czasu. Jeżeli retencja jest krótka, wyeksportuj dane do odseparowanego magazynu.

4. Uruchom analizę kompromitacji

Sprawdź, czy wystąpiły anonimowe żądania do mechanizmu instalacji wtyczki, niespodziewane operacje inicjalizacji kontekstu użytkownika, utworzenie administratora, unieważnienie albo zmiana tokenu, modyfikacja grafana_url lub api_token oraz połączenia wychodzące do nieznanych hostów. To hipotezy detekcyjne wynikające z opisu CVE, a nie opublikowane uniwersalne IOC.

5. Rotuj poświadczenia we właściwej kolejności

Jeśli pojawia się podejrzenie nadużycia, najpierw odetnij nieautoryzowany dostęp i zabezpiecz dowody, potem usuń nieznane konta oraz rotuj PluginAuthToken, tokeny API Grafany i inne sekrety dostępne dla komponentu. Rotacja bez zamknięcia podatnej ścieżki może tylko wydać atakującemu kolejne poświadczenie.

Co monitorować w logach i konfiguracji

Nie ma jednej sygnatury, która rozstrzygnie sprawę. Zbuduj korelację kilku zdarzeń:

żądanie do wewnętrznej funkcji instalacji wtyczki z adresu, użytkownika lub agenta, który nigdy nie wykonuje administracji;
utworzenie nowego użytkownika z rolą administratora bez odpowiadającego zgłoszenia i operacji IAM;
zmiana lub unieważnienie tokenu wtyczki poza oknem serwisowym;
modyfikacja docelowego grafana_url albo wartości api_token;
nowy kierunek ruchu wychodzącego z OnCall, zwłaszcza przez publiczny DNS lub nietypowy ASN;
błędy integracji, nagły brak alertów i ponowne próby uwierzytelnienia po zmianie tokenu;
zmiany sekretów w Kubernetes, Dockerze lub systemie Vault bez działania zatwierdzonego pipeline’u.

Zespół korzystający z SIEM powinien zachować surowe pola żądania i odpowiedzi, identyfikator instancji, źródłowy adres IP, tożsamość workloadu oraz znacznik czasu. Porównanie możliwości opisujemy szerzej w materiale SIEM, XDR czy EDR — co naprawdę wykryje incydent. Dla tej luki najcenniejsze są logi aplikacyjne, proxy i kontrola zmian, nie wyłącznie telemetria z hosta.

Mitigacja, naprawa i migracja to trzy różne rzeczy

Mitigacja ogranicza prawdopodobieństwo wykorzystania, na przykład przez allowlistę, segmentację albo wyłączenie publicznego routingu. Naprawa usuwa błąd w kodzie lub wdraża oficjalnie poprawioną wersję. Migracja usuwa zależność od zarchiwizowanego produktu. Te działania mogą działać równolegle, ale nie wolno raportować pierwszego jako zakończenia pozostałych.

Jeśli producent opublikuje poprawkę, wdrożenie powinno objąć każdy węzeł, a walidacja — kontrolę rzeczywistej wersji obrazu i test legalnej integracji Grafana–OnCall. Jeśli wspierana poprawka nie jest dostępna, najbardziej defensywną decyzją jest izolacja usługi, ograniczenie funkcji i przyspieszenie migracji. Wyjątek bezpieczeństwa musi mieć właściciela, termin oraz mierzalny warunek zamknięcia.

W praktyce warto połączyć ten incydent z priorytetyzacją krytycznych podatności, segmentacją sieci wewnętrznej oraz ćwiczeniem tabletop reagowania na incydenty. CVSS mówi o potencjale technicznym. Dopiero ekspozycja, stan wsparcia, dane w systemie i dostępność telemetrii określają rzeczywiste ryzyko organizacji.

Czego dziś nie wiemy

Odpowiedzialna analiza powinna zawierać granice wiedzy. Na 17 lipca 2026 roku publiczny rekord nie potwierdza aktywnej eksploatacji, nie podaje uniwersalnych IOC i nie przedstawia jednoznacznej wspieranej wersji naprawczej. Dane mogą zostać uzupełnione. Dlatego zespoły powinny śledzić NVD, kanały Grafana i CNA, a każdą zmianę statusu przenieść do własnej oceny ryzyka.

Brak potwierdzonych ataków nie jest argumentem za czekaniem. Przy zdalnej, nieuwierzytelnionej i automatyzowalnej ścieżce do uprawnień administratora czas ekspozycji ma znaczenie. Jednocześnie nie należy publikować alarmistycznej informacji o „trwającej kampanii”, dopóki źródła jej nie potwierdzą.

Jak raportować status bez tworzenia fałszywej pewności

W komunikacie dla zarządu rozdziel cztery pola: podatność techniczną, ekspozycję konkretnej instancji, dowody potencjalnego nadużycia oraz status naprawy. „Nie znaleźliśmy IOC” nie znaczy „nie było włamania”, jeśli logi obejmują tylko ostatnie 24 godziny albo nie rejestrują zmian administratorów. Z kolei obecność podatnej wersji nie dowodzi kompromitacji.

Dobry raport zapisuje źródło i czas każdego wniosku. Przykład: „NVD wymienia wersje do 1.16.11; instancja była dostępna z sieci VPN; zachowano 30 dni logów proxy; nie stwierdzono nowych administratorów; ruch wychodzący jest nadal analizowany; publiczny dostęp ograniczono o 14:20”. Taka forma umożliwia aktualizację oceny bez przepisywania całej historii incydentu i pokazuje, które wnioski są faktami, a które pozostają hipotezami.

Nie oznaczaj zadania jako zamknięte po samej zmianie reguły firewall. Zamknięcie powinno wymagać potwierdzonej wersji lub wycofania usługi, zakończonego przeglądu okresu ekspozycji, rotacji poświadczeń tam, gdzie była potrzebna, oraz zachowanych dowodów walidacji.

Decyzja dla właściciela systemu

Jeśli nie używasz Grafana OnCall OSS, udokumentuj wynik wyszukiwania i zamknij zadanie. Jeśli używasz wersji do 1.16.11, ogranicz osiągalność, zabezpiecz telemetrię, przeprowadź analizę kont oraz konfiguracji i sprawdź oficjalną ścieżkę aktualizacji. Jeżeli system jest zarchiwizowany i nie ma wspieranej poprawki, wyznacz termin migracji lub wycofania.

Potrzebujesz niezależnie sprawdzić ekspozycję legacy observability, API i paneli administracyjnych? Umów test penetracyjny z BreachRoad — zakres obejmie bezpieczną walidację konfiguracji, ścieżek dostępu, sekretów oraz gotowości detekcyjnej, bez uruchamiania destrukcyjnego PoC na produkcji.