WebdriverIO BrowserStack command injection shows test supply chain risk

At a glance

What this is: Corgea reports a critical command-injection vulnerability in WebdriverIO BrowserStack Service smart-selection logic that can turn attacker-controlled branch names into shell execution.

Why it matters: It matters because CI/CD and test orchestration often run with privileged tokens and secrets, so a testing helper can become an application supply chain breach path.

By the numbers:

• CVE-2026-25244 carries a GitHub CVSS 3.1 score of 9.8 critical.
• @wdio/browserstack-service versions through 9.23.2 are affected, and 9.24.0 is fixed.

👉 Read Corgea's analysis of CVE-2026-25244 in WebdriverIO BrowserStack Service

Context

Command injection is a control failure, not a browser automation failure. When test orchestration code concatenates untrusted repository metadata into shell commands, the security boundary shifts from application testing to execution of attacker-controlled input, which is a supply chain issue with direct identity and secrets exposure implications for CI/CD runners.

This matters to IAM, PAM, and NHI teams because build and test systems routinely hold non-human identities such as API tokens, deployment keys, and service credentials. If a runner can be steered into arbitrary command execution, those credentials become the next target, and the starting position described here is unfortunately common in modern pipelines.

The article’s core lesson is that local tooling can become a high-impact attack surface when it trusts Git metadata. That pattern is especially relevant where repositories are external, pull requests are untrusted, or smart-selection logic reaches into the current checkout without strict input handling.

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 know whether a test helper is creating supply chain risk?

A: Look for utilities that execute before deployment gates, consume untrusted repository inputs, and run with secrets capable of publishing, deploying, or authenticating to external services. If a helper reads Git metadata and invokes a shell, it is already a supply chain control point. Dependency review should include execution context, not just package version.

Q: Who is accountable when a CI runner leaks credentials after a test-tool vulnerability?

A: The accountable owner is the team that controls the runner, the package allowance, and the secrets issued to the job. Security, platform, and engineering teams share responsibility, but the remediation decision sits with the system owner. Control frameworks such as NIST SP 800-53 and CIS Controls both expect explicit access governance and change control.

Technical breakdown

How Git branch names become shell payloads

The flaw is not in Git itself. It appears when branch names, which are attacker-influenced strings in an untrusted repository, are inserted into a shell command through string interpolation. In this case, the helper builds a git diff command with baseBranch and currentBranch, then hands the full string to execSync(), which invokes a shell. Shell metacharacters such as semicolons and expansions are then interpreted as commands, not data. The issue is a classic command-injection pattern where trusted context is assigned to untrusted input.

Practical implication: remove shell-string execution from test helpers that consume repository metadata.

Why smart selection increases the blast radius

BrowserStack test orchestration smart selection is designed to reduce test scope by reading local Git metadata. That convenience creates a risky dependency on the repository source and current working directory, especially when source is unset and the helper falls back to the checkout in front of it. In a CI runner, that checkout may be attacker-controlled through a fork, sample project, or generated repository. Once the test orchestration path runs before deployment gates, it becomes a pre-release execution point with access to the environment’s non-human identities and cached artefacts.

Practical implication: restrict smart-selection features to trusted repositories and trusted checkout paths only.

Why shell invocation is the wrong boundary for untrusted refs

Using execSync() with a single string hands parsing to the shell, which is the wrong trust boundary for any value derived from outside the application. Safer patterns are execFile(), spawn(), or argument-array equivalents that bypass shell interpretation and preserve literal handling of branch names. Even then, validation still matters for ref names, but validation is secondary to avoiding shell execution entirely. Git separators can help with path handling, yet they do not neutralise command injection once shell parsing has already occurred.

Practical implication: use argument-array process execution and validate refs before they ever reach orchestration code.

Threat narrative

Attacker objective: The objective is to gain command execution in a trusted test environment and use that foothold to steal credentials or manipulate the software supply chain.

1. Entry occurs when an attacker supplies a repository or branch name containing shell metacharacters that are later read by the smart-selection helper.
2. Credential access follows arbitrary command execution inside a CI runner or developer workstation that already holds BrowserStack, GitHub, npm, cloud, or SSH secrets.
3. Impact is supply-chain compromise, where the attacker can steal tokens, tamper with artifacts, or pivot into downstream deployment systems.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Test orchestration is now part of the application supply chain, not a neutral utility layer. This vulnerability shows that pre-release tooling can hold the same trust weight as build and deploy systems when it executes in privileged CI contexts. The real control failure is not weak test coverage, but untrusted input reaching a command interpreter before any release gate can intervene. Teams should treat orchestration code as security-sensitive supply chain code, not developer convenience.

