EUVD-2026-38573Severity by source
AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H
Local hook on the developer host (AV:L); attacker is unprivileged injected content (PR:N) but needs the user to approve the Claude action (UI:R); arbitrary command execution yields C/I/A:H.
Primary rating from Vendor (GitHub_M).
CVSS VectorVendor: GitHub_M
Lifecycle Timeline
2DescriptionCVE.org
rtk filters and compresses command outputs before they reach your LLM context. Prior to 0.42.2, the permission splitter did not conservatively split or reject several shell constructs that Bash treats as command execution boundaries or nested execution. As a result, a command beginning with an allowed prefix such as git could hide a second command behind one of these constructs. rtk rewrite returned exit code 0, causing the Claude hook to emit permissionDecision: "allow". The rewritten command still contained the hidden command, so it ran without the user confirmation or denial that the permission rules were intended to enforce. This vulnerability is fixed in 0.42.2.
AnalysisAI
Authorization bypass in rtk (rtk-ai) prior to 0.42.2 allows hidden command execution to slip past the permission splitter that gates the Claude Code permission hook. Because the splitter fails to handle Bash command-execution boundary constructs (such as command substitution and chained operators) inside an allowlisted prefix like git, rtk rewrite returns exit code 0 and the hook emits permissionDecision: "allow", causing the secondary command to execute without the user confirmation the policy was supposed to require. No public exploit identified at time of analysis and the issue is not in CISA KEV.
Technical ContextAI
rtk is a command output filter/compressor used as a Claude Code permission hook: it parses shell commands before they execute, validates them against an allowlist, and returns a permissionDecision to the Claude harness. The vulnerable component is the permission splitter, which decomposes a candidate shell command into primitive commands so each can be checked against allowed prefixes. The root cause is CWE-863 (Incorrect Authorization): the splitter does not conservatively split or reject several Bash constructs that act as execution boundaries or nested execution - for example command substitution ($(...) / backticks), process substitution, pipelines, and conjunction operators (&&, ||, ;). Because the first token still matches an allowed prefix such as git, the splitter accepts the whole string and never evaluates the hidden secondary command. CPE cpe:2.3:a:rtk-ai:rtk:*:*:*:*:*:*:*:* indicates a single affected package family from the rtk-ai project.
RemediationAI
Vendor-released patch: upgrade rtk to 0.42.2 or later, which hardens the permission splitter to conservatively reject or split on Bash command-execution boundary constructs; details are in advisory GHSA-7gxq-fvfc-g327 (https://github.com/rtk-ai/rtk/security/advisories/GHSA-7gxq-fvfc-g327). Until the upgrade lands, tighten the Claude permission hook so rtk's allow decision is not authoritative - either remove rtk from the hook chain and fall back to interactive confirmation for every shell command, or shrink the allowlisted prefixes to commands that cannot meaningfully chain (avoid blanket prefixes like git, npm, sh, bash, env, xargs); the trade-off is more confirmation prompts and lost ergonomics for trusted workflows. As a defensive control, deny any candidate command containing $( , ` , ;, &&, ||, |, > (when not strictly required), or process-substitution <(...) before rtk sees it, accepting that this will reject some legitimate one-liners.
Same weakness CWE-863 – Incorrect Authorization
View allSame technique Authentication Bypass
View allShare
External POC / Exploit Code
Leaving vuln.today