Crabbox EUVD-2026-30418

Exploitation requires the victim developer to use Crabbox's remote command execution feature (crabbox run) against a repository containing a malicious .crabbox configuration file with overly permissive environment variable allowlisting directives. The attacker must control or compromise the target repository to modify the Crabbox configuration file, achievable through direct repository ownership, accepted pull requests in open-source projects, or compromised maintainer accounts. The victim's local environment must contain valuable secrets as environment variables (common in developer workflows using cloud CLIs, CI/CD tools, and package managers that read credentials from environment). The vulnerability does NOT require: network services exposed by the victim, administrative privileges, or specific Crabbox provider backends (affects all AWS/Azure/Proxmox/Tensorlake configurations equally). Exploitation is LIMITED by: developer security awareness to review configuration changes in untrusted repositories before running remote commands, organizational policies restricting Crabbox usage to vetted internal repositories only, and use of credential management tools (vaults, keychains) instead of environment variables for secrets. The CVSS vector PR:N reflects that attackers need no Crabbox authentication but DO require social engineering to convince developers to run commands against malicious repos.

Despite the 9.3 CVSS score indicating critical severity, real-world risk is moderate and highly context-dependent. The CVSS vector correctly identifies AV:N/AC:L/PR:N but the attack requires significant social engineering: developers must clone and run commands against attacker-controlled or compromised repositories, AND have valuable secrets in their local environment, AND use Crabbox's remote execution features against untrusted repos. The VC:H/VI:H ratings reflect that once exploited, attackers gain full access to forwarded credentials, potentially enabling lateral movement to cloud infrastructure or CI/CD systems. However, no public exploit identified at time of analysis and no EPSS data provided (suggesting low observed exploitation). The vulnerability is NOT a wormable RCE but rather a supply-chain-style credential exfiltration vector targeting developers in the software supply chain. Priority depends on organizational Crabbox adoption: critical for teams using Crabbox with cloud credentials in developer environments, low for organizations not using the tool. The patch in v0.12.0 fundamentally redesigns environment forwarding with explicit opt-in (--allow-env flags) rather than configuration-file-driven allowlisting, significantly reducing attack surface. Key missing data: EPSS score, KEV status (assumed negative given recent 2026 CVE), and real-world exploitation reports.

An attacker publishes a malicious open-source repository or compromises an existing legitimate repository by submitting a pull request that modifies the .crabbox configuration file to include broad environment variable allowlisting (e.g., patterns matching GITHUB_TOKEN, AWS_*, NPM_TOKEN). A developer clones the repository and runs crabbox run to test the code in a remote environment as part of their normal workflow. Crabbox reads the malicious configuration, serializes the developer's local environment variables matching the attacker-controlled allowlist, and forwards them into the remote execution context. The attacker-controlled code running in the remote environment captures these forwarded secrets (via simple env > /tmp/exfil.txt commands embedded in build scripts or test harnesses) and exfiltrates them to attacker infrastructure. The attacker then uses the stolen cloud credentials or API tokens to access the victim organization's AWS accounts, GitHub repositories, or package registries. No public exploit identified at time of analysis, but the attack vector requires only basic repository manipulation and knowledge of common secret environment variable naming conventions.