Standing secrets in CI runners turn command injection into identity compromise. The article’s risk profile is driven by the credentials present on the runner, not just the shell bug itself. When GitHub tokens, npm tokens, cloud credentials, and SSH keys are accessible to test jobs, arbitrary command execution becomes a non-human identity abuse problem as much as a vulnerability management issue. Practitioners should map runner privilege and secret scope with the same rigor used for production service accounts.

Shell interpolation of repository metadata is a named governance gap: metadata-to-execution trust collapse. This is the failure mode where a system assumes ref names, paths, or repo-derived values are inert when they are actually attacker-controlled. That assumption is especially dangerous in JavaScript supply chains because helpers often run early, automatically, and with broad access. The control lesson is to remove shell interpretation from any workflow that consumes external repository metadata.

Smart-selection features complicate least privilege because they encourage broad environment access for a narrow test purpose. What looks like a test optimisation can quietly expand the attack surface across code, credentials, and network reach. In identity terms, this is a privilege design problem, not only an input-validation problem. Practitioners should question whether convenience features justify the access breadth they require.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
• For a broader view of identity exposure patterns, The 52 NHI breaches Report shows how trusted execution paths repeatedly turn into credential loss events.

What this signals

CI security is increasingly an identity control problem because test runners aggregate machine credentials, build permissions, and external service access in one execution context. Teams that still treat orchestration helpers as low-risk utilities will miss where the actual blast radius lives.

Metadata-to-execution trust collapse: this is the pattern to watch when repository-derived values can influence command execution, file writes, or network calls. The lesson is to separate repository inspection from shell invocation, then verify that runner privileges match the minimum needed for the job.

For teams managing NHI estates, this is another reminder to connect secrets inventory with execution context. A leaked token is bad, but a leaked token on a runner that can publish or deploy is materially worse, so governance must follow the path from code checkout to credential use.

For practitioners

• Upgrade vulnerable WebdriverIO packages immediately Move @wdio/browserstack-service to 9.24.0 or later and verify that lockfiles, transitive dependencies, and CI images no longer resolve to 9.23.2 or older.
• Disable smart selection for untrusted repositories Turn off BrowserStack smart-selection paths in any job that runs against forks, sample projects, generated repositories, or checkouts created by external contributors.
• Remove shell-string execution from orchestration helpers Replace execSync string commands with execFile or spawn-style argument arrays so branch names and other repo metadata are never parsed by a shell.
• Rotate runner credentials after exposure If any vulnerable job executed against an untrusted checkout, rotate BrowserStack credentials, GitHub tokens, npm tokens, cloud keys, SSH keys, and deployment secrets used by that runner.

Key takeaways

• The vulnerability is not in browser automation itself, but in trusting Git metadata enough to turn it into shell syntax.
• Its real risk is identity-related because CI runners often hold the secrets and tokens that make supply chain compromise possible.
• Fixing the package is necessary, but reducing runner privilege and eliminating shell-string execution are what close the governance gap.

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 Orchestration: The automation layer that decides how tests are selected, scheduled, and executed across environments. It is security-sensitive because it often runs early in the pipeline and may inherit the same credentials and network reach used by release and deployment jobs.
• Runner Identity: The credentialed identity used by a CI/CD runner or build agent to execute automation tasks. It is often broader than teams realise because it can inherit repository, cloud, and deployment permissions that make a single compromised job highly valuable to an attacker.
• Repository-Derived Input: Any value pulled from source control, such as branch names, commit messages, file paths, or metadata. These values are not automatically trustworthy, and security failures occur when tooling treats them as safe command fragments or configuration data without validation.

What's in the full analysis

Corgea's full analysis covers the operational detail this post intentionally leaves for the source:

• Exact vulnerable code path and advisory references for CVE-2026-25244
• Exploit examples showing how malicious branch names reach shell execution
• Detection and triage steps for npm, pnpm, and yarn dependency checks
• Remediation guidance for runner credential rotation after exposure

👉 Corgea's full post covers the vulnerable command path, exploit shape, and remediation steps for CI teams.

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 practitioners connect identity controls to the build and release systems that expose them.