Summary
A shell injection flaw in Wazuh's GitHub Actions workflows allows crafted VERSION.json data from pull requests to be interpolated directly into shell commands.
When exploited, this lets attackers execute arbitrary commands on CI runners and potentially exfiltrate sensitive secrets such as GITHUB_TOKEN or cloud credentials.
Affected context
This vulnerability arises in Wazuh's continuous integration workflows that:
- Parse VERSION.json values from untrusted pull requests
- Assign these values to environment variables
- Interpolate those variables directly into shell
runsteps without quoting or sanitization
It is most relevant in repositories where GitHub Actions run automatically on contributions and especially critical on self-hosted or privileged runners.
Exploit preconditions
- Attack surface: GitHub repository workflows triggered by pull requests
- Required access: Ability to submit or modify pull requests (e.g., fork-based contributions)
- Trigger point: CI pipeline jobs that read VERSION.json and interpolate its contents into shell commands
- Why exploitation is possible: Untrusted JSON values are used as environment variables and embedded into shell commands without proper escaping or validation, allowing injection of shell metacharacters.
Why this happens
The core issue maps to CWE-78: Improper Neutralization of Special Elements used in an OS Command (OS Command Injection).
Workflow logic treats data from VERSION.json—originating from untrusted pull requests—as benign configuration and passes it straight into shell commands via environment variables.
Because these values are not strictly validated, quoted, or escaped, shell metacharacters (such as command separators and redirection operators) are interpreted by the shell, turning data fields into executable instructions within the CI environment.
Potential impact
- Execution of arbitrary commands on GitHub-hosted or self-hosted CI runners
- Exfiltration of GITHUB_TOKEN, repository secrets, and AWS or other cloud credentials
- Tampering with build artifacts or injecting malicious code into produced binaries or containers
- Persistence or lateral movement within an organization's infrastructure via compromised credentials
- Disruption of CI/CD processes, including denial of service for builds or deployments
General mitigation guidance
Effective mitigation focuses on treating all workflow inputs as untrusted and minimizing their influence over shell execution:
- Constrain how data from files like VERSION.json is consumed, using strict parsing and whitelisting expected formats (e.g., semantic version patterns).
- Avoid direct interpolation of untrusted values into shell commands; pass them as arguments to trusted tools or use parameterized invocations.
- Apply robust quoting and escaping practices when variables must be used in shell contexts, and prefer structured languages (e.g., JavaScript actions) instead of inline shell where possible.
- Reduce privileges of CI jobs by limiting accessible secrets, scoping tokens tightly, and segregating sensitive workflows from untrusted contributions.
- Introduce separate, more restricted workflows for untrusted PRs that do not require access to high-value secrets or production infrastructure.
How teams detect issues like this
Organizations can identify similar issues by:
- Scanning workflow configuration (e.g., GitHub Actions YAML) for patterns where inputs from PRs, files, or environment variables are interpolated into
runsteps without quoting. - Using static analysis or policy-as-code tools to flag shell commands that concatenate user-controlled variables or lack input validation.
- Conducting code reviews with a specific checklist for CI/CD configurations, focusing on secret usage, shell command construction, and trust boundaries.
- Enforcing repository policies that restrict or require manual approval for workflows triggered by first-time contributors or workflows that access sensitive secrets.
