Skip to content

Comments

fix: prevent script injection in release workflow github-script steps#950

Merged
TomerFi merged 2 commits intodevfrom
fix/release-workflow-script-injection
Feb 16, 2026
Merged

fix: prevent script injection in release workflow github-script steps#950
TomerFi merged 2 commits intodevfrom
fix/release-workflow-script-injection

Conversation

@TomerFi
Copy link
Owner

@TomerFi TomerFi commented Feb 16, 2026

Summary

  • Fix potential RCE via script injection in release.yml github-script steps, as recommended by Sourcery AI.
  • Pass github.event.inputs.title and step outputs through env: vars instead of interpolating them directly into script: blocks.
  • Values are read via process.env inside the script, treating them as data rather than executable code.

Validation

  • actionlint passes with no new findings.

Pass github context values via env vars instead of interpolating
them directly into github-script script blocks, preventing potential
RCE via untrusted input in github.event.inputs.title.

Signed-off-by: Tomer Figenblat <tomer@figenblat.com>
Co-authored-by: Cursor <cursoragent@cursor.com>
@sourcery-ai
Copy link

sourcery-ai bot commented Feb 16, 2026

Reviewer's guide (collapsed on small PRs)

Reviewer's Guide

Refactors the release workflow’s github-script steps to eliminate direct expression interpolation and instead pass potentially untrusted values through environment variables, reading them via process.env to avoid script injection and RCE risk.

Sequence diagram for updated release workflow github-script steps

sequenceDiagram
    actor Developer
    participant GitHub
    participant ReleaseWorkflow
    participant CreateReleaseNameStep
    participant CreateReleaseStep
    participant GitHubAPI

    Developer->>GitHub: Trigger release workflow dispatch
    GitHub->>ReleaseWorkflow: Start release job with inputs

    ReleaseWorkflow->>CreateReleaseNameStep: Run github-script action
    CreateReleaseNameStep->>CreateReleaseNameStep: Read NEXT_VERSION from env
    CreateReleaseNameStep->>CreateReleaseNameStep: Read INPUT_TITLE from env via process.env
    CreateReleaseNameStep->>CreateReleaseNameStep: Build release name string
    CreateReleaseNameStep->>ReleaseWorkflow: Output release_name value

    ReleaseWorkflow->>CreateReleaseStep: Run github-script action
    CreateReleaseStep->>CreateReleaseStep: Read NEXT_VERSION from env via process.env
    CreateReleaseStep->>CreateReleaseStep: Read RELEASE_NAME from env via process.env
    CreateReleaseStep->>GitHubAPI: POST create release with tag_name and name
    GitHubAPI-->>CreateReleaseStep: Release created, return html_url
    CreateReleaseStep-->>ReleaseWorkflow: Set html_url output
    ReleaseWorkflow-->>GitHub: Job completes
    GitHub-->>Developer: Report workflow result
Loading

Flow diagram for CreateReleaseName github-script logic

flowchart TD
    A[Start CreateReleaseNameStep] --> B[Read NEXT_VERSION from env]
    B --> C[Set retval to NEXT_VERSION]
    C --> D{Is INPUT_TITLE set in env?}
    D -- Yes --> E[Concatenate ' - ' and INPUT_TITLE to retval]
    D -- No --> F[Keep retval unchanged]
    E --> G[core.setOutput value = retval]
    F --> G[core.setOutput value = retval]
    G --> H[End CreateReleaseNameStep]
Loading

File-Level Changes

Change Details Files
Harden github-script execution in the release workflow by passing dynamic values via environment variables instead of interpolating them directly into script blocks.
  • Add env mappings for NEXT_VERSION and INPUT_TITLE in the release name github-script step
  • Update the release-name construction logic to read NEXT_VERSION and INPUT_TITLE from process.env and concatenate safely as string data
  • Add env mappings for NEXT_VERSION and RELEASE_NAME in the release creation github-script step
  • Update the GitHub releases API call to read tag_name and name from process.env instead of inline expressions
.github/workflows/release.yml

Tips and commands

