Did Nuxt Ollama Put A Cloud API Key In Every Public Page?

September 10, 2026

Affected Nuxt Ollama apps exposed cloud API keys in public SSR HTML. Learn the fixed versions, rotation steps, and what the advisory does not prove.

Yes—for an affected server-rendered Nuxt app that configured an Ollama cloud API key, the vulnerable nuxt-ollama module could place that key in the public HTML sent to any visitor. CVE-2026-59158 affects nuxt-ollama 1.2.26 through versions before 1.3.1. GitHub rates it High at 7.5.

That does not mean every Nuxt site, every Ollama installation, or every local Ollama user leaked a key. The vulnerable chain required the affected module version, a configured api_key, and server-side rendering that serialized Nuxt's public runtime configuration. But where those conditions existed, an unauthenticated HTTP request could retrieve the credential in plaintext.

Operators should upgrade to a current release, rotate any key that passed through the vulnerable configuration, redeploy the application, and review provider usage. Simply removing the key from source control or changing the Nuxt configuration now does not invalidate a copy that may already have reached browsers, caches, logs, or crawlers.

Research cutoff: September 10, 2026. This article separates the reviewed vulnerability record from impact claims that have not been demonstrated publicly.

What Is Confirmed

The GitHub reviewed advisory for CVE-2026-59158 says nuxt-ollama unconditionally merged all module options into runtimeConfig.public.ollama. Those options could include the Ollama API key shown in the module's cloud configuration.

Nuxt's own runtime configuration documentation makes the boundary explicit: values under runtimeConfig.public are available on both the server and client. During server-side rendering, Nuxt serializes public runtime configuration into the page payload used to hydrate the browser application.

The result was a direct source-to-response path:

1. An operator configured the nuxt-ollama module with a cloud host and api_key.
2. The module copied the complete options object into Nuxt's public runtime configuration.
3. Nuxt embedded that public configuration in the server-rendered HTML.
4. An unauthenticated visitor fetched a page and received the key in the response body.
5. Browser-side module code used the same value as an Authorization: Bearer credential for Ollama API requests.

The advisory includes a controlled reproduction using a sentinel key. A plain HTTP GET to the test application's home page returned that sentinel inside the Nuxt payload. No login, browser exploit, prompt injection, or special user action was required for that demonstration.

GitHub lists the vulnerable range as 1.2.26 through versions before 1.3.1 and identifies 1.3.1 as the first patched version. The npm registry now lists newer releases, so operators should prefer the latest compatible version rather than stopping at the minimum fix.

Why A Public Runtime Configuration Is Not A Secret Store

The word runtime can sound private because the value is supplied when the application runs instead of being hard-coded into a bundle. The word that matters here is public.

A server-rendered application must give its browser code the public values that code needs. Nuxt does that by serializing them into the HTML payload. Anyone who can load the page can inspect the raw response, page source, developer tools, a proxy capture, or a cached copy. Minification, obfuscation, and hiding the value from the visible interface do not turn it back into a secret.

This is a broader web-development rule: a reusable credential cannot remain secret if browser code is expected to possess it. A server can keep a credential private and make narrowly authorized requests on the browser's behalf. It cannot safely send the credential to every browser and still treat possession as proof of trust.

Was The Key Really In Every Public Page?

The advisory says Nuxt's SSR pipeline embedded the public runtime configuration in server-rendered HTML, and its reproduction retrieved the key from the home page. That supports the warning that affected SSR responses could expose the key broadly.

But “every public page” needs conditions:

• the application had to use a vulnerable nuxt-ollama version;
• the operator had to configure an API key;
• the route had to receive the affected public runtime payload; and
• the response had to be generated or cached while that key was configured.

A Nuxt application that did not use the module was not affected by this advisory. A module user connecting only to a local Ollama endpoint without a cloud key had no configured cloud key for this path to reveal. A client-only or specially customized deployment may also produce different output and should be tested rather than assumed.

