# Unvalidated name to executable resolution

User or repo-supplied names reaching exec, helper prefixes, or path joins without strict validation

_Area: Software supply chain and CI/CD. Seen in 3 disclosed reports; latest 2026-01-15. Updated 2026-11-02._

## How it works
A name that a user, repo, or config supplies is turned into something executable without being constrained to a safe set. The code assumes the name is a plain identifier, but it is really a string that flows into a command line, a helper-binary lookup, or a path. Three assumptions break: that a filter matches the whole value (it matches a substring), that a captured value is a fixed format (it accepts anything non-whitespace), and that a fixed prefix constrains what gets executed (path normalization can climb out of it). In each case the attacker controls what runs.

## Where it shows up
- Allow-list filters written as unanchored regexes, especially pipe-separated ID lists [E1](https://bugbountylibrary.com/r/blog%3Awiz-io-blog-wiz-research-codebreach-vulnerability-aws-codebuild.md)
- Comment/issue parsers whose captured group is interpolated into `exec(`/`execSync` with template literals [E2](https://bugbountylibrary.com/r/blog%3Ablog-ryotak-net-post-vscode-write-access.md)
- Regexes that accept `\S*` where only a hex hash is expected, and that match anywhere in text [E2](https://bugbountylibrary.com/r/blog%3Ablog-ryotak-net-post-vscode-write-access.md)
- Command handlers missing an authorization check on who may invoke them [E2](https://bugbountylibrary.com/r/blog%3Ablog-ryotak-net-post-vscode-write-access.md)
- Config values (e.g. credential helpers) passed to a resolver that prepends a fixed prefix and execs the result [E3](https://bugbountylibrary.com/r/h1%3A955016.md)
- Any exec path that relies on a string prefix for safety, on Windows especially [E3](https://bugbountylibrary.com/r/h1%3A955016.md)

## How to review
Trace every externally supplied name to its sink. The invariant: before a name reaches exec, helper lookup, or a path join, it must be validated against a strict anchored allow-list (full-string match, fixed format), and the caller must be authorized. For filters, confirm the regex is anchored (`^...$`) so superstrings cannot pass [E1](https://bugbountylibrary.com/r/blog%3Awiz-io-blog-wiz-research-codebreach-vulnerability-aws-codebuild.md). For parsers, confirm the captured value is format-checked and never concatenated into a shell string unquoted [E2](https://bugbountylibrary.com/r/blog%3Ablog-ryotak-net-post-vscode-write-access.md). For prefix-based resolution, confirm the resolved path stays inside the intended directory after normalization, on every OS [E3](https://bugbountylibrary.com/r/h1%3A955016.md).

## How finders spotted it
- Scanned public CI dashboards linked from commit statuses, saw pipe-separated ACTOR_ID filters, recognized them as regexes, and reasoned unanchored matching admits superstring IDs; then noted GitHub's sequential IDs create periodic collisions [E1](https://bugbountylibrary.com/r/blog%3Awiz-io-blog-wiz-research-codebreach-vulnerability-aws-codebuild.md)
- Reading CI scripts in a separate repo, spotted unquoted shell interpolation in exec, then traced the tainted value back through the code to issue comments and found the loose regex and missing auth check [E2](https://bugbountylibrary.com/r/blog%3Ablog-ryotak-net-post-vscode-write-access.md)
- Code reading of the credential-store resolver showed the `docker-credential-` prefix, then reasoned Windows path normalization ignores nonexistent directories, allowing traversal past the prefix [E3](https://bugbountylibrary.com/r/h1%3A955016.md)

## Variants seen
- Substring match in an allow-list regex (ID filter) [E1](https://bugbountylibrary.com/r/blog%3Awiz-io-blog-wiz-research-codebreach-vulnerability-aws-codebuild.md)
- Loose capture plus missing authorization in a comment command handler [E2](https://bugbountylibrary.com/r/blog%3Ablog-ryotak-net-post-vscode-write-access.md)
- Prefix-based helper resolution defeated by path traversal [E3](https://bugbountylibrary.com/r/h1%3A955016.md)

## Impact and severity
E1 leaked a PAT with admin over a major repo, enabling repo-admin escalation and potential NPM supply-chain compromise [E1](https://bugbountylibrary.com/r/blog%3Awiz-io-blog-wiz-research-codebreach-vulnerability-aws-codebuild.md). E2 gave write access to microsoft/vscode, bypassing release-branch protection via self-approved PRs [E2](https://bugbountylibrary.com/r/blog%3Ablog-ryotak-net-post-vscode-write-access.md). E3 achieved arbitrary program execution on the container host, chained with predictable mount paths [E3](https://bugbountylibrary.com/r/h1%3A955016.md). Severity rises with the token's scope and how far the compromised pipeline reaches.

## Seen in real software
Open-source packages and projects, and products, where this pattern was found. If the target runs one, compare the version it runs with the fix.
- **AWS CodeBuild** (ACTOR_ID webhook filter) (version not stated): CodeBreach: Infiltrating the AWS Console Supply Chain and Hijacking AWS GitHub Repositories via CodeBuild. Report: https://bugbountylibrary.com/r/blog%3Awiz-io-blog-wiz-research-codebreach-vulnerability-aws-codebuild.md
- **vscode-github-triage-actions** (getClosingInfo / releaseContainsCommit) (version not stated): VSCode triage bot: command injection via \closedWith comment. Report: https://bugbountylibrary.com/r/blog%3Ablog-ryotak-net-post-vscode-write-access.md
- **GitLab**: GitLab-Runner on Windows `DOCKER_AUTH_CONFIG` container host Command Injection. Report: https://bugbountylibrary.com/r/h1%3A955016.md

## Evidence
- E1: https://bugbountylibrary.com/r/blog%3Awiz-io-blog-wiz-research-codebreach-vulnerability-aws-codebuild.md
- E2: https://bugbountylibrary.com/r/blog%3Ablog-ryotak-net-post-vscode-write-access.md
- E3: https://bugbountylibrary.com/r/h1%3A955016.md
