CVE-2026-59158: Ollama API key leaked

CISO Take

nuxt-ollama versions 1.2.26 through 1.3.0 unconditionally copy the Ollama cloud API key into Nuxt's public runtime config, which gets serialized in plaintext into every server-rendered page's `__NUXT__` script block — meaning any anonymous visitor, crawler, or network observer who loads the homepage can lift the key with a single unauthenticated `curl` request. This is a CVSS 7.5 credential-exposure flaw (CWE-522) with a confirmed working PoC and zero attacker prerequisites; there's no EPSS or KEV data yet since it's a fresh advisory (published 2026-09-09), but the low exploitation bar and the fact that the vulnerable behavior is the officially documented configuration path for cloud Ollama makes accidental mass exposure likely once scanners start grepping for the `api_key` pattern. The package itself shows weak maintenance signals — 31 other CVEs on record and a package risk score of 84/100 — so if it's in your stack, assume other issues exist too. Immediate action: upgrade to 1.3.1, rotate any Ollama cloud API key that was ever deployed with an affected version, and grep production HTML responses / CDN logs for `api_key` leakage as a compromise indicator.

Sources:NVDGitHub AdvisoryATLAS

What is the risk?

High severity, trivial exploitability, low current exposure breadth. The flaw requires zero privileges, zero user interaction, and a single HTTP GET — any operator who followed the module's own README to enable cloud Ollama is affected by default, with no opt-out. Impact is capped at confidentiality (API key theft) with no direct integrity or availability compromise from the vulnerability itself, but the stolen key enables downstream abuse (unauthorized inference calls, cost harvesting, possible data exposure if the key has read access to stored models/conversations). No public exploit tooling, Nuclei template, or KEV listing exists yet, and EPSS data is not available for this very recent CVE, so opportunistic mass-exploitation has not been observed — but the attack is so cheap (one curl request) that any targeted reconnaissance of a site known to use nuxt-ollama would find it immediately.

How does the attack unfold?

Discovery

Attacker sends an unauthenticated HTTP GET to the target Nuxt application's homepage.

AML.T0055

Credential extraction

The response HTML contains the `__NUXT__` payload with `public.ollama.api_key` in plaintext, which the attacker parses out.

AML.T0055

Unauthorized API access

The attacker replays the stolen key as a Bearer token against the Ollama cloud API, gaining the operator's level of access.

AML.T0040

Impact

The attacker runs arbitrary inference at the operator's expense, exhausts quota/rate limits, or accesses stored models/conversations tied to the key.

AML.T0034

Discovery

Attacker sends an unauthenticated HTTP GET to the target Nuxt application's homepage.

AML.T0055

Credential extraction

The response HTML contains the `__NUXT__` payload with `public.ollama.api_key` in plaintext, which the attacker parses out.

AML.T0055

Unauthorized API access

The attacker replays the stolen key as a Bearer token against the Ollama cloud API, gaining the operator's level of access.

AML.T0040

Impact

The attacker runs arbitrary inference at the operator's expense, exhausts quota/rate limits, or accesses stored models/conversations tied to the key.

AML.T0034

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
Ollama	npm	>= 1.2.26, < 1.3.1	`1.3.1`
185.5K1.9K dependentsPushed 4d ago19% patched~36d to patchFull package profile →

Do you use Ollama? You're affected.

How severe is it?

CVSS 3.1

7.5 / 10

EPSS

0.5%

chance of exploitation in 30 days

Higher than 43% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

Exploit Available

Exploitation: MEDIUM

Sophistication

Trivial

Exploitation Confidence

medium

○CISA SSVC: Public PoC

Composite signal derived from CISA KEV, VulnCheck KEV, CISA SSVC, EPSS, Metasploit, Exploit-DB, trickest/cve, Nuclei templates, and inthewild.io exploitation reports.

What is the attack surface?

AVNetwork

ACLow

PRNone

UINone

SUnchanged

CHigh

INone

ANone

What should I do?

1 step

