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.
{
"nvd_published_at": null,
"github_reviewed_at": "2026-03-03T21:35:21Z",
"github_reviewed": true,
"cwe_ids": [
"CWE-295",
"CWE-78"
],
"severity": "MODERATE"
}