GitHub Actions Security: Avoiding `pull_request_target` Pitfalls in `welcome-new-users.yml`

[yada]

📌 Background

Recent research has highlighted a class of attacks targeting insecure GitHub Actions workflows, particularly those that use the pull_request_target trigger.

👉 Reference (thanks @mathieu-benoit for the notification):

• https://www.stepsecurity.io/blog/hackerbot-claw-github-actions-exploitation

These attacks (e.g. HackerBot-Claw) exploit workflows that:

• Run on pull_request_target
• Execute untrusted code from pull requests
• Have access to write permissions or secrets

This combination can lead to:

• Remote code execution (RCE)
• Token exfiltration
• Repository compromise

⚠️ The Problem

The pull_request_target event runs in the context of the base repository, meaning:

• It has access to secrets
• It uses a write-capable GITHUB_TOKEN
• It is NOT sandboxed like pull_request

This becomes dangerous if the workflow:

• Checks out PR code (actions/checkout)
• Executes scripts from the PR
• Uses inputs controlled by the PR author

✅ Safe Use Case (Previous Setup)

Our original workflow used pull_request_target only to post comments (via wow-actions/welcome), without:

• Checking out code
• Running scripts

This is not directly vulnerable to the attack described above.

However, it still introduces a latent risk:

A future change (e.g. adding checkout) could instantly make it exploitable.

🛡️ Recommended Solution (Provably Safer)

We replace pull_request_target with pull_request, which:

• Runs in a restricted context
• Does not expose secrets to forks
• Uses a read-limited token by default

We also:

• Remove all unnecessary permissions
• Grant minimal per-job permissions
• Avoid executing any external or user-controlled code

✅ TL;DR

The safest workflow is one that never executes untrusted code and never has more permissions than it needs.

Switching from pull_request_target to pull_request eliminates an entire class of supply chain attacks, including the one described in the HackerBot-Claw research.

[ollieb89]

The migration from to described here is the right call for a workflow that only posts welcome comments.

One thing to watch during the transition: if you currently use the to post comments, from forks will have a read-only token. For comment-only workflows, you have two options:

1. Use the trigger with a GitHub App token (if you need write access on fork PRs)
2. Use the pattern — a workflow does the untrusted work (checking out code, building), then triggers a privileged that posts the comment using the base repo context

For a simple welcome message that doesn't need PR code access, option 1 with a minimal-permissions GitHub App is usually cleanest. The App only needs and , and you avoid the complexity of chaining.

If you want to validate that no future PR accidentally reintroduces with unsafe patterns, you could add a CI check using zizmor or workflow-guardian that scans workflow files and fails the build on dangerous configurations.