Strona główna / Blog / OpenShift ACM: 9.9 vs EPSS

Blog · case study

CVSS 9.9, EPSS około 0,3%: OpenShift ACM pokazuje, dlaczego severity i exploit probability odpowiadają na inne pytania

CVE-2026-66792 w multicloud-operators-subscription, używanym przez Red Hat Advanced Cluster Management for Kubernetes, ma CVSS 3.1 9.9 Critical. Użytkownik posiadający odpowiedni dostęp na managed cluster może utworzyć Subscription ze spreparowanymi annotations i doprowadzić do operacji wykonywanych z uprawnieniami Service Account kontrolera. Skutkiem może być wdrażanie zasobów w dowolnych namespace'ach i eskalacja do cluster-admin. Jednocześnie GitHub Advisory Database pokazuje EPSS około 0,303%. To nie jest sprzeczność.

CVE-2026-66792: annotations Subscription → operacje z uprawnieniami SA kontrolera → cluster-admin.
CVSS 3.1: 9.9 Critical.
EPSS: ~0,303%.
Mitigation: Red Hat nie wskazuje mitigation spełniającego jego standardowe kryteria.

CVSS i EPSS odpowiadają na inne pytania

CVSS mówi: jak poważna jest podatność technicznie, jeżeli warunki ataku zostaną spełnione? EPSS mówi: jak prawdopodobne jest wykorzystanie CVE w najbliższym okresie według modelu statystycznego? Możemy więc mieć CVSS 9.9 i EPSS 0.3% jednocześnie — i obie wartości mogą być prawidłowe.

Dlaczego globalne prawdopodobieństwo może być niskie?

Attack path nie jest typowym unauthenticated Internet RCE. Atakujący musi już mieć możliwość działania na managed cluster i tworzenia odpowiednio spreparowanych Subscription. To ogranicza globalną populację potencjalnych attackerów. Ale dla konkretnej organizacji precondition może być łatwe do spełnienia — jeżeli managed clusters są współdzielone między zespołami, tenantami lub CI/CD service accounts, lokalna probability może być zupełnie inna niż globalny EPSS.

Global probability kontra local probability

VE powinien sprawdzić:

Who can create Subscription? How many identities? Are managed clusters multi-tenant? Can CI accounts create these resources? Are annotations restricted? What privileges has controller Service Account?

Dopiero te dane pozwalają ocenić realny attack path.

Brak prostego mitigation zwiększa znaczenie problemu

Red Hat nie wskazuje mitigation spełniającego jego standardowe kryteria. To ważne: nawet przy niskim EPSS organizacja może nie mieć wygodnej kontroli tymczasowej. Wtedy decyzja może sprowadzać się do patch/upgrade, redukcji uprawnień, izolacji albo formalnego i krótkoterminowego risk acceptance.

Nie mnożyć bezmyślnie CVSS przez EPSS

Część modeli priorytetyzacji próbuje wyprodukować jedną liczbę. To bywa wygodne, ale zaciera znaczenie danych. Lepszy model:

Impact: Critical Global threat likelihood: Low Local precondition: ... Exposure: ... Remediation availability: ... Asset criticality: ...

EPSS nie powinno automatycznie „zbić” CVSS 9.9 do niskiego priorytetu, jeśli lokalne warunki są korzystne dla atakującego.

Wniosek

CVE-2026-66792 świetnie pokazuje, że CVSS i EPSS nie konkurują ze sobą. Jedno mówi o potencjalnym skutku, drugie o statystycznym prawdopodobieństwie wykorzystania. Prawdziwa praca VE polega na połączeniu obu z lokalnymi uprawnieniami, tenancy i rzeczywistą możliwością stworzenia podatnego obiektu.

Powiązane na blogu

Źródła

Nota redakcyjna: stan informacji 1 września 2026. CVE-2026-66792 (CVSS 3.1 9.9) w multicloud-operators-subscription (RHACM) pozwala przez spreparowane annotations Subscription wykonać operacje z uprawnieniami SA kontrolera i eskalować do cluster-admin; GitHub Advisory pokazuje EPSS ~0,303%. Artykuł koncentruje się na rozróżnieniu CVSS i EPSS oraz global vs local probability.

Zapamiętaj jedno

CVSS i EPSS nie konkurują — jedno mówi o potencjalnym skutku, drugie o statystycznym prawdopodobieństwie wykorzystania. EPSS nie powinno automatycznie zbijać CVSS 9.9 do niskiego priorytetu, jeśli lokalne warunki (tenancy, uprawnienia, CI accounts) sprzyjają atakującemu.