Strona główna / Blog / APITable: fail-open authorization

Blog · case study

APITable: permission guard rzuca wyjątek, więc request przechodzi. Kiedy błąd w systemie autoryzacji oznacza „allow” zamiast „deny”

CVE-2026-86120 dotyczy NodePermissionGuard w Fusion API projektu APITable. Użytkownik z ważnym Fusion API tokenem może zapisywać załączniki do prywatnych datasheetów, do których został jawnie pozbawiony dostępu. Mechanizm jest szczególnie pouczający: kiedy permission lookup rzuca wyjątek, guard nie wymusza odmowy — zachowuje się fail-open.

CVE-2026-86120 (Moderate 5.3): wyjątek w permission lookup → request kontynuowany zamiast odrzucony; zapis załączników do datasheetów bez uprawnień.
Affected: APITable do 1.13.0-beta.1.
oczekiwany model: security uncertainty → deny podatny model: permission backend error → request continues

Dlaczego to więcej niż „Moderate 5.3”

Score nie oddaje wartości case study: problem ujawnia fundamentalnie błędną semantykę bezpieczeństwa. To sprawia też, że zwykły test user without permission → 403 nie wystarcza — bo w normalnym przebiegu guard działa. Podatność ujawnia się dopiero na ścieżce błędu: timeout DB, wyjątek cache, brak obiektu permission, 5xx z downstream service.

Affectedness zależy od użycia Fusion API

Z perspektywy VM affectedness zależy od tego, czy organizacja używa Fusion API i czy istnieje możliwość wejścia w konkretny exception path. VE powinien to potwierdzić testem, a nie zakładać — a weryfikacja remediacji musi obejmować symulację błędów zależności, nie tylko happy path.

Variant analysis pozostałych guardów

Po takim CVE warto objąć variant analysis inne guardy i middleware i odpowiedzieć na jedno pytanie: czy każdy error path kończy się odmową? Fail-open bywa wzorcem powtarzalnym w bazie kodu — jeśli jeden guard łapie wyjątek i przepuszcza, prawdopodobnie robią tak i inne.

Wniosek

CVE-2026-86120 to modelowy fail-open: kontrola bezpieczeństwa, która w razie własnego błędu domyślnie przepuszcza. Dla VE lekcja jest przenośna — testuj autoryzację również wtedy, gdy jej zależności zawodzą, i traktuj „security uncertainty → deny” jako niepodlegające negocjacji.

Powiązane na blogu

Źródła

Nota redakcyjna: stan informacji 7 września 2026. CVE-2026-86120 (APITable Fusion API NodePermissionGuard, ≤ 1.13.0-beta.1): wyjątek w permission lookup powoduje fail-open. Artykuł koncentruje się na testowaniu autoryzacji na ścieżkach błędów i na variant analysis pozostałych guardów.

Zapamiętaj jedno

Zwykły test „user without permission → 403” nie wystarcza. Weryfikacja autoryzacji powinna obejmować też błędy zależności: timeout DB, wyjątek cache, brak obiektu permission czy 5xx z downstream. Po takim CVE variant analysis powinno objąć wszystkie guardy i sprawdzić, czy każdy error path kończy się odmową.