OpenClaw Just Patched 40+ Security Holes. You Should Pay Attention.
2026-02-19
openclaw shipped a massive security release this month. 40+ fixes across three releases (v2026.2.12 through v2026.2.17), two published GHSAs, and a breaking change to how canvas authentication works. SecureClaw launched the same week as a third-party security audit tool. steinberger left for openai. the openclaw foundation is now a thing.
that’s a lot happening in two weeks. and if you’re running openclaw agents against your own backends — or building tools that interact with them — some of this directly affects you.
let me break down what actually changed and why it matters.
the big one: session management hardening
v2026.2.12 overhauled how openclaw handles ACP bridge sessions. before this release, there was no idle-session reaping, no eviction cap, and no burst rate limiting on session creation. that means a malicious or misbehaving client could create sessions faster than the bridge could handle them — a local denial-of-service vector that’s been sitting there since the ACP bridge was introduced.
the fix adds four mechanisms: duplicate-session refresh (reuse instead of recreate), idle-session reaping (clean up what’s not being used), oldest-idle soft-cap eviction (keep the total under control), and burst rate limiting on session creation (throttle the creation path itself).
if you’re running any kind of gateway or proxy in front of openclaw — including gatewaystack — this matters because session exhaustion on the openclaw side could cascade upstream. your gateway might be healthy, but if the agent runtime behind it is choking on session management, your users see the same failure.
tool blocking defaults changed
this is the one that’ll break things if you’re not paying attention.
openclaw now blocks high-risk tools from HTTP /tools/invoke by default. previously, any tool registered in the agent was callable via the HTTP bridge. now there’s a gateway.tools.{allow,deny} configuration, and the default posture is restrictive.
more importantly, ACP permission selection now fails closed when tool identity or options are ambiguous. if the system can’t confidently determine which tool you’re trying to invoke or what permissions apply, the answer is “no” instead of “best guess.”
this is the right call. we’ve been running deny-by-default in gatewaystack’s validatabl module since day one. but if you have existing integrations that rely on openclaw’s HTTP tool bridge, they might stop working after the upgrade. check your tool registrations.
path traversal containment
v2026.2.12 added realpath checks on plugin loading, hook handler modules, and runtime package paths. this blocks symlink-based escapes and path traversal attacks where a malicious plugin could reference files outside its intended directory.
the two GHSAs published on february 18 are related:
GHSA-h7f7-89mm-pqh6 — skill download target directory validation. a crafted skill could write files outside the expected download path.
GHSA-mmpf-jwf4-h3qv — option injection in pre-commit hooks that could stage ignored files. if you’re using openclaw’s git integration with hooks, an attacker could manipulate which files get committed.
both are fixed in the latest release. update.
canvas auth tightening (breaking change)
v2026.2.13 changed how canvas IP-based authentication fallback works. previously, any IP that matched the expected source could authenticate without a bearer token. now, only RFC1918, link-local, ULA IPv6, and CGNAT addresses get the IP fallback. public-source IP matches require bearer token auth.
this is a breaking change if you’re accessing openclaw’s canvas from a public IP without a token. the fix is straightforward — add bearer token auth to your canvas clients — but it’ll break silently if you don’t.
what this means if you’re running gatewaystack
gatewaystack doesn’t directly depend on openclaw. there’s no npm dependency, no API coupling. but there are two concrete touchpoints:
first: injection patterns. gatewaystack’s transformabl module ports openclaw’s prompt injection and extraction detection patterns. the comment in patterns.ts explicitly cites openclaw’s EXTRACTION and INJECTION_PATTERNS_MULTILANG as sources. openclaw’s security overhaul almost certainly updated these patterns — new attack vectors, refined regexes, reduced false positives. we need to diff and pull.
second: architectural alignment. openclaw just moved to the same posture gatewaystack has had from the start — deny-by-default tool authorization, fail-closed on ambiguity, session lifecycle management. that’s validating. but openclaw’s session hardening exposes a gap in gatewaystack: we handle per-workflow rate limiting and budget caps through limitabl, but we don’t have explicit session lifecycle management (idle reaping, eviction, burst control on creation). if you’re running persistent MCP sessions through the gateway, that’s worth adding.
the bigger picture
here’s what i keep coming back to.
openclaw is an agent runtime. it runs your agent, manages your conversations, connects to your channels. it’s good at that. but this month’s security crisis — 40+ vulnerabilities, two GHSAs, a breaking auth change, and the founder leaving — is a reminder that agent runtimes are attack surfaces, not governance surfaces.
the system prompt is the lock on the front door. the runtime is the building itself. but neither of them is the security system.
the security system is the layer that sits between the agent and your services. the layer that verifies identity regardless of which runtime sent the request. the layer that enforces policy even when the runtime has a bad day. the layer that keeps audit logs even when the runtime is being patched.
openclaw’s 40 patches are all things that needed fixing. but the fact that they needed fixing at all is the argument for why governance belongs outside the runtime.
every one of these vulnerabilities — session exhaustion, path traversal, permissive tool access, IP auth bypass — would have been mitigated by a control plane that enforces identity, authorization, and audit independently of the agent runtime. not because the control plane is magically immune to bugs, but because it’s a separate trust boundary. the runtime being compromised doesn’t compromise the governance.
what to do right now
if you’re running openclaw:
update to v2026.2.17. check your gateway.tools.allow and gateway.tools.deny configuration. if you’re accessing canvas from a public IP, add bearer token auth. review any custom skills and hooks for the path traversal patterns that were just patched.
if you’re running gatewaystack:
we’ll be updating the ported injection patterns in transformabl to match openclaw’s latest. watch the repo. and if you’re running persistent MCP sessions, consider adding session lifecycle controls — we’re evaluating whether to add this to limitabl or as a separate module.
if you’re building on any agent runtime:
this is the argument for separating your governance layer from your agent runtime. not because openclaw is bad — it’s not, and they handled this well — but because governance that depends on the runtime’s security is governance that fails when the runtime fails.
that’s the whole point of an agentic control plane. and openclaw just proved why it matters.
GatewayStack is open source (MIT) user-scoped AI governance for agentic systems. Visit agenticcontrolplane.com to learn more.