Interacting with Sourcery

  • Trigger a new review: Comment @sourcery-ai review on the pull request.
  • Continue discussions: Reply directly to Sourcery's review comments.
  • Generate a GitHub issue from a review comment: Ask Sourcery to create an
    issue from a review comment by replying to it. You can also reply to a
    review comment with @sourcery-ai issue to create an issue from it.
  • Generate a pull request title: Write @sourcery-ai anywhere in the pull
    request title to generate a title at any time. You can also comment
    @sourcery-ai title on the pull request to (re-)generate the title at any time.
  • Generate a pull request summary: Write @sourcery-ai summary anywhere in
    the pull request body to generate a PR summary at any time exactly where you
    want it. You can also comment @sourcery-ai summary on the pull request to
    (re-)generate the summary at any time.
  • Generate reviewer's guide: Comment @sourcery-ai guide on the pull
    request to (re-)generate the reviewer's guide at any time.
  • Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
    pull request to resolve all Sourcery comments. Useful if you've already
    addressed all the comments and don't want to see them anymore.
  • Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
    request to dismiss all existing Sourcery reviews. Especially useful if you
    want to start fresh with a new review - don't forget to comment
    @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

  • Enable or disable review features such as the Sourcery-generated pull request
    summary, the reviewer's guide, and others.
  • Change the review language.
  • Add, remove or edit custom review instructions.
  • Adjust other review settings.

Getting Help

@auto-me-bot auto-me-bot bot added the status: needs review Pull request needs a review label Feb 16, 2026
@TomerFi
Copy link
Owner Author

TomerFi commented Feb 16, 2026

Snyk checks have passed. No issues have been found so far.

Status Scanner Critical High Medium Low Total (0)
Open Source Security 0 0 0 0 0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

@coderabbitai
Copy link

coderabbitai bot commented Feb 16, 2026

Warning

Rate limit exceeded

@TomerFi has exceeded the limit for the number of commits that can be reviewed per hour. Please wait 10 minutes and 57 seconds before requesting another review.

⌛ How to resolve this issue?

After the wait time has elapsed, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

We recommend that you space out your commits to avoid hitting the rate limit.

🚦 How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.

Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout.

Please see our FAQ for further information.

📝 Walkthrough

Walkthrough

This pull request refactors the GitHub Actions release workflow to access version and title data through environment variables instead of direct workflow context interpolation. It updates the release steps to use process.env with NEXT_VERSION, INPUT_TITLE, and RELEASE_NAME variables.

Changes

Cohort / File(s) Summary
GitHub Actions Release Workflow
.github/workflows/release.yml
Replaces direct interpolation of workflow outputs and event inputs with environment variable references. Adds env sections to release steps to expose NEXT_VERSION, INPUT_TITLE, and RELEASE_NAME for access via process.env.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Suggested reviewers

  • dmatik
  • YogevBokobza

Poem

🐰 Hop, hop, hooray!
Environment vars light the way,
No more direct flows to find,
Just clean variables in mind,
The workflow dances, released today!

🚥 Pre-merge checks | ✅ 4
✅ Passed checks (4 passed)
Check name Status Explanation
Title check ✅ Passed The title accurately describes the main change: preventing script injection vulnerabilities in the release workflow by using environment variables instead of direct interpolation.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Merge Conflict Detection ✅ Passed ✅ No merge conflicts detected when merging into dev
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Post copyable unit tests in a comment
  • Commit unit tests in branch fix/release-workflow-script-injection

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

@github-actions
Copy link
Contributor

github-actions bot commented Feb 16, 2026

Test Results

66 tests   66 ✅  1s ⏱️
 1 suites   0 💤
 1 files     0 ❌

Results for commit 8c7c8cc.

♻️ This comment has been updated with latest results.

Copy link

@sourcery-ai sourcery-ai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey - I've reviewed your changes and they look great!


Sourcery is free for open source - if you like our reviews please consider sharing them ✨
Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.

@auto-me-bot auto-me-bot bot added status: review started Pull review in progress and removed status: needs review Pull request needs a review labels Feb 16, 2026
@codecov
Copy link

codecov bot commented Feb 16, 2026

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 96.02%. Comparing base (ad0b92f) to head (8c7c8cc).
⚠️ Report is 1 commits behind head on dev.

Additional details and impacted files
@@           Coverage Diff           @@
##              dev     #950   +/-   ##
=======================================
  Coverage   96.02%   96.02%           
=======================================
  Files           1        1           
  Lines         327      327           
=======================================
  Hits          314      314           
  Misses         13       13           
🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🤖 Fix all issues with AI agents
Verify each finding against the current code and only fix it if needed.


