How We Hit the SSRF Landmine in OpenClaw 2026.4.2 and Fixed It Across 13 Nodes

April 4, 2026 turned into our cluster-wide migration day — switching all OpenClaw nodes from Anthropic models to openai-codex/gpt-5.4. The trigger was a policy change on Anthropic's side that cut off third-party harness access to subscription quota. Running rough numbers on March usage: full Opus would run ~$4,700/month, Sonnet ~$945/month. Not sustainable, so we pivoted to Codex via existing ChatGPT Plus.

The model switch alone wasn't the hard part. To run gpt-5.4 stably, OpenClaw needed to be on 2026.3.3 or later. We validated 2026.4.2 on one node first, then rolled it out to all 13.

That's where the SSRF protection blindsided us.

Symptom: Bot Goes Silent After Upgrade

In 2026.4.2, internal connections to Mattermost are blocked by default. The symptom is straightforward — after the upgrade, bots stop responding entirely. The logs show:

SsrFBlockedError: Blocked hostname or private/internal/special-use IP address

First instinct was "is Mattermost down?" — but the issue isn't network reachability. It's OpenClaw's own SSRF protection kicking in.

Two Traps, Not One

Trap #1: Type Mismatch

allowPrivateNetwork only works as a boolean true.

• ❌ String "true" — silently ignored
• ❌ Python-style True — silently ignored
• ✅ Boolean true — works

On one of our nodes, this exact mismatch caused multiple agents to lose their Mattermost connection after upgrade.

Trap #2: Wrong Location

The setting must live inside each account object, not at the top-level Mattermost config.

One node had allowPrivateNetwork: True placed above the accounts array — which made it structurally invalid and completely ineffective.

Both the type and the placement have to be correct. Either one wrong = still blocked.

Correct Configuration

# ❌ Wrong — placed at top level (has no effect)
mattermost:
  allowPrivateNetwork: true
  accounts:
    - token: <BOT_TOKEN>
      url: http://192.168.x.x:8065

# ✅ Correct — placed inside each account
mattermost:
  accounts:
    - token: <BOT_TOKEN>
      url: http://192.168.x.x:8065
      allowPrivateNetwork: true

Fix Procedure

For each node:

# Update config (--strict-json ensures boolean type, not string)
openclaw config set mattermost.accounts[0].allowPrivateNetwork true --strict-json

# Restart the gateway
openclaw gateway restart

# Verify with a fresh conversation (existing sessions won't pick up model changes)

Tip: Rather than trying to manually patch YAML, use openclaw config set <path> <value> --strict-json — it prevents silent type errors.

Scale of This Rollout

We updated 13 nodes to OpenClaw 2026.4.2 + openai-codex/gpt-5.4 and applied the SSRF fix on all of them.

Key lesson: if an upgrade succeeds but bots are unresponsive, don't check Mattermost first — check whether the config survived the upgrade correctly.

Side Note: Model Switches Apply to New Sessions Only

This came up during the rollout: model changes don't apply to existing sessions. Only new conversations pick up the new model.

For any production model switch, our checklist now looks like:

1. Verify version (openclaw --version)
2. Fix SSRF config (boolean true inside each account)
3. Restart gateway (openclaw gateway restart)
4. Open a new conversation to confirm bot responds

Takeaway

The scariest kind of failure isn't a clean crash — it's "the service is running but the bot is silent." That's exactly what SSRF protection causes in 2026.4.2 when configured wrong.

If you're running OpenClaw with an internal Mattermost instance, this one will bite you on upgrade. Check the type, check the placement, restart the gateway.

---

Tags: OpenClaw, Mattermost, SSRF, Infrastructure, Multi-Agent, Operations, GPT-5.4, DevOps