Summary
Nuxt Ollama exposes a configured Ollama Cloud API key by placing it in Nuxt's public runtime configuration, which is serialized into server-rendered HTML. Any unauthenticated client that retrieves an affected page may obtain the key and use it for unauthorized cloud requests, potentially consuming operator resources or accessing permitted data.
Nuxt Ollama exposes a configured Ollama Cloud API key by placing it in Nuxt's public runtime configuration, which is serialized into server-rendered HTML. Any unauthenticated client that retrieves an affected page may obtain the key and use it for unauthorized cloud requests, potentially consuming operator resources or accessing permitted data.
Affected context
The issue occurs in Nuxt Ollama deployments that configure a cloud API key through the module options. The module unconditionally merges that option into runtimeConfig.public.ollama, and Nuxt may include the resulting value in the window.__NUXT__ payload delivered to browsers. The application does not need to visibly invoke an Ollama request for the credential to be exposed.
The issue occurs in Nuxt Ollama deployments that configure a cloud API key through the module options. The module unconditionally merges that option into runtimeConfig.public.ollama, and Nuxt may include the resulting value in the window.__NUXT__ payload delivered to browsers. The application does not need to visibly invoke an Ollama request for the credential to be exposed.
Exploit preconditions
- Attack surface: Server-rendered Nuxt pages and their serialized runtime configuration
- Required access: Ability to request an affected public page; authentication is generally not required
- Trigger point: Rendering or fetching a page whose payload contains the public Ollama configuration
- Why exploitation is possible: A secret API key is placed in a client-visible configuration namespace and may also be used by browser-side code as a bearer credential
- Attack surface: Server-rendered Nuxt pages and their serialized runtime configuration
- Required access: Ability to request an affected public page; authentication is generally not required
- Trigger point: Rendering or fetching a page whose payload contains the public Ollama configuration
- Why exploitation is possible: A secret API key is placed in a client-visible configuration namespace and may also be used by browser-side code as a bearer credential
Why this happens
The vulnerability results from treating a secret cloud API key as public runtime configuration. Values stored in runtimeConfig.public are intended for browser exposure, and Nuxt serializes them into the server-rendered payload. The runtime composable then reads the exposed value for client-side authorization, creating an insecure credential-handling pattern that maps to CWE-522, where authentication information is insufficiently protected from disclosure.
The vulnerability results from treating a secret cloud API key as public runtime configuration. Values stored in runtimeConfig.public are intended for browser exposure, and Nuxt serializes them into the server-rendered payload. The runtime composable then reads the exposed value for client-side authorization, creating an insecure credential-handling pattern that maps to CWE-522, where authentication information is insufficiently protected from disclosure.
Potential impact
- An attacker may make unauthorized Ollama Cloud API requests using the exposed key
- The operator may incur unexpected usage charges or consume service quotas
- Attackers could exhaust rate limits and disrupt legitimate application activity
- An exposed key may permit access to stored models or conversations within its granted scope
- The credential could be reused in other workflows until revoked or rotated
- An attacker may make unauthorized Ollama Cloud API requests using the exposed key
- The operator may incur unexpected usage charges or consume service quotas
- Attackers could exhaust rate limits and disrupt legitimate application activity
- An exposed key may permit access to stored models or conversations within its granted scope
- The credential could be reused in other workflows until revoked or rotated
General mitigation guidance
Mitigation focuses on keeping cloud credentials exclusively on trusted server-side boundaries.
Common defensive patterns include:
- Store API keys in private server runtime configuration rather than public configuration
- Proxy Ollama Cloud requests through server-side handlers that enforce authorization
- Ensure browser bundles, rendered HTML, and serialized state never contain bearer credentials
- Use narrowly scoped credentials with the minimum required permissions
- Apply secret rotation, revocation, and usage monitoring procedures
- Treat any previously exposed key as compromised and replace it through established credential-management processes
Mitigation focuses on keeping cloud credentials exclusively on trusted server-side boundaries.
Common defensive patterns include:
- Store API keys in private server runtime configuration rather than public configuration
- Proxy Ollama Cloud requests through server-side handlers that enforce authorization
- Ensure browser bundles, rendered HTML, and serialized state never contain bearer credentials
- Use narrowly scoped credentials with the minimum required permissions
- Apply secret rotation, revocation, and usage monitoring procedures
- Treat any previously exposed key as compromised and replace it through established credential-management processes
How teams detect issues like this
Organizations can detect this class of issue through:
- Static analysis rules that flag secrets assigned to public runtime configuration
- Code review checks for API keys passed into browser-side composables or bundles
- Rendered-page inspections for credential-like values in
window.__NUXT__and related payloads - CI policies that scan generated HTML, client assets, and configuration output for secrets
- Runtime monitoring for unexpected API usage, quota consumption, or access from unusual locations
Automated secret-scanning and dependency-review tools may help identify accidental exposure during development and release workflows.
Organizations can detect this class of issue through:
- Static analysis rules that flag secrets assigned to public runtime configuration
- Code review checks for API keys passed into browser-side composables or bundles
- Rendered-page inspections for credential-like values in
window.__NUXT__and related payloads - CI policies that scan generated HTML, client assets, and configuration output for secrets
- Runtime monitoring for unexpected API usage, quota consumption, or access from unusual locations
Automated secret-scanning and dependency-review tools may help identify accidental exposure during development and release workflows.