The safe operational question is not “Did every site leak?” It is: “Did any response from my affected deployment contain the credential?”

What An Exposed Ollama API Key Can Do

Ollama's authentication documentation says direct requests to the ollama.com API use an API key in the bearer authorization header. The same documentation says keys do not currently expire automatically but can be revoked.

That makes the disclosed value a reusable bearer credential. Anyone who possesses it may be able to make requests with the authority assigned to the key. The reviewed advisory specifically identifies unauthorized Ollama API use at the operator's expense as the impact.

Possible operational consequences include unexpected model usage, exhausted quotas or rate limits, and service disruption. The exact financial and data impact depends on the provider account, key permissions, available APIs, usage terms, and what an attacker actually did.

Do not inflate the evidence. The public record does not show that an attacker stole a production key, ran up a bill, accessed stored conversations, or compromised Ollama itself. Those are incident questions, not automatic consequences of vulnerable code.

What Is Still Unclear

How many applications used the vulnerable cloud configuration?

The Nuxt module directory shows that nuxt-ollama is a community module and displays current package activity, but that is not an inventory of deployed applications. Public package downloads do not reveal how many installations were live, server-rendered, internet-accessible, or configured with an Ollama cloud key.

Were any real keys collected or abused?

No reviewed source found for this article reports exploitation in the wild, stolen production keys, fraudulent charges, or a measured victim count. Absence of a report is not proof that nobody fetched an affected page.

Which old copies still exist?

A key may have appeared in browser caches, CDN caches, reverse-proxy logs, application traces, monitoring captures, saved pages, search indexes, or security scans. Whether any of those copies exist depends on the deployment and its retention settings.

Does upgrading prove the old key is safe?

No. The patch stops the documented serialization path. It cannot recall a credential already delivered to another system. Rotation is what invalidates the old bearer value.

Could the key expose conversations or private models?

That depends on the actual authority and behavior of the affected account and APIs. The advisory discusses possible downstream impact, but it does not document a real incident or prove that every exposed key could read stored data.

How To Check A Nuxt Ollama Deployment

Use a synthetic marker for reproduction. Do not paste a production credential into a test page or third-party scanner.

1. Record the deployed artifact

Identify the nuxt-ollama version in the lockfile and the package actually installed in the production build. Record the container or deployment digest too. A changed manifest does not prove an old process was replaced.

If the deployed version is 1.2.26 through 1.3.0, treat it as affected. If it is older, review the exact code and configuration rather than assuming it is safe merely because it falls outside the advisory's named range.

2. Find every place the option was supplied

Check Nuxt configuration, environment-variable mappings, deployment secrets, CI variables, hosting dashboards, and generated runtime configuration. Search for the option name and for the known key prefix, but prevent search output from entering shared logs.

3. Inspect rendered responses

Fetch representative public routes without authentication and inspect the raw HTML, not only the visible page. Check the Nuxt payload for api_key, the key prefix, or a synthetic marker in a controlled nonproduction build.

Test routes rendered at the origin and through each CDN or reverse proxy. A fixed origin can coexist with a stale cached response.

4. Review retained copies

Check CDN cache history, application and proxy logs, error monitoring, browser recordings, observability payloads, build artifacts, saved responses, and security-scanner archives. Avoid copying the full credential into a ticket while documenting the result.

5. Rotate and verify

Revoke the exposed key through the provider account, create a replacement, deploy a current module release, purge affected caches, and verify that the old key is rejected. Then make a known request with the new configuration and confirm that the replacement value does not appear in HTML.

The ROTATE Response

Use this six-part response for any server-rendered secret exposure:

