CVE-2026-59158

Nuxt Ollama: Public Runtime Config Exposes Ollama API Key to Browser Clients ## Public Runtime Config Exposes Ollama API Key to Browser Clients ### Summary `[email protected]` unconditionally merges all module options — including `api_key` — into Nuxt's **public** runtime config (`runtimeConfig.public.ollama`). Nuxt serializes `runtimeConfig.public` into the SSR HTML response inside a `<script>` payload block (`window.__NUXT__`), making the API key visible in plaintext to any unauthenticated HTTP client that fetches the page. An attacker with no credentials can steal the Ollama cloud API key with a single HTTP GET request, then use it to make arbitrary requests to the Ollama API at the operator's expense. ### Details The vulnerability is a design flaw in `src/module.ts`. During Nuxt module setup, the entire `_options` object — which contains `api_key` when configured for cloud Ollama as documented in `README.md:71-80` — is merged into the **public** runtime config namespace: ```ts // src/module.ts:35-36 const currentConfig = (runtimeConfig.public.ollama ?? {}) as OllamaOptions runtimeConfig.public.ollama = defu(currentConfig, _options) ``` Nuxt's SSR pipeline serializes `runtimeConfig.public` and embeds it in every server-rendered HTML page for client-side hydration. This results in the `api_key` appearing verbatim in the `window.__NUXT__` script block: ```html <script> window.__NUXT__={}; window.__NUXT__.config={ public:{ ollama:{ protocol:"https", host:"api.ollama.com", port:"", proxy:false, api_key:"LEAKED_TEST_KEY_123" // ← secret exposed to browser } } } </script> ``` The browser-side composable (`src/runtime/composables/useOllama.ts`) then reads this value and sends it as an `Authorization: Bearer` header in client-side Ollama API calls: ```ts // src/runtime/composables/useOllama.ts:6-10 const options: ModuleOptions = useRuntimeConfig().public.ollama as ModuleOptions if (options.api_key) { headers.Authorization = `Bearer ${options.api_key}` } return new Ollama({ host, proxy: options.proxy, headers }) ``` The complete data flow from source to sink: 1. `README.md:71-80` — official documentation instructs users to set `ollama.api_key` for cloud Ollama models 2. `src/module.ts:35-36` — **source**: `api_key` is merged into `runtimeConfig.public.ollama` 3. Nuxt SSR runtime — `runtimeConfig.public` is serialized into HTML `__NUXT__` payload 4. `src/runtime/composables/useOllama.ts:6` — browser composable reads `useRuntimeConfig().public.ollama` 5. `src/runtime/composables/useOllama.ts:8-10` — **sink**: `options.api_key` becomes `headers.Authorization` in client-side HTTP request The `api_key` value is never private (i.e., placed in `runtimeConfig.ollama`) and no sanitization removes it from the public namespace before serialization. **Recommended remediation:** Move `api_key` to the private runtime config and remove it from the browser composable: ```diff - const currentConfig = (runtimeConfig.public.ollama ?? {}) as OllamaOptions - runtimeConfig.public.ollama = defu(currentConfig, _options) + const { api_key, ...publicOptions } = _options + const currentPublicConfig = (runtimeConfig.public.ollama ?? {}) as Omit<OllamaOptions, 'api_key'> + runtimeConfig.public.ollama = defu(currentPublicConfig, publicOptions) + const currentPrivateConfig = (runtimeConfig.ollama ?? {}) as Pick<ModuleOptions, 'api_key'> + runtimeConfig.ollama = defu(currentPrivateConfig, { api_key }) ``` The `api_key` should then only be consumed in the server-side utility (`src/runtime/server/utils/useOllama.ts`) via `useRuntimeConfig().ollama.api_key`. ### PoC **Prerequisites:** Docker, Python 3 **Step 1 — Build the vulnerable Nuxt app container** ```bash docker build \ -f /path/to/vuln-001/Dockerfile \ -t nuxt-ollama-vuln-001 \ /path/to/npmAI_735_thoda-dev__nuxt-ollama ``` The Dockerfile uses the nuxt-ollama source at commit `6989ea8` and injects the following `playgr