CVE-2026-86439 / GHSA-9gfj-28hw-jchp dotyczy Knowns (narzędzie z MCP docs i memory). Wersje ≤ 0.29.1 nie zapewniają containment validation dla ścieżek: filepath.Join() składa base directory z user-controlled path, ale po normalizacji nie sprawdza, czy wynik nadal jest pod project root. Fix w 0.30.0. Najciekawsze jest jednak drugie odkrycie: model capabilities też można ominąć.
docs.get path="../../../victim/secret" → poza project root; ta sama klasa w Get/Create/Update/Rename/Delete i MemoryStore.docs.update(path, newPath) robi rename = zapis + os.Remove(oldPath), ale w registry to CapWrite, nie CapDelete — user z read-write-no-delete i tak kasuje.Capability powinno opisywać efekt, nie nazwę API
Typowy model: update = write, delete = delete. Ale realny efekt update obejmuje delete, rename, move, overwrite. Jeśli capability mapping jest oparty na nazwie akcji, a nie jej side effects, policy jest semantycznie fałszywa — dla agent tools szczególnie, bo MCP prezentuje LLM-owi wysokopoziomowe verbs.
Impact ograniczają OS permissions, nie „sandbox”
Sandbox istniał tylko jako założenie o ścieżce — właśnie go omijamy. Impact traversal jest ograniczony OS permissions procesu. Na developer workstation / agent server proces ma dostęp do repozytoriów, .env, SSH keys, cloud/CI credentials, konfiguracji innych agentów — path traversal z MCP zmienia się w supply-chain entry point (overwrite CI config/script consumed by another agent → later trusted execution). Nie nazywaj tego RCE bez dowodu konkretnego downstream execution. Compounding: przy auth-bypass/serwerze bez hasła MCP tools bywają dostępne bez credentials — rozdziel affectedness traversal od authentication state.
Remediacja i dwie własności weryfikacji
Upgrade do 0.30.0 (containment validation). Dodatkowo: wymagaj auth dla MCP, binduj do wymaganych interfejsów, uruchamiaj z minimalnymi OS permissions, nie montuj zbędnych sekretów. WAF blokujący literalne ../ jest słaby (encoding, separatory, normalization) — lepszy control jest przy sinku (resolved path musi zostać w approved base dir). Weryfikacja to dwie własności: (1) filesystem containment (testy negatywne dla get/create/update/delete/memory z traversal), (2) capability semantics (read-write-no-delete nie może usunąć pliku przez docs.update).
Wniosek
Knowns pokazuje dwa typowe problemy agent infrastructure: sandbox istnieje tylko jako założenie o ścieżce, a capability tylko jako etykieta przypisana do wysokopoziomowej akcji. Standard dla MCP: sprawdzaj security property na efekcie końcowym, nie na nazwie verb-a.
Powiązane na blogu
- Skyvern: drugi render bez sandboxa — control ginie między etapami
- Buildah: build-context breakout — granica po stronie efektu, nie nazwy
Źródła
- Knowns — advisory GHSA-9gfj-28hw-jchp — github.com/knowns-dev
- GitHub Advisory Database — CVE-2026-86439 / GHSA-qjrq-cvv4-3g9w — github.com/advisories
Nota redakcyjna: stan informacji 9 września 2026. CVE-2026-86439 (Knowns MCP ≤0.29.1, fix 0.30.0): path traversal (brak containment) oraz docs.update kasujący mimo profilu read-write-no-delete. Artykuł koncentruje się na tym, że capability musi opisywać efekt, a impact ograniczają OS permissions procesu.