1. R — Record: Preserve the package version, deployed digest, configuration path, response sample, and research cutoff.
2. O — Observe: Inspect public HTML, caches, logs, monitoring, and provider usage without spreading the secret further.
3. T — Terminate: Revoke the exposed bearer credential instead of relying on a code change alone.
4. A — Apply: Upgrade to a current fixed release, move secrets to server-only configuration, and redeploy every instance.
5. T — Trace: Review usage, billing, rate-limit, and access records for activity outside expected patterns.
6. E — Eliminate: Remove any design that requires a reusable provider credential in browser-accessible state.

ROTATE is intentionally broader than “upgrade.” Software remediation, credential containment, and incident review solve different parts of the problem.

Local Ollama And Ollama Cloud Are Different Boundaries

A local Ollama API normally runs on the user's machine and does not require the Ollama cloud API key described here. Ollama's cloud documentation explains that cloud models are processed through Ollama's service and that direct cloud API access uses a key.

That distinction matters for both privacy and security:

• a local model can keep inference on hardware you control, subject to the rest of the application's network and tool behavior;
• a cloud model sends active requests to a hosted service; and
• a local web interface can still introduce browser, authentication, file, plugin, SSRF, logging, and secret-management risks even when model inference is local.

If you are auditing the whole route, read whether using Ollama means AI is always local, whether an Ollama model digest proves a backup is complete, and how local AI can use web search without making the search local.

Where OpenVeil Fits

OpenVeil is a hosted, paid, privacy-focused conversational workspace for adults. A user can access chat, search, files, voice, image, video, and persona features without deploying a Nuxt integration or administering an Ollama cloud API key. Normal private-chat history is stored in the user's browser, and OpenVeil does not maintain a normal server-side chat-history record for those sessions.

That can remove this particular self-hosted integration task from the user's environment. It does not make OpenVeil a Nuxt patch, secret scanner, billing control, API-key vault, incident-response service, or guarantee against unrelated vulnerabilities.

OpenVeil is also not fully offline or anonymous. Active requests can still be processed by OpenVeil and necessary AI, search, upload, hosting, routing, security, billing, and infrastructure providers. Users should not paste passwords, API keys, private keys, regulated records, or information they are not authorized to share into any hosted AI service.

For the broader comparison, see OpenVeil versus Ollama and what no server chat history does not mean.

FAQ

Which nuxt-ollama versions are affected?

GitHub lists versions 1.2.26 through versions before 1.3.1 as vulnerable. Version 1.3.1 is the first patched version, and newer releases are available.

Does CVE-2026-59158 affect every Nuxt application?

No. It affects the named nuxt-ollama package range and the documented API-key configuration path. A Nuxt application that never installed the module is not affected by this advisory.

Does it affect local Ollama without a cloud API key?

The disclosed credential path requires an api_key value. A local-only setup with no cloud key has no Ollama cloud credential for this bug to serialize. The surrounding web application can still have other security and privacy risks.

Is upgrading to 1.3.1 enough?

It fixes the documented code path, but it does not invalidate an old key that may already have been exposed. Upgrade to a current compatible version, rotate the old key, purge affected caches, and review usage.

Can I just hide the key with an environment variable?

An environment variable can keep a secret out of source code, but it does not help if application code copies the value into public runtime configuration. The final destination of the value—not only its source—determines whether browsers receive it.

How can I tell whether the key was exposed?

Inspect unauthenticated raw HTML from representative routes, cached copies, logs, monitoring captures, and provider usage records. Use a synthetic key in a controlled test when reproducing the behavior.

Was Ollama breached?

The advisory describes a flaw in the community nuxt-ollama integration. It does not report a breach of Ollama's service or prove that any production key was stolen.

Bottom Line

CVE-2026-59158 put an Ollama cloud API key into browser-readable Nuxt SSR HTML when an affected nuxt-ollama version used that configuration. The exposure required no authentication in the reviewed reproduction. Version 1.3.1 is the first listed fix, but operators should install a current release, rotate the old credential, purge retained responses, and review usage.

The durable lesson is simple: public runtime configuration is part of the client boundary. If a browser can receive a reusable provider key, the key is no longer secret.