Google Agent Mesh (SAM): dwa obejścia autoryzacji narzędzi MCP, dwie linie poprawek i moduł Go, którego nie znajdzie żaden skaner

19 października 2026 Google opublikował dwa rekordy CVE dla Google OSS Agent Mesh (SAM), sieci, w której agenci AI wywołują narzędzia MCP, usługi A2A i punkty inferencji na innych węzłach. Oba mają CVSS 4.0 9.3 i oba dotyczą tego samego: kto może wywołać narzędzie na cudzym węźle. Nie są nowe. Advisory producenta pochodzą z 4 i 6 września, a poprawki z sierpnia i września. Nowe jest to, że teraz trafią do rejestrów podatności. Dla VM ważne są trzy rzeczy: wersja naprawiająca pierwsze CVE nie naprawia drugiego, rekordy wskazują nazwę modułu Go, której projekt już nie używa, a sama aktualizacja nie odbiera dostępu, który ktoś mógł zdobyć wcześniej.

Dwie luki, dwie linie poprawek

CVE-2026-102503 to problem parzystości ścieżek. Węzeł udostępnia te same usługi backendowe dwiema drogami libp2p. Strumień MCP przechodzi przez WithBiscuitAuth i Authorize, które sprawdzają uprawnienia z tokenu Biscuit. Równoległy serwer /libp2p-http trafiał do tych samych handlerów bez żadnej kontroli. Według GHSA w podatnych wersjach węzeł domyślnie nasłuchiwał na wszystkich interfejsach i ogłaszał się w publicznej sieci DHT, więc był osiągalny z internetu. Jak duży jest skutek, zależy od tego, co węzeł udostępnia: dla usług MCP opartych na procesie (stdio) to wywołanie dowolnego narzędzia tego procesu, a przy usługach URL-backed węzeł staje się nieuwierzytelnionym proxy do sieci wewnętrznej. To nie jest bezwarunkowe RCE na każdej instalacji, ale zgłaszający słusznie zauważa, że sufitem jest wykonanie kodu. Ten sam wzorzec, w którym druga ścieżka nie dziedziczy polityki pierwszej, opisywałem przy rclone i Open WebUI.

CVE-2026-103091 nie wymaga żadnego błędu w kodzie autoryzacji. Autoryzacja działa, tylko domyślna polityka wszystko przepuszcza. Każdy, kto ma ważny token od dostawcy OIDC skonfigurowanego w sieci, mógł się sam zarejestrować jako węzeł. Według GHSA klient OIDC był publiczny, a SAM nie filtrował claimów e-mail, domeny ani grup. Rola sam:system:authenticated była powiązana z allowed_services: ["*"] i allowed_targets: ["*"]. GHSA wskazuje też dwa szczegóły ważne po incydencie: bany opierały się na peer_id, który wynika z lokalnej pary kluczy (wystarczy wygenerować nową), a jedna rejestracja dawała poświadczenie ważne 90 dni, choć token OIDC wygasał po godzinie. Domyślne konfiguracje, które same w sobie są podatnością, opisywałem przy platformach agentów z narzędziem shell.

Skutek dla skanerów: instalacja na alpha.3–alpha.8 wypadnie z zakresu pierwszego CVE i dalej będzie w zakresie drugiego. Jeśli ktoś zamknął w zeszłym miesiącu „SAM” jednym ticketem po aktualizacji do alpha.3, ma otwartą lukę 9.3. Dwa CVE muszą być dwoma findingami z osobnymi kryteriami zamknięcia.

Dwie skale, jedna ocena

GHSA podaje 9.8 w CVSS 3.1, rekordy CVE 9.3 w CVSS 4.0. To nie jest rozjazd ocen, tylko dwie różne skale. Nie uśredniaj ich i nie traktuj 9.8 jako „wyższej”. Ciekawszy jest wektor: CNA ustawił SC:N/SI:N/SA:N, czyli brak wpływu na systemy zależne. Tymczasem cały sens tych luk to wywoływanie narzędzi, które działają na innych systemach: bazach danych, chmurze, hostach. Zgłaszający CVE-2026-102503 argumentował wprost za zmianą zakresu (S:C). Przy ocenie środowiskowej dla Twojej instalacji to właśnie metryki systemów zależnych powinny odzwierciedlić, do czego podłączone są narzędzia MCP.

