DSPy CVE-2026-72742: odpowiedź modelu może wykraść lokalne pliki

11 sierpnia 2026 roku opublikowano CVE-2026-72742 w DSPy, frameworku do programowania systemów wykorzystujących modele językowe. Podatność pokazuje nietypowy, ale bardzo ważny wariant prompt injection: model nie musi bezpośrednio odczytać pliku narzędziem. Wystarczy, że jego odpowiedź zostanie zinterpretowana jako obiekt Image lub Audio z polem wskazującym lokalną ścieżkę. Kod frameworka sprawdzał, czy taki plik istnieje, odczytywał go i kodował do base64, a zawartość mogła trafić w kolejnym promptcie do kontrolowanego przez napastnika endpointu modelu.

Rekord obejmuje DSPy do wersji 3.3.0b1 i ocenia problem na 9,2 w CVSS 4.0 oraz 8,6 w CVSS 3.1. Kluczowym warunkiem jest wpływ napastnika na odpowiedź modelu oraz przepływ, w którym wynik zostaje sparsowany do typu multimedialnego i ponownie użyty. To nie jest automatyczny odczyt wszystkich plików w każdej aplikacji DSPy. Jest to jednak złamanie bardzo ważnej granicy: walidacja danych wyjściowych zaczyna wykonywać operacje I/O na hoście.

Łańcuch od tekstu do pliku

DSPy umożliwia definiowanie typowanych sygnatur wejścia i wyjścia. Adapter, na przykład JSONAdapter lub ChatAdapter, prosi model o strukturę i następnie konwertuje wartości do oczekiwanego typu. Sam pomysł jest dobry: typy ograniczają chaos tekstu i ułatwiają budowę modułów. Problem powstaje, gdy konstruktor typu ma skutki uboczne.

W podatnej ścieżce odpowiedź przechodziła przez parse_value i Pydantic TypeAdapter. Utworzenie obiektu multimedialnego wywoływało kod rozpoznający wartość jako ścieżkę. Funkcje kodujące obraz lub audio używały os.path.isfile, odczytywały bajty i tworzyły reprezentację data URL. Jeżeli później obiekt stawał się częścią zapytania do modelu, lokalny plik opuszczał host.

Napastnik potrzebuje więc kontroli nad co najmniej jednym modelem lub jego odpowiedzią. Może to być zewnętrzny endpoint LLM, złośliwy pośrednik, zatruty kontekst wpływający na wyjście albo model, któremu aplikacja zbyt szeroko ufa. Potencjalnymi celami są pliki konfiguracyjne, klucze dostępne dla konta procesu, dane robocze i sekrety zamontowane do kontenera. Zakres odczytu ograniczają systemowe uprawnienia procesu — dlatego ich minimalizacja jest realną kontrolą.

Dlaczego zwykła walidacja typu nie wystarcza

Zespół może oczekiwać, że typowanie Pydantic tylko sprawdzi składnię. Jeśli jednak konstrukcja obiektu wykonuje odczyt pliku lub żądanie sieciowe, dane modelu sterują zachowaniem hosta. To odpowiednik deserializacji z efektami ubocznymi. Granica „model generuje tekst, aplikacja decyduje o działaniach” staje się pozorna.

Bezpieczniejsza zasada brzmi: parsowanie i zwykła konstrukcja wartości powinny być czyste. Mogą normalizować tekst, sprawdzać format i tworzyć strukturę w pamięci, ale nie powinny otwierać plików, pobierać URL ani uruchamiać procesów. I/O wymaga jawnego wywołania przez kod aplikacji, po sprawdzeniu polityki oraz pochodzenia argumentu.

Commit naprawiający CVE-2026-72742 wprowadza właśnie taki model. Zwykłe tworzenie Image, Audio i File nie wykonuje automatycznego I/O. Programista używa jawnych fabryk, na przykład Image.from_path() lub Audio.from_path(), gdy naprawdę chce odczytać lokalny zasób. Oddzielne from_url() sygnalizuje operację sieciową.

Uwaga: jawne from_url nadal wymaga polityki

Jawność usuwa niebezpieczny automatyzm, ale nie rozwiązuje każdego SSRF. Dokumentacja poprawki zaznacza, że from_url() samo nie narzuca allowlisty i może podążać za przekierowaniami. Jeśli aplikacja przekazuje do tej funkcji URL wygenerowany przez model, musi niezależnie sprawdzić schemat, host, adres po rozwiązaniu DNS, przekierowania i zakresy sieci prywatnej.

