Bug Description

The QQ bot plugin cannot obtain access tokens because fetchWithSsrFGuard in doFetchToken() is called without a policy parameter. When bots.qq.com resolves to a 198.18.x.x address (RFC 2544 benchmark range), the default SSRF policy blocks it.

Error Log

[security] blocked URL fetch (qqbot-token) target=https://bots.qq.com/app/getAppAccessToken reason=Blocked: resolves to private/internal/special-use IP address
[qqbot:token:1903616641] Connection failed: Network error getting access_token: Blocked: resolves to private/internal/special-use IP address

bots.qq.com resolves to 198.18.0.70 — an address in the RFC 2544 benchmark address range (198.18.0.0/15).

Root Cause

In the QQ bot plugin's bundled runtime JS (runtime-DWfbz21q.js), the doFetchToken() method calls fetchWithSsrFGuard() without passing a policy parameter:

const guarded = await fetchWithSsrFGuard({
    url: TOKEN_URL,
    auditContext: "qqbot-token",
    capture: false,
    // ❌ Missing: policy parameter — uses default strict SSRF policy
    init: { method: "POST", headers, body },
});

Meanwhile the media upload path already has the correct policy:

const QQBOT_MEDIA_SSRF_POLICY = {
    hostnameAllowlist: ["*.qpic.cn", "*.qq.com", ...],
    allowRfc2544BenchmarkRange: true  // ✅
};

The fix is to add policy: { allowRfc2544BenchmarkRange: true } to the token fetch call, exactly as the media path already does.

Environment

• OpenClaw 2026.5.28 (gateway, latest stable)
• QQ bot plugin 2026.5.28
• Linux (WSL2), Node 22.22.2
• DNS resolver returns 198.18.0.70 for bots.qq.com

Workaround

Patch the QQ bot plugin runtime JS file directly:

• File: ~/.openclaw/npm/projects/openclaw-qqbot-*/node_modules/@openclaw/qqbot/dist/runtime-DWfbz21q.js
• Target: doFetchToken() method's fetchWithSsrFGuard call
• Change: inject policy: { allowRfc2544BenchmarkRange: true } between capture: false and init

A systemd ExecStartPre can re-apply the patch on every gateway start.

Related

• Issue Bug: QQBot plugin token/API requests blocked by SSRF guard in fake-IP proxy environments (Surge/Clash) #70310 was filed for the same bug but incorrectly closed as "implemented". The bot clawsweeper[bot] marked it resolved without the fix actually shipping to the QQ plugin code.
• The media upload path has always worked correctly — only the token fetch path is affected.