Repozytorium nie powinno głosować nad swoim własnym zaufaniem

24 kwietnia 2026 r. Anthropic opublikował GHSA-q5hj-mxqh-vv77 — lukę obejścia dialogu zaufania Claude Code z oceną CVSS 7,7. Trzydzieści siedem dni wcześniej, 18 marca, ten sam projekt opublikował GHSA-mmgp-wc2j-qcv7 z identyczną oceną CVSS. Dwa obejścia dialogu zaufania w tym samym środowisku uruchomieniowym agenta w tym samym sześciotygodniowym okresie nie są przypadkiem.¹²

Wspólny kształt obu luk stanowi lekcję. W błędzie z marca plik .claude/settings.json kontrolowany przez projekt był odczytywany przed sprawdzeniem zaufania obszaru roboczego, a tryb uprawnień bypassPermissions w tym pliku w trywialny sposób przechodził kontrolę.² W błędzie z kwietnia złośliwe repozytorium dostarcza spreparowany plik commondir w katalogu .git/, ewaluator zaufania podąża za wskaźnikiem do katalogu, któremu użytkownik już zaufał, a obszar roboczy dziedziczy to zaufanie bez wyświetlenia dialogu.¹

Dwie linie tekstu wewnątrz repozytorium, którego nikt jeszcze nie otworzył, mogły zagłosować za uznaniem obszaru roboczego za zaufany. Powierzchnie na poziomie projektu, które repozytorium dostarcza (hooks, konfiguracje serwerów MCP, skills, subagents), mogą następnie zostać rozwiązane na podstawie tego głosu — czy to z wyprzedzeniem na początku sesji, czy z opóźnieniem przy wywołaniu. Mechanizmy obronne niższego rzędu w każdym środowisku uruchomieniowym agenta są uzależnione od decyzji, którą środowisko podejmuje, zanim te mechanizmy w ogóle zaistnieją.

TL;DR

• Dwie luki CVE dotyczące obejścia dialogu zaufania Claude Code w ciągu 37 dni pokazują, co się psuje, gdy bajty kontrolowane przez repozytorium wpływają na zaufanie obszaru roboczego.
• Bezpośrednia naprawa po stronie użytkownika polega na aktualizacji do wersji powyżej 2.1.84, zawężeniu zaufanych ścieżek w ~/.claude.json oraz unikaniu szerokiego zaufania do ścieżek nadrzędnych, takich jak ~/Projects.
• Strukturalna naprawa to niezmiennik kolejności ładowania: nie należy interpretować żadnego bajtu obszaru roboczego, dopóki ścieżka obszaru roboczego nie zostanie jawnie uznana za zaufaną.

Co właściwie naprawiały oba zalecenia bezpieczeństwa

Lektura łatek w zestawieniu z dokumentacją uwidacznia błąd kolejności ładowania. Naprawione wersje zmieniają porządek tego, jakie bajty wolno odczytać ewaluatorowi zaufania.

Zalecenie marcowe opisuje, jak Claude Code rozwiązuje ustawienia projektu przed rozwiązaniem zaufania obszaru roboczego. Naprawa w wersji 2.1.53 odwraca tę kolejność, dzięki czemu kontrola zaufania nie odczytuje już .claude/settings.json z wnętrza obszaru roboczego, zanim użytkownik podejmie decyzję.² Zalecenie kwietniowe opisuje, jak ewaluator zaufania podąża za plikiem commondir w katalogu .git/ repozytorium podczas rozwiązywania samej ścieżki obszaru roboczego. Naprawa w wersji 2.1.84 powstrzymuje ewaluator przed honorowaniem zawartości commondir kontrolowanej przez repozytorium podczas oceny zaufania.¹ Obie łatki przywracają ten sam niezmiennik: decyzja o zaufaniu nie może opierać się na bajtach znajdujących się wewnątrz kandydującego obszaru roboczego.

