All Things OpenClawAll Things OpenClaw
SECURITY • OpenClaw quick fix
Featured: @steipete

OpenClaw allowlists: use stable sender IDs, not names.

A recent OpenClaw advisory is a good reminder for anyone letting chat messages trigger elevated tools: mutable usernames and display-style metadata can drift away from the stable sender you meant to trust. For Telegram, the verified GitHub advisory calls out mutable usernames directly; for other channels, treat the same class as an audit pattern, not a blanket claim. Use stable platform IDs where possible, keep name matching opt-in and documented, and smoke-test the channel before resuming unattended work.

In simple words: Make a safe copy if the step could change your setup, try the smallest check, then confirm OpenClaw is back to normal before doing more. The source link and commands stay below for people who want the technical detail.

Checklist
Find every channel or command path where a chat sender can approve elevated tools, run workflows, or trigger sensitive actions.
Allowlist audit sheet
- Channel / integration:
- Sensitive action or elevated tool path:
- Current allowlist entries:
- Stable sender ID to use instead:
- Is any name/username/tag matching still enabled? why?
- Negative test result:
- Positive test result:
- Rollback label before the config edit:
Replace display-name, username, or tag allowlist entries with stable sender IDs when the channel supports them — for example Teams AAD object IDs, platform sender IDs, E.164 phone identifiers, or channel-specific `accessGroup:<name>` entries made from stable IDs.
Safer config shape to review, not paste blindly
{
  "accessGroups": {
    "operators": {
      "type": "message.senders",
      "members": {
        "msteams": ["aad-object-id-or-stable-sender-id"],
        "telegram": ["987654321"],
        "whatsapp": ["+15551234567"]
      }
    }
  }
}
If you must use mutable metadata matching, make the opt-in visible in the config and write down why it is acceptable for that channel; do not let it hide inside a broad fallback.
After changing allowlists, run one negative test from an unapproved sender and one positive test from the intended operator before re-enabling unattended or elevated tasks.
Record the OpenClaw version, channel, matched ID, and rollback label so the next update does not reintroduce name-based trust by accident.
Success looks like
• Elevated or sensitive sender allowlists are based on stable sender identity, not mutable display names.
• Any remaining name, username, or tag matching is explicitly opted in and documented as a conscious risk tradeoff.
• A negative and positive channel smoke test proves the allowlist still blocks strangers while preserving the intended operator path.

Source: GitHub advisory + OpenClaw Teams/access-group docs · link