← NEWS DESK
security advisory

Three OpenClaw Fixes Close Credential Exposure Paths in Ollama, LM Studio and Voice Call Tunnels

Main-branch fixes stop Ollama cloud credentials being forwarded to loopback aliases, redact reflected API keys from provider errors, and keep ngrok auth tokens out of process arguments.

Independent reporting and tested guidance for OpenClaw operators · Editorial standards

OpenClaw landed three independent credential-hygiene fixes on main between August 24 and 25, 2026. None of them changes how you configure OpenClaw; all of them change what happens to secrets in failure paths and edge-case endpoints that operators rarely watch. Here is what each one means for your threat model.

Ollama: ambient credentials no longer forwarded to loopback aliases

PR #129168 closes a subtle gap: OpenClaw’s Ollama plugin classified only 127.0.0.1 as “local,” while anything else — including 127.0.0.2 or 127.1.2.3, which are equally loopback — got treated as remote. A remote-classified endpoint received your ambient Ollama Cloud credential instead of the synthetic local marker.

Why this matters: Ollama’s own documentation explicitly promises 127.0.0.2 remains local. An operator following that guidance would have their cloud-scoped credential forwarded to whatever server answered on that address — a local impersonator or a misconfigured proxy. Post-fix, the plugin reuses its canonical full-127/8 IPv4 loopback detector at the classification boundary; every IPv4 loopback endpoint gets the synthetic local marker, and external/private-network behavior is unchanged.

Evidence quality is high: four pre-fix regressions failed exactly on 127.0.0.2/127.1.2.3, and post-fix 151 focused tests pass covering discovery, auth classification, SSRF guards, timeouts, header redaction, and import boundaries.

Operator action: if you use non-.1 loopback aliases for Ollama, update and then verify your Ollama Cloud key never appears in requests to those endpoints. If you cannot update yet, pin Ollama endpoints to plain localhost/127.0.0.1.

Provider errors no longer echo your API keys

Two companion fixes close the same class of bug in different plugins: reflected credentials in error bodies. When a provider endpoint or an intermediary echoes an authorization value back inside a failed response, older builds copied that provider-controlled text straight into operator-visible errors.

  • PR #119537 (Ollama transport): embedding, native streaming, and web-search failures now run every error body through one owner-local helper that derives exact request-scoped secret values from the final outbound headers and removes raw, JSON-string, URI-encoded, form-encoded, mixed-case percent-escape, and truncation-boundary forms before display.
  • PR #128561 (LM Studio model-load): a malicious or broken reverse proxy can reflect active API keys in failed model-load responses or unexpected successful JSON statuses; both paths are sanitized longest-first against the exact finalized headers, and truncated bodies are suppressed because a credential split at the read limit cannot be identified safely.

These are defense-in-depth fixes for a path operators don’t control: the content of third-party error responses. The threat model is concrete — a hostile intermediary between you and the model provider can deliberately leak keys into logs, terminals, and chat surfaces where agents may re-read them.

Operator action: rotate any provider keys that appeared in pasted error messages or support tickets. On updated builds, error text remains useful for diagnostics while secret values are stripped even when general log redaction is disabled.

Voice Call: ngrok authtoken leaves process arguments

PR #129330 removes the last place Voice Call’s ngrok setup exposed its configured authentication value: child-process arguments. argv is world-readable via /proc/<pid>/cmdline to any local user or process-inspection tooling, so passing secrets there hands them to everything sharing the host.

The fix passes the value exclusively through ngrok’s supported NGROK_AUTHTOKEN environment contract, deletes the separate persist-to-config subprocess entirely (production −28 lines), and proves via real-child synthetic evidence that the value reaches the tunnel process environment and is absent from its argv.

Operator action: nothing to configure. But audit host hardening assumptions: any tool that could read /proc/*/cmdline previously had a window on your ngrok token whenever tunnels started.

The pattern behind these three

All three fixes share one root cause class: trust boundaries drawn by string comparison or convenience rather than ownership. A loopback classifier keyed on one address; error text trusted because it came from “the provider”; a CLI convention used despite argv being public. When you review OpenClaw security posture, look for exactly these shapes — and note that each fix arrived through the project’s proof-driven contribution pipeline, with red-green regressions attached to every claim.

THE RECEIPTS

Claims should survive the click.

Primary links used for this article are listed openly. If the evidence changes, the verification date changes with it.
  1. 01fix(ollama): protect local credentials on all loopback addresses — PR #129168
  2. 02fix(ollama): redact reflected credentials from transport errors — PR #119537
  3. 03fix(lmstudio): redact reflected model-load credentials — PR #128561
  4. 04fix(voice-call): keep ngrok auth out of argv — PR #129330

THE OPERATOR BRIEF

One useful email when the signal earns it.

Release impact, security changes and repository intelligence. No daily sludge.