Klasyfikacje CVE wskazują na tę samą diagnozę. Marcowy błąd zarejestrowano jako CWE-807, Reliance on Untrusted Inputs in a Security Decision (Poleganie na niezaufanych danych wejściowych w decyzji bezpieczeństwa).³ Kwietniowy błąd zarejestrowano jako CWE-20 wraz z CWE-77, Improper Input Validation oraz Improper Neutralization of Special Elements, ponieważ rozwiązywanie commondir traktowało bajty kontrolowane przez repozytorium jako miarodajne.¹ Różne CWE, ale to samo błędne założenie: bramka bezpieczeństwa, która odczytuje z artefaktu, którego ma strzec.

Powierzchnia przed-zaufaniem jest szersza, niż sugeruje dokumentacja ustawień

Claude Code dokumentuje zestaw kontrolowanych przez projekt powierzchni inicjowanych przy starcie sesji, które muszą pozostać za bramką zaufania. Dwie luki CVE z tej klasy dowodzą, że niezmiennik się załamuje, gdy którakolwiek z nich wchodzi do samej decyzji o zaufaniu. Powierzchnie dzielą się na dwa zakresy, które analiza zaufania musi rozróżnić: bajty dostarczane wraz ze sklonowanym repozytorium oraz bajty, które użytkownik dodaje do obszaru roboczego lokalnie, bez ich commitowania.⁴⁵⁶⁷

Powierzchnie commitowane do repozytorium (dostarczane przez git clone). Stanowią one powierzchnię łańcucha dostaw. Wszystko z tej grupy jest tym, co kontroluje atakujący, gdy tworzy złośliwe repozytorium.

Powierzchnie lokalne dla obszaru roboczego (domyślnie niecommitowane). Te nie wjeżdżają do obszaru roboczego łańcuchem dostaw; pojawiają się, gdy lokalny użytkownik je tworzy. Mimo to nadal znajdują się wewnątrz ścieżki obszaru roboczego, więc bramka zaufania musi traktować je jako niezaufane, dopóki ścieżka nie zostanie zatwierdzona.

Hooks znajdują się wewnątrz .claude/settings.json, a nie w osobnym pliku; kwietniowe zalecenie opisuje, jak atakujący wypełnia ten klucz bezpośrednio.¹⁶ Kwietniowy błąd ujawnił także powierzchnię, która w ogóle nie należy do dokumentacji konfiguracji Claude Code: wewnętrzny dla gita plik o nazwie commondir, który rozwiązuje worktree z powrotem do swojego repozytorium nadrzędnego.⁸ Złośliwe repozytorium dostarczające spreparowany układ commondir dziedziczy zaufanie ścieżki docelowej, gdy Claude Code podąża za wskaźnikiem podczas oceny zaufania. Ta wewnętrzna dla gita powierzchnia zburzyła liczbę powierzchni konfiguracji projektu — i to jest właściwa lekcja. Taksonomia nie jest zamknięta. Powierzchnia ataku jest zdefiniowana przez to, jakie bajty zostają odczytane przed wyzwoleniem dialogu, a wszystko, co może wpłynąć na rozwiązywanie ścieżek lub konfigurację, wchodzi w grę.

Wzorzec to ten, który MCP Servers Are the New Attack Surface nazwał na innym poziomie.⁹ Serwery MCP wybuchowo rozszerzyły powierzchnię dostawcy narzędzi, zanim ekosystem nadążył z konsekwencjami. Obejście dialogu zaufania to ten sam kształt jedną warstwę niżej. Każda funkcja wygody, która pozwala repozytorium wstępnie skonfigurować agenta, dodaje wiersz do powyższej taksonomii. Każdy wiersz jest kandydatem na następną lukę CVE w tej klasie.

Tylna strona szafki: niezmiennik kolejności ładowania, a nie sprytniejszy dialog

