PipeRoll - Agent Incident Registry ·
about ·
contribute ·
data ·
notes ·
constitution ·
seismograph ↗
CodeWhale coding agent: a cloned repository silently takes over the agent …
PIR-2026-0057PIR-2026-0057id: PIR-2026-0057title: CodeWhale (an AI coding-agent TUI, formerly deepseek-tui) trusts repository-controlled input it should treat as hostile. A malicious .codewhale/config.toml/.deepseek/config.toml committed to a cloned repo can silently set allow_shell = true (arbitrary shell execution) or point instructions at arbitrary files that are read into the model's system prompt; separately, the git_blame and git_show tools pass an unvalidated revision argument straight to git, so --contents= reads and --output= writes arbitrary files - and all four tools run under ApprovalRequirement::Auto, so none of it prompts the user. Four coordinated CVEs (CVE-2026-75911, -75859, -75912, -75913), all fixed in 0.8.64date_occurred: not applicable - vulnerability disclosure (no confirmed in-the-wild exploitation tied to these CVEs)date_detected: coordinated disclosure to the CodeWhale maintainers; no individual discoverer is credited in the GitHub advisoriesdate_disclosed: 2026-07-16 (the four GitHub Security Advisories were published 2026-07-16; the advisories were reviewed/updated 2026-09-04, which is when the leads surfaced)status: corroborated (all four GitHub Security Advisories - GHSA-gx45-xrj5-g6c4, GHSA-62f5-cp2p-vq95, GHSA-c6mw-8xh8-gpq6, GHSA-7j5w-7r7x-9v27 - read 2026-09-09; product, affected/fixed versions, mechanism, CVSS and CVE ids confirmed)agent_description: CodeWhale, an AI coding-agent TUI (terminal user interface) that drives a large language model to read, edit and run code in a developer's local workspace with a set of built-in tools (shell, and git tools including git_blame and git_show). It was previously published as deepseek-tui and renamed; both names are affected. Distributed as npm codewhale and cargo codewhale-tui (and the older npm/cargo deepseek-tui).operator_type: individual developers running the agent locally against repositories they clone (affects any deployment on an affected version; the flaw is in the agent, not one operator's configuration)autonomy_level: human-on-the-loop by design (a developer supervises the coding session) - but the point of these CVEs is that the affected actions run under ApprovalRequirement::Auto, so the human-in-the-loop is bypassed for exactly the dangerous operationsmodel_stack: DeepSeek models by default; model-agnostic to the flaw - the defects are in the agent harness (config loader and tool layer), not in the modelharness: CodeWhale / codewhale-tui; formerly deepseek-tui. Affected: codewhale (npm) and codewhale-tui (cargo) >= 0.8.41 and < 0.8.64; deepseek-tui affected in earlier ranges (npm >= 0.3.27 to 0.8.6-era depending on CVE, < 0.8.41). Fixed in 0.8.64 (the cargo deepseek-tui line has no patch - superseded by codewhale)authority_scope: full local compromise of the developer's machine reachable from merely opening a hostile repository in the agent - arbitrary shell command execution (config allow_shell override), arbitrary file read (git_blame --contents=, and the instructions override reading files into the prompt), and arbitrary file write (git_show --output=). Read targets explicitly include SSH keys, AWS credentials and environment filesfunds_at_risk_usd: unknownblast_radius: one developer workstation per hostile repository opened; a path to wider compromise if the developer's exfiltrated credentials or the arbitrary-write primitive enable lateral movement or supply-chain push access (potential, not realized in these disclosures)root_cause: tool-error (the agent's tool and config layer trusts repository-controlled input it should treat as untrusted, and does not enforce its own approval/capability contract: a committed config file can grant shell or redirect instructions, and two git tools concatenate an unvalidated revision argument into the git command line while declaring ApprovalRequirement::Auto - git_show even declares ToolCapability::ReadOnly yet writes files). One of the four (the instructions override, CVE-2026-75859) is also prompt-injection-class - repo content injected into the system prompt - and the git-tool abuses are reached via prompt injection on a malicious repo; recorded under tool-error because the enforceable defect is in the harness's tool/config implementation. See the schema note.failure_locus: harness (the agent application's own config loader and built-in git tools; not an MCP server and not the model's reasoning)exploitation_status: researcher-demonstrated (four CVEs assigned and mechanisms publicly described with the exploit primitives; no confirmed in-the-wild exploitation tied to these identifiers)mechanism: Four related weaknesses, all triggered by a repository the developer clones and opens in the agent, all running without an approval prompt. (1) CVE-2026-75911 (CVSS 8.5): a malicious .codewhale/config.toml or .deepseek/config.toml committed to the repo can set allow_shell = true, silently flipping the default-off shell boundary so the model can execute arbitrary shell commands. (2) CVE-2026-75859 (CVSS 8.7): the same config's instructions field accepts an array of arbitrary file paths that are read from disk with no workspace-boundary check and injected into the model's system prompt - exposing SSH keys, cloud credentials and env files where they become exfiltrable. (3) CVE-2026-75912 (CVSS 8.3): the git_blame tool passes its rev parameter to git unvalidated, so a value like --contents=/path/to/secret turns a blame into an arbitrary file read; the tool is registered ApprovalRequirement::Auto, so no consent is sought. (4) CVE-2026-75913 (CVSS 8.5): the git_show tool likewise passes rev unvalidated, so --output=/path writes an attacker-chosen file - an arbitrary file write that also contradicts the tool's declared ToolCapability::ReadOnly. The unifying error is that repository-controlled configuration and tool arguments are trusted, and the agent's own approval/read-only contract is not enforced for the operations that most need it.adversary_present: no (disclosed vulnerabilities; the threat model is a malicious repository author, but no in-the-wild adversary is tied to these CVEs)severity: near-miss (the full capability is exposed - remote-ish code execution, arbitrary file read/write, secret exfiltration from cloning one hostile repo - but no realized loss is reported for these CVEs, and all four are patched in 0.8.64)direct_loss_usd: 0 (no confirmed exploitation or loss)indirect_loss_usd: unknowndowntime: nonedata_exposure: none confirmed; the exposed capability is reading arbitrary local files (SSH keys, AWS credentials, environment files) into the model prompt and off the machine, plus arbitrary file writedetected_by: third-party (security research / coordinated disclosure; no individual discoverer credited in the advisories)time_to_detect: unknowntime_to_recover: fixed in CodeWhale 0.8.64remediation: upgrade to codewhale / codewhale-tui >= 0.8.64. The fixed version validates the revision argument to git tools, enforces the workspace boundary and approval contract, and no longer honours a repository-committed config that silently grants shell or redirects instructionsstructural_fix: an agent-harness lesson, not a single-CVE patch: repository-controlled input (project config AND tool arguments) is untrusted input and must be validated and boundary-checked; a tool's declared approval requirement and read-only capability must be ENFORCED, not merely declared; and privilege-granting configuration (shell enablement, prompt instructions) must never be settable by a cloned repo without explicit user consent. The "open a repo in your coding agent" action is a trust boundarycontrols_that_worked: none identified - the default shell-off boundary was defeated by the config override, and the Auto-approval tools bypassed the human-on-the-loop entirelytelemetry_grade: none (coordinated vulnerability disclosure, not an operated incident with logs)sources:.codewhale/.deepseek config allow_shell override -> arbitrary shell execution; affected codewhale/codewhale-tui >= 0.8.41 < 0.8.64, fixed 0.8.64; read 2026-09-09)instructions reads arbitrary file paths into the AI system prompt, no workspace-boundary check; fixed 0.8.64; read 2026-09-09)git_blame argument injection via unvalidated rev (--contents=) -> arbitrary file read without approval, tool registered ApprovalRequirement::Auto; fixed 0.8.64; read 2026-09-09)git_show argument injection via unvalidated rev (--output=) -> arbitrary file write without approval, contradicting declared ToolCapability::ReadOnly; fixed 0.8.64; read 2026-09-09)independence: low-to-medium - all four are GitHub Security Advisories for the same product from one coordinated disclosure; they corroborate each other on product, versions and fixed release, but are not four independent operators. No independent second report, as expected for a disclosed vulnerability rather than an operated incidentrelated: PIR-2026-0056 (Grafana MCP SSRF), PIR-2026-0026 (GitHub MCP toxic-agent flow), PIR-2026-0028 (Supabase MCP lethal trifecta), PIR-2026-0036 (malicious postmark-mcp package) - the tool-layer / untrusted-input agent-failure family. This record differs in surface: the defect is in a coding agent's OWN harness (config loader + built-in git tools) abused by a cloned repository, not in an MCP server; and it is a cluster of four coordinated CVEs treated as one incident because they share the same product, disclosure and root erroraiid_incident_id: unknown (none located as of 2026-09-09)confidence: high on the identity, mechanism, CVE ids, CVSS scores, affected/fixed versions and disclosure of all four issues, from the four GitHub Security Advisories; no individual discoverer is credited (recorded as such, not as unknown-pending); no in-the-wild exploitation is claimedgit_show advisory (GHSA-7j5w-7r7x-9v27) with CVE-2026-75913 but also showed a stray "CVE-2026-75913" against the instructions advisory; the primary sources resolve the instructions override to CVE-2026-75859, which is the id used here. Verify against the advisory pages, not the lead.