CVE-2026-50180
WysokieCVSS 8.7Prawdopodobieństwo exploitacji (EPSS)
Niskie ryzykoPercentyl 48 - wyżej niż 48% wszystkich znanych CVE
Streszczenie
W bibliotece Langroid w wersji przed 0.64.0, komponent SQLChatAgent zawiera niedoskonałą warstwę zabezpieczeń _validate_query, która nie blokuje wszystkich niebezpiecznych funkcji SQL. Lista blokująca pomija m.in. funkcje PostgreSQL do odczytu plików (pg_read_file, pg_stat_file) oraz konstrukcje SQL Server i SQLite, co umożliwia atakującemu odczyt plików z hosta bazy danych.
Ocena ryzyka
Atakujący może wykorzystać podatność do odczytu wrażliwych plików systemowych z serwera PostgreSQL, nawet przy domyślnej restrykcyjnej konfiguracji agenta (tylko SELECT). Może to prowadzić do wycieku danych, takich jak hasła, konfiguracje czy klucze prywatne.
Rekomendacja
Należy natychmiast zaktualizować bibliotekę Langroid do wersji 0.64.0 lub nowszej, która zawiera poprawkę. Dodatkowo warto rozważyć dodatkowe mechanizmy walidacji zapytań SQL po stronie aplikacji.
Inne podatności w Langroid
Zobacz wszystkie- CVE-2026-55615Krytyczne
Langroid przed wersją 0.65.5 zawiera podatność w komponencie Neo4jChatAgent, która pozwala na wstrzykiwanie zapytań Cypher. Atakujący może wpłynąć na treść zapytania poprzez prompt injection, co umożliwia odczytanie lub zniszczenie wszystkich danych grafu, a przy włączonych procedurach APOC lub dbms.security – uzyskanie dostępu do systemu plików i wykonanie poleceń OS.
- CVE-2026-54769Krytyczne
Langroid w wersjach przed 0.65.2 zawiera krytyczną podatność umożliwiającą ucieczkę z sandboksa i zdalne wykonanie kodu (RCE) w komponentach `TableChatAgent` i `VectorStore`. Podczas ewaluacji komunikatów narzędziowych generowanych przez LLM z parametrem `full_eval=True`, funkcja `eval()` nie usuwa `__builtins__` z globalnego słownika, co pozwala na dostęp do funkcji systemowych, takich jak `__import__('os').system()`. Atakujący może wykorzystać tę lukę, dostarczając spreparowany prompt, aby uzyskać nieuwierzytelnione RCE na hoście.
- CVE-2026-54760Krytyczne
W frameworku Langroid do wersji 0.65.1 wykryto podatność na iniekcję SQL w komponencie `SQLChatAgent`. Mimo domyślnego wyłączenia niebezpiecznych operacji, mechanizm ochronny oparty na liście blokowanych wzorców regex i liście dozwolonych zapytań SELECT może zostać ominięty przez specjalnie skonstruowane zapytania PostgreSQL, co umożliwia odczyt plików serwera.
- CVE-2026-25879Krytyczne
Langroid SQLChatAgent przed wersją 0.63.0 wykonuje zapytania SQL generowane przez model językowy, które mogą być manipulowane przez wstrzyknięcie promptu. Atakujący może wymusić wykonanie niebezpiecznych operacji, takich jak COPY ... FROM PROGRAM, prowadząc do zdalnego wykonania kodu na hoście bazy danych.
- CVE-2026-54771Wysokie
Podatność w frameworku Langroid przed wersją 0.65.3 umożliwia bezpośrednie wywoływanie narzędzi przez niezaufanych użytkowników za pomocą surowych ładunków JSON, nawet gdy narzędzia są zarejestrowane z flagami `use=False, handle=True`.
- CVE-2026-50181Wysokie
W frameworku Langroid narzędzia ReadFileTool i WriteFileTool nie weryfikują, czy ścieżka pliku pozostaje w granicach katalogu roboczego (curr_dir). Umożliwia to atakującemu odczyt i zapis plików poza dozwolonym katalogiem poprzez sekwencje typu ../.
Oryginalny opis (angielski, źródło NVD)
Langroid is a framework for building large-language-model-powered applications. Prior to version 0.64.0, `SQLChatAgent` in `langroid` ships a `_validate_query` defense-in-depth layer whose `_DANGEROUS_SQL_PATTERNS` regex blocklist enumerates dangerous SQL primitives by specific function name. The list misses the canonical PostgreSQL filesystem-disclosure family `pg_read_file()`, `pg_stat_file()`, `pg_ls_logdir()`, `pg_ls_waldir()`, `pg_current_logfile()` (and similar `SELECT`-shaped functions in the same family). It also leaves SQL Server `OPENDATASOURCE` and SQLite `ATTACH '<file>' AS x` (DATABASE keyword omitted) unblocked. An attacker able to shape the LLM's generated SQL (directly via prompt input or transitively via prompt-injection in data the LLM ingests) can read arbitrary files from the PostgreSQL host through ordinary `SELECT` queries, even with the agent's strict default configuration (`allow_dangerous_operations=False`, `allowed_statement_types=['SELECT']`). The payloads survive the statement-type allowlist (each is a `SELECT`) and pass through the regex blocklist (none of the function names match), then reach the live SQLAlchemy engine via `SQLChatAgent.run_query`. Version 0.64.0 contains a patch for the issue.