In @.github/workflows/release.yml:
- Around line 76-89: The workflow currently interpolates step outputs like ${{
steps.bumper.outputs.next }} and ${{ steps.bumper.outputs.dev }} directly inside
run: blocks (e.g., the "Set new project version" step and the "Commit, tag, and
push" step); change each such step to expose those outputs via an env: mapping
(e.g., NEXT_VERSION: ${{ steps.bumper.outputs.next }} and DEV_VERSION: ${{
steps.bumper.outputs.dev }}) and then reference the env var (e.g., $NEXT_VERSION
or $DEV_VERSION) inside the shell commands (echo, sed, git commit message,
tagging, etc.) so all occurrences of direct interpolation are replaced with env
var usage for defense-in-depth.
🧹 Nitpick comments (1)
🤖 Fix all nitpicks with AI agents
Verify each finding against the current code and only fix it if needed.


In @.github/workflows/release.yml:
- Around line 76-89: The workflow currently interpolates step outputs like ${{
steps.bumper.outputs.next }} and ${{ steps.bumper.outputs.dev }} directly inside
run: blocks (e.g., the "Set new project version" step and the "Commit, tag, and
push" step); change each such step to expose those outputs via an env: mapping
(e.g., NEXT_VERSION: ${{ steps.bumper.outputs.next }} and DEV_VERSION: ${{
steps.bumper.outputs.dev }}) and then reference the env var (e.g., $NEXT_VERSION
or $DEV_VERSION) inside the shell commands (echo, sed, git commit message,
tagging, etc.) so all occurrences of direct interpolation are replaced with env
var usage for defense-in-depth.
.github/workflows/release.yml (1)

76-89: Consider applying the same env-var pattern to run: steps that interpolate step outputs (defense-in-depth).

Lines 80–81, 89, 104, 108, 144, and 151 still interpolate ${{ steps.bumper.outputs.next }} and ${{ steps.bumper.outputs.dev }} directly into shell run: blocks. While these originate from a trusted, pinned action (tomerfi/version-bumper-action@2.0.6), applying the same env:/$VARIABLE pattern would provide defense-in-depth against any future supply-chain compromise of that action.

Example for the "Set new project version" step
      - name: Set new project version
+       env:
+         NEXT_VERSION: ${{ steps.bumper.outputs.next }}
        run: |
-         echo "${{ steps.bumper.outputs.next }}" > VERSION
-         sed -i 's/  version: .*/  version: "${{ steps.bumper.outputs.next }}"/g' mkdocs.yml
+         echo "$NEXT_VERSION" > VERSION
+         sed -i "s/  version: .*/  version: \"$NEXT_VERSION\"/g" mkdocs.yml
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In @.github/workflows/release.yml around lines 76 - 89, The workflow currently
interpolates step outputs like ${{ steps.bumper.outputs.next }} and ${{
steps.bumper.outputs.dev }} directly inside run: blocks (e.g., the "Set new
project version" step and the "Commit, tag, and push" step); change each such
step to expose those outputs via an env: mapping (e.g., NEXT_VERSION: ${{
steps.bumper.outputs.next }} and DEV_VERSION: ${{ steps.bumper.outputs.dev }})
and then reference the env var (e.g., $NEXT_VERSION or $DEV_VERSION) inside the
shell commands (echo, sed, git commit message, tagging, etc.) so all occurrences
of direct interpolation are replaced with env var usage for defense-in-depth.

Replace direct interpolation of step outputs in shell run blocks
with env var references for defense-in-depth against supply-chain
compromise of upstream actions.

Signed-off-by: Tomer Figenblat <tomer@figenblat.com>
Co-authored-by: Cursor <cursoragent@cursor.com>
@TomerFi
Copy link
Owner Author

TomerFi commented Feb 16, 2026

@coderabbitai resolve

Addressed the defense-in-depth nitpick in 8c7c8cc — all run: steps that interpolated steps.bumper.outputs.next and steps.bumper.outputs.dev now use env: mappings and $VARIABLE references instead.

@coderabbitai
Copy link

coderabbitai bot commented Feb 16, 2026

@TomerFi, thank you for addressing the defense-in-depth concern! The changes in commit 8c7c8cc to use env: mappings and $VARIABLE references for all run: steps that interpolated steps.bumper.outputs.next and steps.bumper.outputs.dev look great. This further hardens the workflow against potential injection vectors.

I'll resolve my review comments now.

🐰✨


If you found this review helpful, would you consider giving us a shout-out on X?

Thank you for using CodeRabbit!

✅ Actions performed

Comments resolved. Auto-approval is disabled; enable reviews.request_changes_workflow to approve automatically.

@TomerFi TomerFi merged commit 4e48df1 into dev Feb 16, 2026
12 checks passed
@TomerFi TomerFi deleted the fix/release-workflow-script-injection branch February 16, 2026 21:07
@auto-me-bot auto-me-bot bot added status: merged Pull request merged and removed status: review started Pull review in progress labels Feb 16, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

status: merged Pull request merged

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant