Improper Github Workflow Trigger Validation

Base Metricscoreseverity

Type: Weakness

Status: fixed

Reporting Date: 2023.06.01

The build-on-pr Github workflow passes untrusted data to into a shell command, causing improper username comparison and triggering further workflow execution.


The github.triggering_actor is passed directly into a grep shell command and not sanitized or escaped.

The github user name limitations severely limit the direct impact for command injection.

Github username may only contain alphanumeric characters or hyphens. Github username cannot have multiple consecutive hyphens. Github username cannot begin or end with a hyphen. Maximum is 39 characters.

The main issue is in the username validation logic.

It only checks if there is a grep match, which will be true in case the PR submitter only has a subset of the name of a contributor. In this case you could trigger a build based on a malicious PR by creating an account named anastasiya115, which is a subset of anastasiya1155.

    runs-on: ubuntu-latest
    name: Validate user is the member of BloopAI organization
    if: github.event.issue.pull_request && contains(github.event.comment.body, '/build')
      is-member: ${{ }}
      - name: Validation
        id: membership
          ACTOR: ${{ github.triggering_actor }}
        run: |
          if curl -L \
            -H "Accept: application/vnd.github+json" \
            -H "Authorization: Bearer ${{ secrets.BLOOP_DEVOPS_PAT}}"\
            -H "X-GitHub-Api-Version: 2022-11-28" \
   | jq -r ".[] .login" | grep ${ACTOR}; then
            echo "is-member=true" >> $GITHUB_OUTPUT

The username of the user that triggered the initial workflow run. If the workflow run is a re-run, this value may differ from github.triggering_actor. Any workflow re-runs will use the privileges of, even if the actor initiating the re-run (github.triggering_actor) has different privileges.1


As the final execution is prevented by further hardening settings of the Github repository, another manual approval would be needed to execute a malicious PR workflow. Therefore the practial likelihood of exploitation is low, while impact would be high once mistakenly approved.


Refactor the workflow to facilitate proper github authorisation mechanisms.

Retest Notes

The issue was promptly fixed, after being discussed in a shared Slack channel. It was resolved by facilitating javascript based actions, which are properly implemented. The fix was merged into their release with PR 968.