1) Upgrade to nuxt-ollama@1.3.1 or later immediately — the patch moves api_key into Nuxt's private runtime config, keeping it server-side only. 2) Treat any API key ever used with an affected version (1.2.26–1.3.0) as compromised: rotate it in the Ollama cloud dashboard regardless of whether abuse has been confirmed. 3) Detection: audit historical page HTML / CDN cache / WAF logs for the string api_key inside __NUXT__ or __NUXT_DATA__ payloads to confirm whether exposure actually occurred and for how long. 4) Post-patch verification: curl -s https://<your-app>/ | grep -o 'api_key"\?:\?"[^"]*' should return nothing. 5) As defense in depth, monitor Ollama cloud API usage/billing for anomalous request volume that could indicate an already-stolen key being abused.

What does CISA's SSVC say?

DecisionTrack*

Exploitationpoc

AutomatableYes

Technical Impactpartial

Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.

How is it classified?

Data LeakageAuth BypassFrameworkAPIInferenceAML.T0034- Cost Harvesting AML.T0040- AI Model Inference API Access AML.T0055- Unsecured Credentials

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 15-Accuracy, robustness and cybersecurity

ISO 42001

Annex A.6.2-AI system security controls in operation

NIST AI RMF

MANAGE-2.3-Mechanisms are in place to monitor and manage third-party AI component risk

OWASP LLM Top 10

LLM02:2025-Sensitive Information Disclosure

Frequently Asked Questions

What is CVE-2026-59158?

nuxt-ollama versions 1.2.26 through 1.3.0 unconditionally copy the Ollama cloud API key into Nuxt's public runtime config, which gets serialized in plaintext into every server-rendered page's `__NUXT__` script block — meaning any anonymous visitor, crawler, or network observer who loads the homepage can lift the key with a single unauthenticated `curl` request. This is a CVSS 7.5 credential-exposure flaw (CWE-522) with a confirmed working PoC and zero attacker prerequisites; there's no EPSS or KEV data yet since it's a fresh advisory (published 2026-09-09), but the low exploitation bar and the fact that the vulnerable behavior is the officially documented configuration path for cloud Ollama makes accidental mass exposure likely once scanners start grepping for the `api_key` pattern. The package itself shows weak maintenance signals — 31 other CVEs on record and a package risk score of 84/100 — so if it's in your stack, assume other issues exist too. Immediate action: upgrade to 1.3.1, rotate any Ollama cloud API key that was ever deployed with an affected version, and grep production HTML responses / CDN logs for `api_key` leakage as a compromise indicator.

Is CVE-2026-59158 actively exploited?

No confirmed active exploitation of CVE-2026-59158 has been reported, but organizations should still patch proactively.

How to fix CVE-2026-59158?

1) Upgrade to `nuxt-ollama@1.3.1` or later immediately — the patch moves `api_key` into Nuxt's private runtime config, keeping it server-side only. 2) Treat any API key ever used with an affected version (1.2.26–1.3.0) as compromised: rotate it in the Ollama cloud dashboard regardless of whether abuse has been confirmed. 3) Detection: audit historical page HTML / CDN cache / WAF logs for the string `api_key` inside `__NUXT__` or `__NUXT_DATA__` payloads to confirm whether exposure actually occurred and for how long. 4) Post-patch verification: `curl -s https://<your-app>/ | grep -o 'api_key"\?:\?"[^"]*'` should return nothing. 5) As defense in depth, monitor Ollama cloud API usage/billing for anomalous request volume that could indicate an already-stolen key being abused.

What systems are affected by CVE-2026-59158?

This vulnerability affects the following AI/ML architecture patterns: LLM API integration (cloud-hosted inference), model serving, SSR web frontends embedding LLM credentials.

What is the CVSS score for CVE-2026-59158?

CVE-2026-59158 has a CVSS v3.1 base score of 7.5 (HIGH). The EPSS exploitation probability is 0.50%.

What is the AI security impact?

Affected AI Architectures

LLM API integration (cloud-hosted inference)model servingSSR web frontends embedding LLM credentials

MITRE ATLAS Techniques

AML.T0034Cost Harvesting

AML.T0040AI Model Inference API Access

AML.T0055Unsecured Credentials

Compliance Controls Affected

EU AI Act: Article 15

ISO 42001: Annex A.6.2

NIST AI RMF: MANAGE-2.3

OWASP LLM Top 10: LLM02:2025

What are the technical details?

Original Advisory

Nuxt Ollama integrates the official Ollama JavaScript library into Nuxt applications. Prior to 1.3.1, `src/module.ts` unconditionally merges all module options, including a configured cloud `api_key`, into `runtimeConfig.public.ollama`. Nuxt serializes this public configuration into the server-rendered HTML `window.__NUXT__` payload, exposing the API key in plaintext to any unauthenticated client that fetches a page. `src/runtime/composables/useOllama.ts` also reads the public key and sends it as an `Authorization` `Bearer` credential in browser-side Ollama requests. Following the documented cloud configuration is sufficient; the visible application template need not make an Ollama request for the secret to leak. A stolen key permits unauthorized cloud API requests at the operator's expense, quota or rate-limit exhaustion, and access to stored models or conversations if the key grants those permissions. This issue is fixed in version 1.3.1.

Exploitation Scenario

An attacker with no credentials and no reconnaissance beyond knowing (or discovering via tech fingerprinting) that a target site uses `nuxt-ollama` sends a single anonymous HTTP GET to the site's homepage. The SSR response embeds the operator's Ollama cloud `api_key` in plaintext inside the `window.__NUXT__` script block. The attacker extracts the key with a regex, then replays it as an `Authorization: Bearer` header directly against the Ollama cloud API, gaining the same level of access the legitimate application has — running arbitrary inference at the victim's expense, exhausting rate limits/quota, or, if the key scope permits, reading stored models or conversation history tied to that account.

Weaknesses (CWE)

CWE-522Insufficiently Protected CredentialsPrimary CWE-522Insufficiently Protected CredentialsPrimary CWE-522Insufficiently Protected Credentials

CWE-522 — Insufficiently Protected Credentials: The product transmits or stores authentication credentials, but it uses an insecure method that is susceptible to unauthorized interception and/or retrieval.

[Architecture and Design] Use an appropriate security mechanism to protect the credentials.
[Architecture and Design] Make appropriate use of cryptography to protect the credentials.

Source: MITRE CWE corpus.