ci: route release version input through env, not shell interpolation - #11857
Merged
Conversation
The parse-validate-version step in release.yml passes the
workflow_dispatch version input to a bash script by interpolating the
expression directly into the shell command:
run: .github/utils/parse_validate_version.sh "${{ inputs.version }}"
At runtime the runner expands the expression before /bin/bash parses the
line, so the raw contents of the input become part of the shell source
of the step. If a triggering actor supplies a version string containing
a backtick, dollar-parenthesis, or quote-escape sequence, that content
is evaluated by the shell before it ever reaches the script.
The release workflow is guarded by an authorize job that requires the
triggering actor to hold the maintain or admin role, so the practical
risk today is limited: only trusted maintainers can reach this step.
This change is defence in depth. It brings the step in line with the
pattern used in the later bump-dc-pipeline-templates job (line 280 in
the same file already sets VERSION via env), matches the guidance in
GitHub's Security hardening for GitHub Actions documentation, and
removes one more instance of the anti-pattern the ecosystem has been
scrubbing since CVE-2025-30066.
Same class of hardening as deepset-ai#11733 (persist-credentials: false) and
deepset-ai#11777 (dependency pinning + CodeQL).
|
@camgrimsec is attempting to deploy a commit to the deepset Team on Vercel. A member of the Team first needs to authorize it. |
sjrl
approved these changes
Jul 3, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The parse-validate-version step in release.yml passes the workflow_dispatch version input to a bash script by interpolating the expression directly into the shell command:
run: .github/utils/parse_validate_version.sh "${{ inputs.version }}"
At runtime the runner expands the expression before /bin/bash parses the line, so the raw contents of the input become part of the shell source of the step. If a triggering actor supplies a version string containing a backtick, dollar-parenthesis, or quote-escape sequence, that content is evaluated by the shell before it ever reaches the script.
The release workflow is guarded by an authorize job that requires the triggering actor to hold the maintain or admin role, so the practical risk today is limited: only trusted maintainers can reach this step. This change is defence in depth. It brings the step in line with the pattern used in the later bump-dc-pipeline-templates job (line 280 in the same file already sets VERSION via env), matches the guidance in GitHub's Security hardening for GitHub Actions documentation, and removes one more instance of the anti-pattern the ecosystem has been scrubbing since CVE-2025-30066.
Same class of hardening as #11733 (persist-credentials: false) and #11777 (dependency pinning + CodeQL).
Related Issues
Proposed Changes:
How did you test it?
Notes for the reviewer
Checklist
fix:,feat:,build:,chore:,ci:,docs:,style:,refactor:,perf:,test:and added!in case the PR includes breaking changes.