Paul Jobs nauczył Steve’a, że spód szafki zasługuje na taką samą staranność jak warstwa wykończeniowa.¹⁰ Metafora szafki nie jest tu ozdobnikiem. Stanowi kręgosłup naprawy.

Dialog zaufania to tyłem szafki. Użytkownicy nie widzą kolejności ładowania. Widzą dialog, klikają „Zaufaj” i zakładają, że każdy bajt wewnątrz obszaru roboczego pozostaje bezczynny aż do tego kliknięcia. Implementacja musi to założenie zasłużyć. Kiedy tego nie robi, samo założenie staje się powierzchnią ataku.

Kolejność ładowania jest niezmiennikiem decydującym o tym, czy założenie zostało zasłużone. Minimalny model wynikający z obu zaleceń i publicznej dokumentacji ustawień Claude Code wygląda mniej więcej tak:²¹⁶

1. Odczyt ustawień użytkownika z ~/.claude/settings.json.
2. Odczyt ustawień użytkownika z ~/.claude/settings.local.json.
3. Ocena, czy bieżąca ścieżka obszaru roboczego jest zaufana.
4. Jeśli nie — wyświetlenie dialogu. Jeżeli użytkownik kliknie „Zaufaj” — utrwalenie ścieżki.
5. Odczyt .claude/settings.json o zasięgu projektu wewnątrz repozytorium.
6. Odczyt .claude/settings.local.json o zasięgu projektu.
7. Rozwiązanie hooks, serwerów MCP, skills i subagents na podstawie scalonych ustawień.
8. Uruchomienie hooków SessionStart.

Zalecenia nie dokumentują każdego kroku z osobna, a umiejscowienie skills, subagents i MCP względem scalania ustawień to szczegół implementacyjny niewidoczny dla użytkownika. Zalecenia ustanawiają natomiast granicę w kroku 3. Wszystko, co rozwiązywane jest przed krokiem 3, znajduje się w strefie zaufanych danych wejściowych. Wszystko, co rozwiązywane jest w kroku 3 lub później, nie może odczytywać bajtów obszaru roboczego. Marcowy błąd zamienił miejscami kroki 3 i 5: ustawienia projektu rozwiązywano jako pierwsze, a tryb uprawnień ustawiony przez te ustawienia (bypassPermissions) trywialnie spełniał kontrolę zaufania w kroku 3.² Kwietniowy błąd przeniósł atak do samego kroku 3: rozwiązywanie ścieżki obszaru roboczego korzystało z pliku commondir kontrolowanego przez repozytorium, a sfałszowanie sprawiało, że kontrola zaufania rozwiązywała się w stosunku do wybranej przez atakującego zaufanej ścieżki.¹ Tak czy inaczej, zanim nastąpi krok 7 lub 8, obszar roboczy jest już zaufany, a każda powierzchnia na poziomie projektu ładuje się na podstawie tego głosu.

Reguła, której domaga się tył szafki, mieści się w jednym zdaniu: nie należy interpretować żadnego bajtu wewnątrz obszaru roboczego, dopóki użytkownik jawnie nie zaufa ścieżce obszaru roboczego. Ani .claude/settings.json. Ani commondir. Ani CLAUDE.md. Ani listy nazw plików. Ani pliku hooka. Ani konfiguracji serwera MCP. Jeżeli coś znajduje się wewnątrz obszaru roboczego, kod decydujący o zaufaniu w to nie zagląda.

Visual Studio Code wprowadził tę naprawę w maju 2021 r. jako Workspace Trust (wydanie 1.57). Zasadnicza klasa zaufania do folderu od czasu wprowadzenia tej funkcji nie wygenerowała opublikowanego obejścia, choć powiązane kwestie dotyczące zaufanych domen i zachowania rozszerzeń wciąż się pojawiają.¹¹¹² Wersja 2.1.53, do której odsyła zalecenie marcowe, wprowadziła wersję niezmiennika dla Claude Code poprzez zmianę kolejności kroków 3 i 5.² Wersja 2.1.84, do której odsyła zalecenie kwietniowe, zrealizowała go poprzez odmowę podążania za plikami commondir kontrolowanymi przez repozytorium podczas oceny zaufania.¹ Obie łatki przywracają niezmiennik, zamiast wymyślać nowy mechanizm obronny.

