CVE-2026-82882 ma CVSS 8.8 (v3.1) / 8.7 (v4.0) i Privileges Required: Low — na pierwszy rzut oka typowa podatność wymagająca konta. Ale realny attack path jest ciekawszy. Devtron do wersji 2.2.0 nie wykonuje właściwego authorization check na GET /orchestrator/api-token/webhook. Dowolny authenticated user może zapytać endpoint z arbitralnymi parametrami (project, environment, application) i otrzymać plaintext super-admin JWT. Czyli PR:L opisuje wejście, nie końcowy poziom władzy.
/orchestrator/api-token/webhook → plaintext super-admin JWT.low-privileged account → admin token disclosure → full platform control.Missing authorization, nie authentication bypass
Attacker musi mieć konto — authentication działa. Problemem jest CWE-862: endpoint nie sprawdza, czy użytkownik ma prawo pobrać token o takim zakresie. authenticated nie znaczy authorized.
Plaintext super-admin JWT jest credentialem, nie informacją
Jeżeli token trafi do attackera, nie musi on dalej exploitować endpointu — może po prostu użyć tokenu jako nowej tożsamości: User A → vulnerable endpoint → super-admin JWT → authenticate as super-admin → platform operations. To credential-mediated privilege escalation. Dlatego klasyczne „information disclosure” bywa mylące, gdy ujawnianą informacją jest credential: impact przechodzi confidentiality loss → impersonation → integrity control → potentially availability impact.
Devtron to control plane
Devtron to platforma DevOps/Kubernetes, nie zwykły CRUD. Full platform control może oznaczać wpływ na aplikacje, deploymenty, environments, pipeline configuration, secrets dostępne platformie i underlying Kubernetes workflows. Asset context mocno zwiększa blast radius — w środowisku, gdzie Devtron steruje produkcją i jest wielu self-service users, environmental priority bywa P1, mimo CVSS 8.8 (High). A PR:L bywa łatwe: developer account, contractor, project member, skompromitowana sesja SSO.
Patch to nie koniec — token rotation jest osobną remediation
Jeżeli attacker pobrał JWT, patch endpoint nie unieważnia automatycznie już wydanego tokenu. Potrzebne może być: endpoint fix + token revocation + session invalidation + audit. Do czasu jednoznacznej fixed version (publiczny CVE/GHSA jej nie podaje — nie należy jej zgadywać) można ograniczyć endpoint na reverse proxy/API gateway, ograniczyć dostęp sieciowy do Devtron API, monitorować wywołania /orchestrator/api-token/webhook i ograniczyć tworzenie kont.
Nie zamykaj na podstawie package mappera
GHSA może mieć Affected versions: Unknown, ale CVE CNA ma ≤ 2.2.0 affected. Jeśli scanner nie mapuje tego poprawnie, VE może potrzebować manual detection — podobny problem machine-actionability jak w argocd-mcp.
Wniosek
PR:L nie oznacza „attacker already has almost everything” — może oznaczać „attacker has the weakest account required to ask the wrong endpoint”. A endpoint może zwrócić credential dający pełną władzę. Dlatego risk model powinien śledzić privilege transition, nie tylko privilege prerequisite: jeśli wycieka super-admin JWT, finding staje się praktycznie platform takeover path.
Powiązane na blogu
- CVSS 10.0, ale „Affected: Unknown” — machine-actionability i działanie z advisory
- Ograniczone ssm:SendCommand, a plik jako root — privilege transition ponad prerequisite
Źródła
- GitHub Advisory — GHSA-mrqp-7v92-wchj / CVE-2026-82882 — github.com/advisories
- VulnCheck — Devtron missing authorization via webhook API token endpoint — vulncheck.com
- CVE.org — CVE-2026-82882 — cve.org
Nota redakcyjna: stan informacji 2 września 2026. Publiczny rekord CVE podaje affected Devtron ≤ 2.2.0, ale nie publikuje jednoznacznej patched version. Artykuł nie wymyśla fixed release; rekomenduje weryfikację aktualnego vendor guidance i traktuje token revocation jako osobny krok po potencjalnej ekspozycji.