Weryfikację należy wykonać przed każdym połączeniem oraz po przekierowaniu, aby nie dopuścić do zmiany z publicznego hosta na adres wewnętrzny. W środowisku chmurowym blokada egress powinna uniemożliwiać dostęp do metadanych instancji i sieci zarządzającej. Walidacja aplikacyjna i zapora wyjściowa uzupełniają się.

Podobnie from_path() powinno przyjmować ścieżkę wybraną przez zaufany kod, nie surowe pole z modelu. Jeśli produkt celowo pozwala modelowi wskazywać zasoby, zamiast dowolnej ścieżki należy użyć nieprzewidywalnego identyfikatora mapowanego po stronie serwera do pliku w jednym katalogu. Po kanonikalizacji wynik musi pozostawać pod dozwolonym korzeniem.

Co powinien zrobić zespół

1. Znajdź projekty i obrazy zawierające DSPy, również eksperymenty, notebooki oraz usługi oceniające wyniki modeli.
2. Sprawdź wersję działającą i ustal, czy kod parsuje wyjścia do Image, Audio lub File oraz ponownie przekazuje je do modelu.
3. Przejdź na wydanie zawierające commit naprawczy i przetestuj migrację do jawnych fabryk zasobów.
4. Przeszukaj własny kod pod kątem automatycznego wywołania from_path() lub from_url() na danych pochodzących z modelu.
5. Uruchamiaj workflow modelowy jako konto bez dostępu do sekretów i plików, których zadanie nie potrzebuje. Ogranicz mounty tylko do odczytu lub usuń je całkowicie.
6. Ogranicz egress do zatwierdzonych endpointów LLM przez kontrolowany proxy i rejestruj docelowy host, model oraz wolumen danych.
7. Jeżeli podatny przepływ działał z niezaufanym modelem, przeanalizuj żądania wychodzące i rotuj sekrety, których odczyt jest wiarygodny.

Rotacja nie powinna być automatycznym, chaotycznym działaniem dla całej firmy. Najpierw ustal prawa procesu: użytkownika systemowego, mounty kontenera, zmienne środowiskowe, katalog roboczy i tokeny agenta. Następnie określ, które dane mogły przejść przez funkcje multimedialne i do jakiego endpointu wysyłano prompty. To daje obronną, audytowalną listę.

Jak wykrywać podobną klasę błędów

W przeglądzie kodu wyszukuj konstruktory, walidatory Pydantic, deserializatory i konwertery, które wywołują open, klienta HTTP, resolver DNS, subprocess albo import dynamiczny. Takie operacje nie zawsze są błędem, ale wymagają wyraźnej granicy zaufania. Szczególnie ryzykowne są miejsca, gdzie źródłem wartości jest LLM, webhook, plik użytkownika lub inny tenant.

Test bezpieczeństwa może podać fikcyjną ścieżkę do pliku testowego i potwierdzić, że samo parsowanie nie powoduje odczytu ani ruchu sieciowego. Można instrumentować funkcje I/O i traktować każde ich wywołanie podczas walidacji jako niepowodzenie. To test właściwości architektury, a nie podpis jednego exploita.

W telemetrii szukaj nagłych dużych pól base64 w promptach, typów multimedialnych nieoczekiwanych dla danego workflow, odczytów wrażliwych plików przez worker AI i połączeń do nowych dostawców modeli. Rejestruj metadane i skróty, ale nie kopiuj sekretów do logów. DLP na kontrolowanym proxy może wykrywać wzorce, lecz nie powinien być jedyną ochroną.

Lekcja dla bezpiecznych agentów AI

Model jest źródłem niezaufanych danych nawet wtedy, gdy został wybrany przez organizację. Może halucynować, zostać zmanipulowany przez prompt injection albo działać za endpointem, którego integralność się zmieniła. Typowany output poprawia niezawodność, ale nie nadaje treści zaufania. Każda operacja zewnętrzna potrzebuje osobnej autoryzacji opartej na polityce aplikacji.

Fakty o ścieżce parsowania, wersjach i zmianie API pochodzą z rekordu CVE oraz commitu projektu. Źródła nie potwierdzają masowej kampanii. Wnioskiem Breachroad jest szersza zasada czystej deserializacji i jawnych efektów ubocznych.

To materiał, który warto omawiać wspólnie z deweloperami, zespołem AI i SOC, ponieważ żaden z tych zespołów sam nie widzi całego przepływu. Szkolenia z bezpieczeństwa AI i cyberbezpieczeństwa pomagają przełożyć model zagrożeń na kod i monitoring. Architekturę agentów, uprawnienia i przepływy danych można następnie uporządkować w ramach bezpiecznych wdrożeń AI.