The Steve Test wyciąga kolejną nić: czy Blake podpisałby się pod tym swoim nazwiskiem?¹³ Odpowiedź dla Claude Code w tym sześciotygodniowym oknie brzmi „nie”, ponieważ dostawca dwukrotnie podpisał, wydał i załatał obejścia tej klasy. To poprzeczka, którą dostawca musi naprawić. Minimum Worthy Product jest standardem, do którego odnosi się ten podpis.¹⁴ Minimum jest ograniczeniem zakresu, a nie zniżką jakości. Minimalnie wykonalny dialog zaufania to taki, który blokuje tani przypadek. Minimalnie godny dialog zaufania to pierwszy krok kolejności ładowania, która odmawia interpretowania jakiegokolwiek bajtu repozytorium, zanim użytkownik podejmie decyzję. Produktem, który wydaje się światu, są bajty, których odmawia się interpretować, dopóki nie pojawi się na to pozwolenie.

Trzy naprawy, których wymaga niezmiennik

Reguła to niezmiennik. Trzy wzorce wynikają z niej bezpośrednio.

Bramki jednokierunkowe. Kod ustanawiający zaufanie odczytuje wyłącznie ścieżkę, kliknięcie użytkownika oraz utrwalony stan zaufania poza obszarem roboczym w ~/.claude.json.¹⁵ Nic więcej. Każda refaktoryzacja, w której plik obszaru roboczego współtworzy decyzję o zaufaniu, jest regresją.

Brak zaufania przechodniego poprzez rozwiązywanie ścieżek. Preferowanym niezmiennikiem jest, by worktree, submoduły, pliki dołączane oraz cele dowiązań symbolicznych otrzymywały każde własny dialog. Visual Studio Code Workspace Trust dla odmiany pozwala, by zaufanie do folderu nadrzędnego rozszerzało się na podfoldery, i to właśnie ten wybór wykorzystuje szerokie zaufanie do ścieżek nadrzędnych w stylu ~/Projects, gdy rozwiązywanie ścieżek zostaje sfałszowane. Surowsza reguła kosztuje kilka dodatkowych dialogów i usuwa całą powierzchnię zaufania przechodniego; luźniejsza reguła utrzymuje niski poziom tarcia i akceptuje, że błędy rozwiązywania ścieżek stają się błędami rozwiązywania zaufania.¹¹

Adwersaryjne fixtury w teście regresji kolejności odczytu zaufania. Celowo spreparowane adwersaryjne repozytorium, które commituje pliki-kanarki obszaru roboczego. Test stwierdza, że żadna ścieżka kodu nie odczytuje tych kanarków przed potwierdzeniem dialogu. Jeśli przyszła zmiana w środowisku uruchomieniowym odczyta jakikolwiek plik-kanarka podczas oceny zaufania, build zawiedzie. CWE-501, Trust Boundary Violation, jest szerszą rodziną wartą śledzenia w taksonomii testów obok bardziej szczegółowych klasyfikacji CWE-807 oraz CWE-20/CWE-77, których już używają opublikowane zalecenia.¹⁶

Żadna z tych trzech naprawa nie jest kosztowna. Pierwsza to nieobecność kodu. Druga kosztuje tarcie widoczne dla użytkownika. Trzecia to jeden przebieg inżynierski plus dyscyplina dalej. Kompromitacja bootstrapu zaufania to kategoria, w której zwykła postawa defense in depth nie obowiązuje, ponieważ każda warstwa pochodząca z dołu od zaufania działa w oparciu o decyzję o zaufaniu, którą obszar roboczy właśnie pomógł podjąć. Obrona poza zaufaniem jest niemożliwa do zbudowania na warstwie szkieletu, ponieważ szkielet jest dokładnie tym, do czego obszar roboczy uzyskuje dostęp do odczytu, gdy zaufanie się rozstrzyga.

