nuxt-ollama, an npm module that wires the Ollama API into Nuxt applications, shipped a design flaw through version 1.2.26 that exposed operators’ Ollama cloud API keys to every visitor of an affected site, without requiring any credentials or user interaction on the attacker’s side. It’s fixed in 1.3.1.
What the flaw is
Per the GitHub Advisory Database record, nuxt-ollama unconditionally merges every module configuration option — including api_key, when an operator configures cloud Ollama per the module’s own documentation — into Nuxt’s public runtime config namespace. Nuxt serializes that public runtime config into the server-rendered HTML response so the browser can hydrate the page, which means the API key appears in plaintext inside the page’s own HTML payload. Any unauthenticated HTTP client that requests the page can read the key directly out of the response body. A browser-side component then reads that same public config value and attaches it as a bearer token on client-side API calls — the key isn’t just an unused byproduct sitting in the page source, it’s actively transmitted to the browser by the module’s own design. CWE-522 (Insufficiently Protected Credentials). CVSS base 7.5 (high; vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N). The record’s remediation guidance describes moving the key into Nuxt’s private runtime config, which only server-side code can read — that fix shipped in 1.3.1. Confidence: medium — GitHub Advisory Database only, no independent corroborating source in our ledger.
Why this matters
A leaked cloud API key lets anyone make requests against the operator’s Ollama account at the operator’s expense — quota exhaustion, unexpected billing, or use of the key for purposes the operator never authorized. Because the exposure requires no authentication and no user interaction, any operator who followed the module’s own documented configuration pattern for cloud Ollama was affected by default, not as an edge case. This is also a useful general reminder for any framework with a public/private runtime-config split: a secret placed in the wrong namespace doesn’t fail loudly, it just quietly ships to every page load.
Frequently Asked Questions
Is this an Ollama vulnerability or a nuxt-ollama vulnerability?
It’s specific to the nuxt-ollama npm integration package, not a flaw in Ollama itself. The bug is in how the wrapper module handles configuration, not in Ollama’s own server code.
Which version fixes this? 1.3.1 and later, per the GitHub Advisory Database record.
Is this vulnerability being actively exploited? Our source data contains no exploitation reports or KEV listing for this CVE.
Am I affected if I never configured a cloud Ollama API key?
The exposure specifically concerns the api_key option used for cloud Ollama. A deployment that only points nuxt-ollama at a local, unauthenticated Ollama instance has no API key in the affected configuration path to begin with.
Data sourced from the GitHub Advisory Database, evaluated September 2026. See more vulnerability intelligence.