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.

[yada]

Still have an issue on the workflow run, see: https://github.com/microcks/microcks/actions/runs/23681151353/job/68999465915#step:2:14

[yada]

Fix deployed, ongoing validation on main repo: to follow

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity 😴

It will be closed in 30 days if no further activity occurs. To unstale this issue, add a comment with a detailed explanation.

There can be many reasons why some specific issue has no activity. The most probable cause is lack of time, not lack of interest. Microcks is a Cloud Native Computing Foundation project not owned by a single for-profit company. It is a community-driven initiative ruled under open governance model.

Let us figure out together how to push this issue forward. Connect with us through one of many communication channels we established here.

Thank you for your patience ❤️