Podatności dbt-mcp

W dbt-mcp przed wersją 1.20.0, lokalny asystent OAuth w src/dbt_mcp/oauth/fastapi_app.py udostępnia punkt końcowy GET /dbt_platform_context bez uwierzytelnienia i walidacji hosta. Po zakończeniu przepływu OAuth dbt Platform, punkt końcowy zwraca pełny DbtPlatformContext, w tym access_token i refresh_token, każdemu procesowi, który może dotrzeć do 127.0.0.1:6785. Brak TrustedHostMiddleware pozwala zdalnemu atakującemu na użycie DNS rebinding w przeglądarce ofiary, a proces współdzielony może bezpośrednio żądać punktu końcowego. Skradzione tokeny zapewniają natychmiastowy dostęp do API dbt Platform jako ofiara oraz trwały dostęp przez refresh token, umożliwiając dostęp lub modyfikację projektów, zadań, sekretów środowiskowych i powiązanych danych konta.

W dbt-mcp przed wersją 1.17.1 funkcja DefaultUsageTracker.emit_tool_called_event() serializuje pełny słownik argumentów każdego wywołania narzędzia MCP i wysyła go przez dbtlabs_vortex.producer.log_proto bez maskowania, w tym sql_query, vars i node_selection. Telemetria jest domyślnie włączona, chyba że ustawiono DBT_SEND_ANONYMOUS_USAGE_STATS=false lub DO_NOT_TRACK=1.

W dbt-mcp (serwer MCP dla dbt) przed wersją 1.17.1 stwierdzono, że funkcja call_tool() loguje surowe argumenty na poziomie INFO, a configure_file_logging() zapisuje je do pliku dbt-mcp.log, co może ujawnić poufne zapytania SQL, zmienne i selekcje węzłów w postaci jawnego tekstu bez automatycznej rotacji lub usuwania.

dbt-mcp przed wersją 1.17.1 nie oczyszcza wartości node_selection i resource_type przed dodaniem ich do argumentów podprocesu dbt. Klient MCP może wstrzyknąć globalne flagi dbt (np. --profiles-dir) mimo użycia shell=False.