Strona główna / Blog / OpenClaw: node.invoke omija scope

Blog · case study

OpenClaw CVE-2026-100588: node.invoke omija admin scope

Bezpośrednia ścieżka browser control w OpenClaw wymaga admin scope, ale alternatywne node.invoke przed 2026.7.1 nie egzekwowało równoważnej kontroli. Write-scoped caller mógł więc dotrzeć do browser-capable node bez admin scope. To klasyczny przypadek autoryzacji przypisanej do endpointu zamiast do capability.

CVE-2026-100588 (OpenClaw, < 2026.7.1): write-scoped caller → node.invoke → browser-capable node → browser control bez admin scope.
Affectedness: najistotniejsze w deploymentach z rozróżnionymi caller identities/scopes; shared-secret operator model ma inne trust assumption.

Attack path

write-scoped caller -> node.invoke -> browser-capable node -> browser control without admin scope

Affectedness

Problem jest najistotniejszy w deploymentach z rozróżnionymi caller identities/scopes — tam różnica między write scope a admin scope realnie coś znaczy. Shared-secret operator model (jeden sekret dla wszystkiego) może mieć inne trust assumption i inny profil ryzyka.

Verification

Po 2026.7.1 odtwórz próbę non-admin node.invoke, sprawdź odmowę oraz inne alternate paths do browser capability. Przejrzyj historię wywołań non-admin — bo skoro istniała jedna ścieżka obejścia, warto sprawdzić, czy nie było więcej.

Powiązane na blogu

Źródło

  • OpenClaw Security Advisory GHSA-jghr-xp78-995p — github.com

Nota redakcyjna: stan informacji 27 września 2026. CVE-2026-100588 (OpenClaw, node.invoke omija admin scope, fix 2026.7.1). Affectedness zależy od modelu tożsamości/scope w deploymencie.

Zapamiętaj jedno

Autoryzacja musi być właściwością capability, a nie pojedynczego endpointu. Jeśli jedna ścieżka do browser control wymaga admin scope, to każda alternatywna droga do tej samej capability musi wymagać tego samego — inaczej scope jest fikcją.