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.
node.invoke → browser-capable node → browser control bez admin scope.Attack path
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
- OpenClaw: non-owner approval — autoryzacja vs uwierzytelnienie
- FrontMCP: incomplete fix — alternatywna ścieżka wokół kontroli
Ź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.