LangSmith z krytyczną podatnością – jak jeden parametr mógł zagrażać bezpieczeństwu

Jedno kliknięcie. Tyle miało dzielić wygodny podgląd logów od pełnego przejęcia konta w narzędziu do debugowania aplikacji AI. Brzmi jak phishing z 2010 roku? Niestety, to 2026 i błąd w samym sercu platformy LangSmith.

Badacze z Miggo Security namierzyli w LangSmith krytyczną podatność (CVE-2026-25750), w której elastyczność konfiguracji stała się wektorem przejęcia aktywnej sesji użytkownika. Wina leżała po stronie parametru baseURL – banalnego z wyglądu, kluczowego w skutkach. Błąd załatano w wersji 0.12.71, a dostawca nie odnotował realnych nadużyć. Warto jednak zobaczyć, jak jedna „ułatwka” może obejść zabezpieczenia.

LangSmith to nie kolejny gadżet dla programisty. To centrum operacyjne: testy, debugowanie, telemetria dla aplikacji LLM, często w architekturach RAG. W jednym miejscu lądują prompty z logiką biznesową, dane użytkowników i klucze do zewnętrznych usług – wszystko, co dla atakującego oznacza wysokie ryzyko przejęcia. Producent podkreśla, że traktuje platformę jak infrastrukturę krytyczną. Tym bardziej ciekawi, jak prozaiczny parametr konfiguracyjny mógł stać się wektorem ataku.

O co chodziło z tym baseURL

Idea była sensowna. Interfejs LangSmith hostuje dostawca, ale backend API można wskazać lokalny – np. pod localhost. Dzięki temu nie trzeba stawiać całego UI u siebie, a i tak łączysz się z własnym środowiskiem. Parametr baseURL miał dawać tę wygodę.

Problem? Brak właściwej walidacji tego adresu. Według opisu badaczy, wystarczyło podmienić baseURL tak, by ruch API poleciał na serwer kontrolowany przez atakującego. Kto kontroluje backend, ten widzi i wpływa na to, co widzi użytkownik. W praktyce oznaczało to możliwość przejęcia aktywnej sesji – klasyczny Account Takeover, tylko że przez „ustawienie” z intencją inną niż bezpieczeństwo. Co gorsza, dało się to zainicjować jednym kliknięciem w odpowiednio spreparowany link. [1]

Dlaczego to istotne – i nie tylko dla LangSmith

Platformy do tworzenia i obserwowania aplikacji AI łączą wiele zaufanych elementów: interfejs, zaplecze, źródła danych, integracje. Granice zaufania bywają rozmyte, a „elastyczne” funkcje administracyjne często lądują w przeglądarce. Ta mieszanka sprzyja błędom projektowym: od niedowalidowanych przekierowań po nieintencjonalne separacje kontekstu. Spójrzmy szerzej: niedawna podatność GeminiJack w środowisku Google Gemini Enterprise pokazała, że prompt injection w RAG potrafi wykonać ukryte instrukcje bez żadnego kliku użytkownika. Wspólny mianownik? Granice systemu zawodzą tam, gdzie wygoda i złożoność wygrywają z rygorem walidacji. [3]

Fakty, bez ściemy

• Luka CVE-2026-25750 dotyczyła parametru baseURL w LangSmith i pozwalała przekierować ruch API na serwer atakującego, co prowadziło do przejęcia aktywnej sesji. [1]
• Atak dało się zainicjować jednym kliknięciem w link modyfikującym konfigurację.
• Badacze z Miggo Security zgłosili problem; producent załatał go w wersji 0.12.71.
• Dostawca nie zaobserwował wykorzystania błędu w realnych atakach.
• Stawka była wysoka: w LangSmith trafiają prompty, dane zapytań, integracje i klucze.

Co tu naprawdę poszło nie tak

To nie jest „wyrafinowany łańcuch exploitów”. To klasyka: zaufanie do wejścia użytkownika w krytycznej ścieżce i brak twardych ograniczeń po stronie aplikacji. Jeśli przeglądarka może rozmawiać z dowolnym adresem wskazanym w parametrach UI, to prędzej czy później porozmawia z adresem, który wybierze ktoś inny. Elastyczność bez barier to nie funkcja – to obietnica kłopotów.

Jak powinno to wyglądać?

Minimum to biała lista dozwolonych hostów, powiązanie sesji z autoryzowanym backendem (tak, by zmiana celu zrywała zaufanie) i pinning środowisk. Dobrą praktyką jest też ograniczenie tego typu przełączników do strefy serwerowej, z audytem zmian i bez możliwości modyfikacji przez link w przeglądarce. Na froncie – jednoznaczne komunikaty o kontekście sesji i brak „magicznego” przełączania torów ruchu w tle.

Czy LangChain odrobił lekcję

Patch jest, wersja z numerkiem 0.12.71 zamyka lukę. W szerszym planie widać, że dostawca inwestuje w twardszą izolację komponentów. Kierunek jest właściwy: ograniczać zaufanie do elementów składowych, ciasno izolować wykonanie, a konfigurację krytyczną trzymać z dala od przeglądarki.

Puenta bez fajerwerków

Ta historia jest nudna w najlepszym tego słowa znaczeniu. Żadnych czarnych sztuk, tylko jeden parametr, który nie dostał należnego mu szacunku. W erze narzędzi AI „dev” to już „prod”: trzyma tajemnice i steruje zachowaniem całych systemów. Jeśli w Twoim stacku są podobne „ułatwki”, warto zapytać: czy naprawdę muszą być w przeglądarce – i czy na pewno ufają tylko tym, którym powinny?

FAQ

Czy podatność CVE-2026-25750 w LangSmith została już załatana?

Tak. Podatność została usunięta w wersji LangSmith 0.12.71.

Czy doszło do realnych ataków wykorzystujących CVE-2026-25750?

Nie. Dostawca nie zaobserwował wykorzystania podatności w rzeczywistych atakach.

Jak mogło dojść do przejęcia konta w LangSmith przez baseURL?

Przejęcie było możliwe przez brak walidacji parametru baseURL, który pozwalał przekierować ruch API na serwer atakującego, co skutkowało przejęciem aktywnej sesji. [3]

Czy muszę coś zrobić jako użytkownik LangSmith?

Tak. Zaktualizuj LangSmith do wersji 0.12.71 lub nowszej i unikaj linków zmieniających konfigurację środowiska z poziomu przeglądarki. [1]

Dlaczego ten błąd był tak niebezpieczny dla zespołów AI?

Bo LangSmith gromadzi prompty, dane i klucze integracji; przejęcie sesji to dostęp do najbardziej wrażliwych elementów procesu tworzenia aplikacji LLM.

Źródła

• [1] https://sekurak.pl/jak-manipulacja-parametrem-zadania-mogla-doprowadzic-do-przejecia-konta-w-langsmith-szczegoly-podatnosci-cve-2026-25750/
• [2] https://mexc.co/en-PH/news/948789
• [3] https://sekurak.pl/geminijack-atak-typu-prompt-injection-i-0-click-w-rozwiazaniu-ai-gemini-enterprise/