Topic starter
21/08/2026 4:45 pm
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.
Editorial analysis by NHI Mgmt Group, based on content published by Corgea: “CVE-2026-25244: WebdriverIO BrowserStack Service executes Git branch names in shell commands”.
By the numbers:
- @wdio/browserstack-service versions through 9.23.2 are affected, and 9.24.0 is the fixed release.
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: This flaw shows how test orchestration can become an execution path when repository metadata is treated as trusted input.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
21/08/2026 5:05 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: WebdriverIO BrowserStack command injection shows test supply chain risk