GHSA-w5c7-9qqw-6645
OpenClaw inter-session prompts could be treated as direct user instructions
Blast Radius
Weekly download volume for affected packages — a proxy for how broadly this vulnerability is deployed.
openclawnpmDescription
Summary
Inter-session messages sent via sessions_send could be interpreted as direct end-user instructions because they were persisted as role: "user" without provenance metadata.
Affected Packages / Versions
- Package:
openclaw(npm) - Affected versions:
<= 2026.2.12(i.e.< 2026.2.13) - Fixed in:
2026.2.13(patched versions>= 2026.2.13)
Impact
A delegated or internal session could inject instructions into another session that appeared equivalent to externally-originated user input.
This is an instruction-provenance confusion issue (confused-deputy style), which can lead to unintended privileged behavior in workflows that trust role: "user" as a sole authority signal.
Technical details
Before the fix, routed inter-session prompts were stored as regular user turns without a verifiable source marker.
As a result, downstream workers and transcript readers could not distinguish:
- External user input
- Internal inter-session routed input
Fix
OpenClaw now carries explicit input provenance end-to-end for routed prompts.
Key changes:
- Added structured provenance model (
inputProvenance) withkindvalues includinginter_session. sessions_sendand agent-to-agent steps now set inter-session provenance when invoking target runs.- Provenance is persisted on user messages as
message.provenance.kind = "inter_session"(role remainsuserfor provider compatibility). - Transcript readers and memory helpers were updated to respect provenance and avoid treating inter-session prompts as external user-originated input.
- Runtime context rebuilding now annotates inter-session turns with an explicit in-memory marker (
[Inter-session message]) for clearer model-side disambiguation. - Regression tests were added for transcript parsing, session tools flow, runner sanitization, and memory hook behavior.
Fix Commit(s)
85409e401b6586f83954cb53552395d7aab04797
Workarounds
If immediate upgrade is not possible:
- Disable or restrict
sessions_sendin affected environments. - Do not use role alone as an authority boundary; require provenance-aware checks in orchestration logic.
Credit
Reported by @anbecker.
Thanks @anbecker for reporting.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | openclaw | all versions | 2026.2.13 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for openclaw. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update openclaw to 2026.2.13 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-w5c7-9qqw-6645 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-w5c7-9qqw-6645 is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-w5c7-9qqw-6645. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-w5c7-9qqw-6645 in your dependencies?
O3 detects GHSA-w5c7-9qqw-6645 across npm dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.