Remote iMessage attachment fetches used SCP with trust-on-first-use host-key behavior and accepted unvalidated remote host tokens.
Before the fix:
- SCP used StrictHostKeyChecking=accept-new in the remote attachment path.
- channels.imessage.remoteHost was not validated as a strict SSH host token.
In remote iMessage deployments that use SCP attachment fetching, a first-connection MITM/DNS-poisoning scenario could cause the wrong host key to be trusted. Unsafe remote host token values could also alter SCP argument semantics.
openclaw (npm)2026.2.17<= 2026.2.17>= 2026.2.19The fix hardens remote attachment SSH/SCP handling by:
- requiring StrictHostKeyChecking=yes for SCP and SSH tunnel paths,
- adding strict remoteHost normalization/validation,
- adding -- argument barrier for SCP remote source parsing,
- validating channels.imessage.remoteHost in config schema,
- rejecting unsafe auto-detected host tokens at runtime.
main: 49d0def6d1e88f002026b1d2a35aa615d48a751aOpenClaw thanks @allsmog for reporting.
| Base score | Version | Severity | Vector |
|---|---|---|---|
| 5.3 | 4.0 | — |
|
| Type | Value |
|---|---|
| GHSA | GHSA-2mc2-g238-722j ↗ |
Vulnerable version ranges and first patched releases as published by GitHub.
| Ecosystem | Package | Vulnerable range | First patched | Vulnerable functions |
|---|---|---|---|---|
| npm | openclaw | <= 2026.2.17 | 2026.2.19 | — |