TL;DR: WebdriverIO BrowserStack Service versions through 9.23.2 contain a critical command-injection flaw that lets attacker-controlled branch names reach execSync during smart-selection test orchestration, creating a path from test execution to arbitrary shell commands, according to Corgea. The issue shows how CI runners can turn repository metadata into supply-chain execution risk when secrets, tokens, and deployment credentials are present.
At a glance
What this is: Corgea reports a critical command-injection flaw in WebdriverIO BrowserStack Service smart-selection logic that lets attacker-controlled branch names reach shell execution.
Why it matters: It matters because CI/CD test runners often hold deploy, cloud, and token credentials, so a test helper flaw can become a supply-chain compromise path.
By the numbers:
- @wdio/browserstack-service versions through 9.23.2 are affected, and 9.24.0 is the fixed release.
Context
A CI/CD test orchestrator is part of the application supply chain when it executes code before release and has access to repository, cloud, and deployment credentials. In this case, the security gap is not in browser automation itself but in how untrusted Git metadata is turned into shell input during smart-selection processing.
That distinction matters for CI/CD security teams because test pipelines often run against forks, sample repositories, or attacker-influenced checkouts. When branch names, refs, or source paths are treated as trusted command fragments, the pipeline stops being a validation layer and becomes an execution surface.
Key questions
Q: What breaks when repository metadata is passed into shell commands during CI test orchestration?
A: Command injection becomes possible because the shell treats branch names, paths, and other metadata as executable syntax rather than data. In CI, that can expose tokens, tamper with build artefacts, or pivot into deployment systems. The safe pattern is to avoid shell-string execution entirely and restrict orchestration code to literal argument handling.
Q: Why do CI test runners increase the impact of command-injection flaws?
A: CI runners usually have broader access than a developer laptop because they can read source, fetch packages, publish artefacts, and reach cloud services. If an injected command lands there, the attacker inherits the runner’s non-human identities and any cached secrets. Least privilege on the runner matters as much as patching the vulnerable package.
Q: How do security teams detect whether test orchestration is exposed to shell injection?
A: Look for any code path that constructs shell commands from branch names, repository paths, or other Git metadata, especially when exec-style helpers are used. Then inspect CI logs for unexpected shell syntax, unusual temporary-file writes, and outbound network calls during test startup. Those are common indicators that untrusted input reached command execution.
Q: When should organisations treat test tooling as part of supply-chain security?
A: As soon as the tooling runs before release and can reach build secrets, registry tokens, or deployment identities. At that point it is not just test automation. It is privileged automation that can affect code integrity, credential exposure, and delivery trust, so it belongs in the same governance model as other release-path controls.
Technical breakdown
How shell-string execution turns branch names into commands
The vulnerable pattern is string-based command construction. Here, a helper reads Git branch names and inserts them into an execSync() call, which passes the string to a shell instead of invoking Git directly with safe argument handling. That matters because shells interpret metacharacters, variable expansion, and command separators before the underlying process ever sees the input. Git branch names are not inherently dangerous, but they become dangerous when a program assumes they are already sanitized command text. In test orchestration, that turns repository metadata into an attack primitive.
Practical implication: Use argument-array process execution for untrusted values and never build shell commands from ref names or repository metadata.
Why CI/CD runners expand the blast radius
CI runners are high-value execution environments because they usually sit close to release authority. They can hold source access, BrowserStack credentials, package registry tokens, cloud deployment keys, SSH material, and cached build artifacts. A command-injection bug in test orchestration does not need to steal everything at once to be serious. It only needs enough code execution to read secrets, tamper with artifacts, or pivot into later pipeline stages. That is why a flaw in a test helper belongs in supply-chain risk management, not just application testing hygiene.
Practical implication: Treat test runners as privileged supply-chain nodes and scope their credentials as if a dependency compromise were already possible.
Why smart selection changes the trust boundary
BrowserStack smart selection increases the risk surface because it uses local repository state to decide what to run. That means the code path relies on current branch data, base branch data, and source repository assumptions before tests even start. When source is unset, the helper can fall back to the current directory, which widens exposure to any attacker-controlled checkout that reaches the runner. The trust boundary is therefore not the browser session. It is the pre-test orchestration layer that interprets repository metadata and assembles commands.
Practical implication: Separate trusted repositories from untrusted checkouts and disable smart-selection paths when the source cannot be fully controlled.
Threat narrative
Attacker objective: The attacker wants arbitrary command execution inside a privileged test environment so they can steal secrets or alter release integrity.
- Entry occurs when an attacker controls a repository, fork, or checkout whose branch name contains shell metacharacters that the helper later processes.
- Credential access follows when the injected shell command executes inside a CI runner or developer workstation that already has access to release, cloud, or registry secrets.
- Impact occurs when the attacker uses that execution to steal credentials, tamper with test outputs, or pivot into downstream supply-chain compromise.
Breaches seen in the wild
- Gravity SMTP CVE-2026-4020 API Keys Exposure: CVE-2026-4020 in Gravity SMTP exposes API keys via single HTTP request across 100,000 WordPress sites.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Test orchestration is now supply-chain infrastructure, not supporting code. The moment a test helper runs before release with access to tokens, cloud credentials, and publishing paths, it becomes part of the trust chain. This article shows that a command-injection flaw in orchestration code can be as consequential as a production dependency bug. Practitioners should classify pre-release test execution as a privileged control plane, not a harmless utility.
Repository metadata is a governance boundary, not just developer input. Branch names, refs, and source paths look operationally ordinary, but they are attacker-controlled data in any forked or external checkout model. The failure here is the assumption that Git metadata is safe to interpolate into shell context. That assumption breaks the moment untrusted repositories are allowed into the pipeline, so CI policy must treat metadata as hostile until proven otherwise.
Smart-selection logic creates a hidden trust shortcut. Optimisation features often narrow test scope by reading repository state and inferring what changed, but that inference step is exactly where shell injection can land. The named concept here is metadata-to-command drift, where data used for orchestration silently crosses into execution. Security teams should regard any build-time optimisation that consumes ref names as a control boundary, not a convenience feature.
Supply-chain impact comes from credential adjacency, not just code execution. The practical consequence of this class of flaw is not merely local command execution. It is access to whatever the runner can reach next, including artifact stores, registry tokens, and deployment identities. In identity terms, this is an NHI governance problem as much as an application issue because CI systems often authenticate as long-lived service accounts. The control failure is excessive trust in the runner’s execution context.
Fixing the shell call matters more than validating one input field. Validation alone is weaker than removing the shell from the trust path, because any future metadata field can become the next injection source. The broader lesson for practitioners is to govern test orchestration like other privileged automation: reduce standing access, constrain sources, and make command execution explicit. That is the only durable way to keep a test helper from becoming an attack helper.
From our research library:
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs.
- Read next: CI/CD Pipeline Identity Security Guide
What this signals
Metadata-to-command drift: build and test pipelines fail when orchestration logic treats repository metadata as executable text. That failure mode is especially dangerous in CI/CD because branch names and ref values are often attacker-controlled in fork and sample-repository workflows.
CI/CD teams should assume that any runner capable of accessing cloud, registry, or deployment credentials is a privileged identity and govern it accordingly. If the runner can execute shell strings from untrusted input, the issue is identity exposure as much as application security.
The practical boundary is simple: move from shell interpretation to explicit argument handling, and keep untrusted repositories away from smart-selection code paths that infer execution decisions from Git state.
For practitioners
- Replace shell-string execution in test helpers Use spawnFile, execFile, or equivalent argument-array APIs for any command that consumes repository metadata, branch names, or ref values.
- Disable smart selection for untrusted checkouts Turn off BrowserStack smart selection when pipelines run against forks, sample repositories, generated repositories, or any source path you do not fully control.
- Rotate credentials exposed to vulnerable runners Review and rotate CI provider tokens, BrowserStack credentials, npm tokens, GitHub tokens, cloud credentials, SSH keys, and deployment secrets if the runner executed vulnerable orchestration.
- Scan dependency trees for affected versions Check package manifests and lockfiles for @wdio/browserstack-service 9.23.2 or earlier, then prioritise remediation where runSmartSelection is enabled.
- Tighten source control around test orchestration Separate trusted source paths from attacker-controlled checkouts and ensure fallback to the current directory cannot occur in privileged CI jobs.
Key takeaways
- This flaw shows how test orchestration can become an execution path when repository metadata is treated as trusted input.
- The blast radius is amplified by the credentials CI runners already hold for publishing, deployment, and external services.
- The durable fix is to remove shell interpretation from untrusted data and restrict smart-selection to controlled sources.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK and OWASP API Security Top 10 address the attack and risk surface, while CIS Controls v8, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | TA0006; TA0008 — Credential Access; Lateral Movement | The exploit path leads from code execution to credential exposure and potential pivoting in CI runners. |
| Recommendation — Map the runner exposure to TA0006 and TA0008, then hunt for command-injection paths in build orchestration. | ||
| CIS Controls v8 | CIS-5 — Account Management | CI runners and pipeline identities need tight account governance because they often hold release authority. |
| Recommendation — Apply CIS-5 to inventory runner identities and remove unnecessary access from pipeline accounts. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The issue is driven by over-trusted execution context and excessive runner permissions. |
| Recommendation — Use PR.AA-05 to constrain runner entitlements and separate trusted from untrusted test execution paths. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | The advisory explicitly recommends rotating secrets reachable by compromised runners, which maps to authenticator lifecycle control. |
| Recommendation — Apply IA-5 to govern, rotate, and revoke credentials exposed to privileged CI test runners. | ||
| OWASP API Security Top 10 | API8 — Security Misconfiguration | The vulnerable orchestration path reflects unsafe handling of untrusted input and execution context. |
| Recommendation — Treat the command-building path as a misconfiguration and remove shell execution from the trust boundary. | ||
Key terms
- Command injection: Command injection occurs when attacker-controlled data is inserted into a shell command and changes what the process executes. In AI tooling, that often happens through wrappers, plugins, or installation flows that turn paths or prompts into shell strings. The impact is privilege abuse through the process’s inherited authority.
- Test Supply Chain: The test supply chain is the set of tools, runners, dependencies, and orchestration logic that executes before release. It matters because compromise at this layer can alter build outcomes, expose secrets, or create a path into downstream delivery systems.
- Smart Selection: Smart selection is a test optimisation pattern that uses repository state and change detection to choose which tests to run. It reduces work, but it also increases trust in metadata sources that may be attacker-controlled in forked or external repository scenarios.
- CI Runner Identity: A CI runner identity is the set of credentials and permissions a build or test runner uses while executing pipeline tasks. In NHI terms, it is a machine identity with real authority, often able to read secrets, access repositories, and publish artefacts if controls are too broad.
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps security and platform teams align identity controls with the privileged automation that underpins modern delivery pipelines.
Published by the NHIMG editorial team on August 21, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org