Niezmiennik musi wprowadzić dostawca. Luki CVE obejścia dialogu zaufania są sposobem, w jaki obserwatorzy mierzą, czy dostawca trzyma się poprzeczki. Dwie w sześć tygodni nie są szumem. Są sygnałem, że niezmiennik nie został zakodowany w pakiecie testów jako asercja egzekwowana przez build. Dopóki tak się nie stanie, kolejna luka CVE w tej klasie to tylko kwestia znalezienia dziesiątego wejścia.

Repozytorium nie powinno głosować nad swoim własnym zaufaniem. Zaufanie jest tą jedyną decyzją, w której podejmowaniu artefakt poddawany ocenie nie może uczestniczyć. Każda inna warstwa obrony agenta (hooks, skills, walidatory, detektory, strażnicy) żyje w dół od tego pojedynczego głosu. Gdy głos jest sfałszowany, praca w dół rzeki staje się meblem dekoracyjnym. Wykończenie szafki nie ratuje jej tyłu.

FAQ

Czym jest obejście dialogu zaufania Claude Code?

Obejście dialogu zaufania Claude Code ma miejsce, gdy niezaufany obszar roboczy zostaje potraktowany jako zaufany, zanim użytkownik jawnie go zatwierdzi. W luce CVE z marca 2026 r. ustawienia kontrolowane przez repozytorium wpłynęły na tryb uprawnień przed dokonaniem oceny zaufania. W luce CVE z kwietnia 2026 r. spreparowany układ git worktree/commondir spowodował, że zaufanie zostało rozwiązane przez ścieżkę już zaufaną.

Jak należy zawęzić zaufane ścieżki w ~/.claude.json?

Proszę otworzyć ~/.claude.json i zbadać mapę projects. Należy szukać wpisów, w których hasTrustDialogAccepted ma wartość true dla katalogów, które nie zawierają już aktywnego kodu, dla szerokich ścieżek nadrzędnych takich jak ~/Projects oraz dla wszelkich ścieżek pokrywających się z układami sąsiadującymi z worktree. Zaufanie per-repozytorium dodaje dialogi, ale zapobiega temu, by jedna zaakceptowana ścieżka nadrzędna w cichy sposób obejmowała każde dziecko.

Dlaczego zaufanie ścieżki nadrzędnej jest niebezpieczne dla Claude Code?

Zaufanie ścieżki nadrzędnej jest niebezpieczne, ponieważ jeden zaakceptowany katalog może obejmować wiele podrzędnych obszarów roboczych. Jeśli rozwiązywanie ścieżek zostanie sfałszowane lub złośliwy worktree wskaże z powrotem na ten katalog nadrzędny, repozytorium podrzędne może odziedziczyć zaufanie, którego mu nigdy nie udzielono. Zaufanie per-repozytorium dodaje tarcia, ale zapobiega zaufaniu przechodniemu między niepowiązanymi repozytoriami.

Jaki niezmiennik zapobiega obejściom dialogu zaufania?

Niezmiennik brzmi: nie należy interpretować żadnego bajtu wewnątrz obszaru roboczego, dopóki użytkownik jawnie nie zaufa ścieżce obszaru roboczego. Kod zaufania może odczytywać ścieżkę, kliknięcie użytkownika oraz utrwalony stan zaufania poza repozytorium. Nie powinien odczytywać .claude/settings.json, CLAUDE.md, .mcp.json, hooks, skills, commondir ani żadnego pliku kontrolowanego przez repozytorium przed wyświetleniem dialogu.

Bibliografia