Dlaczego skaner tego nie znajdzie

To najważniejszy praktyczny wniosek. Sprawdziłem, co widzą źródła, z których korzystają narzędzia SCA:

W efekcie żadne z typowych narzędzi SCA nie powiąże tych CVE z kodem, ani pod starą, ani pod nową nazwą modułu. To ten sam problem jakości danych, który opisywałem przy 12 CVE dla MCP i przy argocd-mcp, z dodatkową komplikacją w postaci zmiany nazwy. Kiedy rekordy zostaną uzupełnione albo GHSA trafią do globalnej bazy, i tak warto pamiętać, że SBOM sprzed 14 października opisze tę samą aplikację jako github.com/google/sam, a nowszy jako github.com/google/agentmesh. Inwentarz powinien łączyć obie nazwy w jeden komponent.

Uspokajające jest jedno: podatne są tylko wczesne wersje alpha. Wydania od alpha.9 wzwyż, w tym rc i v0.1.x, są poza zakresem obu rekordów. Ryzyko dotyczy więc głównie wdrożeń testowych, demonstracyjnych i proof-of-concept z lata 2026, których nikt nie aktualizował. A to dokładnie te instalacje, o których inwentarz zwykle nie wie.

Aktualizacja to nie remediacja

Po CVE-2026-103091 nie wystarczy podnieść wersji. Według rekordu alpha.9 wprowadza politykę domyślnie odmawiającą, wymaga jawnego powiązania polityki przy rejestracji i sprawdza bany. Ze źródeł nie wynika jednak:

• czy aktualizacja unieważnia poświadczenia sieci wydane wcześniej w trybie otwartej rejestracji. Przy 90-dniowej ważności poświadczenie z sierpnia mogło być ważne jeszcze w listopadzie. Niepotwierdzone, więc zakładaj, że nie;
• czy wdrożenie, które ma jawnie wpisane powiązanie sam:system:authenticated z wildcardem (np. skopiowane z przykładowej konfiguracji starszej wersji), po aktualizacji przestaje być permisywne. Zmiana wartości domyślnej nie zmienia wartości jawnie ustawionych. To moje wnioskowanie, nie stwierdzenie producenta.

Kryterium zamknięcia CVE-2026-103091 to więc trzy rzeczy: wersja ≥ alpha.9, polityka bez wildcardów dla roli uwierzytelnionej oraz przegląd i odwołanie zarejestrowanych węzłów, których nikt nie rozpoznaje. Podobnie jak przy Airflow, gdzie poprawka OAuth nie zamknęła całej ścieżki, warto też sprawdzić, kogo przepuszcza konfiguracja OIDC: jakich odbiorców, domen i grup.

Co powinien zrobić VE

1. Znajdź wdrożenia SAM / Agent Mesh poza SCA: obrazy i binaria sam-node i płaszczyzny sterowania, repozytoria z zależnością od github.com/google/sam lub github.com/google/agentmesh, środowiska testowe i demonstracyjne. Wersję bierz z działającego artefaktu.
2. Otwórz dwa findingi. CVE-2026-102503 dla < alpha.3, CVE-2026-103091 dla < alpha.9. Celem dla obu jest bieżące wydanie (v0.1.1 na 22.10.2026), nie minimum z rekordu.
3. Ogranicz osiągalność węzłów libp2p i płaszczyzny sterowania (w tym /info i /register) do zaufanych segmentów, a w wersjach podatnych wyłącz udział w publicznej sieci DHT. To kontrola kompensująca, nie poprawka.
4. Przejrzyj tożsamość i politykę: filtry claimów OIDC, odbiorców tokenów, powiązania polityk dla sam:system:authenticated i listę zarejestrowanych węzłów. Usuń wildcardy i odwołaj węzły, których nie rozpoznajesz.
5. Ogranicz narzędzia MCP podłączone do sieci: bez narzędzi destrukcyjnych i powłoki dostępnych dla wszystkich, bez sekretów produkcyjnych w środowiskach testowych. Od tego zależy, czy obejście autoryzacji to wyciek danych, czy wykonanie kodu.
6. Przeanalizuj historię wywołań narzędzi i rejestracji od sierpnia 2026: nieznane peery, rejestracje z nieoczekiwanych tożsamości, wywołania wrażliwych narzędzi. Jeśli logów nie ma, nie deklaruj braku incydentu. Przy podejrzeniu rotuj sekrety dostępne dla narzędzi MCP.
7. Zweryfikuj poprawkę w kontrolowanym środowisku: odmowa na obu ścieżkach dla peera bez uprawnień, odmowa rejestracji niedozwolonej tożsamości, kontrola polityk. Monitoruj KEV, SSVC i to, czy GHSA trafią do globalnej bazy.

