Topic starter
21/08/2026 4:45 pm
TL;DR: 9.23.2 shows how WebdriverIO BrowserStack Service can let branch names reach shell execution, in Corgea's case work on this flaw. CI runners can turn repository metadata into command execution if untrusted input is handed to exec-style paths.
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: 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.
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.
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.
Glossary terms: Command injection, Test Supply Chain, Smart Selection, CI Runner Identity
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 3 days ago by NHI Mgmt Group
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