CVE-2026-81658 dotyczy historycznych rewizji template'ów w Foremanie. Uwierzytelniony użytkownik z niskimi uprawnieniami związanymi z template'ami może podać audit ID i uzyskać historyczną treść template'u należącego do innej organizacji lub location. Red Hat podkreśla kluczowy szczegół: REST API revision endpoints nie są affected — korzystają z authorization-aware scope. Podatna jest ścieżka obsługi rewizji przez UI.
API test może dać fałszywe poczucie bezpieczeństwa
Scanner może sprawdzić API (GET revision innej organizacji → 403) i uznać object-level authorization za poprawne. Tymczasem równoważny zasób dostępny ścieżką UI może korzystać z innego lookupu: security property tested on interface A ≠ security property guaranteed on interface B. To klasyczny false-negative pattern dla DAST i testów autoryzacji.
Historyczne dane nadal są aktywem
Template revision może zawierać stare credentiale, tokeny, konfigurację lub informacje o infrastrukturze. Usunięcie sekretu z aktualnej wersji nie usuwa go z historii — po wykryciu potencjalnego cross-tenant disclosure remediation może wymagać nie tylko patcha, ale też oceny, czy historyczne sekrety nadal są ważne i czy wymagają rotacji.
Jak weryfikować poprawkę i szersza lekcja
Trzeba testować właściwy attack path: konto w organizacji A, minimalne wymagane permission, audit ID template'u z organizacji B, ścieżka UI revision, oczekiwana odmowa. Test REST API nie potwierdza poprawki, bo REST API nie było podatne. Po takim CVE warto zrobić variant analysis: czy inne historyczne obiekty (templates, parameters, provisioning configs, audits, revisions) oraz wszystkie ścieżki UI/API używają authorization-aware scope? Priorytet zależy od liczby userów z odpowiednim permission, ekspozycji Foremana i wagi danych w template'ach.
Wniosek
Foreman pokazuje, że affectedness może zależeć od interfejsu prowadzącego do tego samego zasobu. Patch zamyka przyszły dostęp, ale nie cofa dostępu, który mógł nastąpić wcześniej — przy historycznych sekretach VE powinien rozważyć również credential rotation. Pytanie brzmi nie „czy API jest bezpieczne?”, lecz: czy każda ścieżka do tego zasobu jest bezpieczna?
Powiązane na blogu
- PikiwiDB: auth tylko na jednej ścieżce — kontrola na jednym protokole, nie wszystkich
- Upgrade: websocket wyłącza uwierzytelnianie — jedna ścieżka omija kontrolę
Źródła
- Red Hat — CVE-2026-81658 (27.08.2026) — access.redhat.com
- CVE.org — CVE-2026-81658 — cve.org
Nota redakcyjna: stan informacji 1 września 2026. CVE-2026-81658 (Foreman): historyczne rewizje template'ów dostępne cross-tenant przez UI (audit ID); REST API revision endpoints (authorization-aware scope) nie są affected. Artykuł koncentruje się na affectedness zależnej od interfejsu i scanner coverage.