Powiązane na blogu

• 12 CVE dla MCP w mniej niż 9 sekund — automatyzacja CVE i jakość danych
• argocd-mcp — wysoka pewność podatności, niska machine-actionability
• DB-GPT, Langchain-Chatchat, Letta, piflow — domyślna konfiguracja jako podatność
• Knowns MCP — model uprawnień narzędzi a realne efekty
• rclone auth-proxy — trzy protokoły, trzy bypassy
• Open WebUI CVE-2026-88006 — drugi punkt wejścia bez polityki

Źródła

• CVE.org — CVE-2026-102503 (CNA Google, CVSS 4.0 9.3, CWE-306, CWE-862, alpha.1 do <alpha.3, SSVC CISA) — cve.org
• CVE.org — CVE-2026-103091 (CNA Google, CVSS 4.0 9.3, CWE-862, CWE-1188, alpha.1 do <alpha.9, SSVC CISA) — cve.org
• Google — GHSA-r6hp-67wp-c7jx „Authorization bypass via unauthenticated /libp2p-http ingress” (04.09.2026) — github.com
• Google — GHSA-cgmg-9xf6-rrgw „Insecure default policy and unrestricted enrollment” (06.09.2026) — github.com
• Google — wydania Agent Mesh (alpha.3, alpha.9, v0.1.0, v0.1.1) — github.com
• NVD — CVE-2026-102503 (Awaiting Analysis) — nvd.nist.gov
• OSV — CVE-2026-103091 (zakresy GIT, bez pakietu Go) — osv.dev
• Go vulnerability database — pkg.go.dev
• CISA Known Exploited Vulnerabilities Catalog (brak obu CVE w wersji 2026.10.21) — cisa.gov

Nota redakcyjna: wpis powstał na podstawie szkicu VMRT Radar z 19.10.2026 i został zweryfikowany ze źródłami pierwotnymi 20 października 2026 (ok. 19:10 CEST): rekordy CVE.org obu CVE (CNA Google, CVSS 4.0, CWE, zakresy, pakiet, zgłaszający, SSVC CISA), NVD API 2.0, advisory GHSA w repozytorium producenta przez API GitHub (daty, CVSS 3.1, zakresy, opis) i globalna baza GitHub (brak wpisów), lista wydań, pliki go.mod w tagach od alpha.3 do v0.1.1, proxy.golang.org, indeks Go vulnerability database, OSV i EPSS. 22 października 2026 (ok. 22:40 CEST) ponownie sprawdziłem katalog CISA KEV (wersja 2026.10.21: brak obu CVE), EPSS i listę wydań (bez zmian). Względem szkicu dodałem daty wydań poprawek (alpha.3 była dostępna miesiąc przed GHSA), SSVC CISA exploitation: poc, zmianę ścieżki modułu Go od v0.1.0-rc.10, brak pokrycia w bazach SCA i ryzyko poświadczeń wydanych przed aktualizacją. Szkic wskazywał katalog KEV 2026.10.16 bez potwierdzenia nowszego. Nie potwierdziłem: czy aktualizacja unieważnia wcześniej wydane poświadczenia sieci, czy jawnie ustawione wildcardy pozostają aktywne po aktualizacji, ile istnieje wdrożeń, ani czy luki były wykorzystywane poza laboratorium. Interpretacja metryk systemów zależnych, kryteria zamknięcia i podział na findingi to oceny autora.