Summary

The new SSRF protection (introduced in 2026.3.28) blocks the BlueBubbles channel plugin's own HTTP calls to its configured server at a private IP address (10.0.0.x:1234). The guard doesn't distinguish between agent-initiated web_fetch (user-controllable, should be guarded) and plugin internal HTTP calls (code-controlled, configured by admin, should be trusted).

Reproduction

1. Configure BlueBubbles plugin with a local server: http://10.0.0.2:1234
2. Start gateway on build 2026.3.28+
3. BlueBubbles plugin fails to connect — all API calls blocked

Error Log

[security] blocked URL fetch (bluebubbles-api) target=http://10.0.0.2:1234/api/v1/server/info reason=Blocked hostname or private/internal/special-use IP address
[security] blocked URL fetch (bluebubbles-api) target=http://10.0.0.2:1234/api/v1/ping reason=Blocked hostname or private/internal/special-use IP address

Expected Behavior

Plugin internal HTTP clients should bypass SSRF policy when making calls to their own admin-configured endpoints. The SSRF guard should only apply to agent-initiated fetches (web_fetch tool, browser tool) where the URL is user/content-controllable.

Workaround

{
  "browser": {
    "ssrfPolicy": {
      "hostnameAllowlist": ["10.0.0.2"]
    }
  }
}

This works but is overly broad — it also allows agent web_fetch to hit the same host, which defeats the purpose of the SSRF guard.

Suggested Fix

Plugin HTTP clients (channel providers, model providers) should use a separate fetch path that is exempt from the agent-facing SSRF policy, since their target URLs are admin-configured in openclaw.json, not derived from user input.

This likely affects other self-hosted integrations too: Home Assistant, local LLM servers (Ollama, vLLM), local TTS, etc.

Environment

• macOS 26.3 (arm64)
• OpenClaw 2026.3.28 (commit 5adc50c)
• BlueBubbles server on local network (10.0.0.2:1234)