CI/CD pipelines are the most targeted surface in modern supply chain attacks. A workflow that runs with write permissions onDocumentation Index
Fetch the complete documentation index at: https://mintlify.com/morwn/github-threat-detector/llms.txt
Use this file to discover all available pages before exploring further.
pull_request_target can be exploited by any external contributor to exfiltrate secrets, push malicious commits, or publish tampered releases — all from a fork they fully control. The three rules in this category cover the main vectors: direct workflow file modification by unknown actors, fork-originating pull requests that could trigger privileged workflows, and workflow runs that have already executed with fork-supplied code.
workflow-file-change
Severity: highRequired data: Events only
What it detects
APushEvent that touches any file under .github/workflows/ made by an actor who has no prior push history in the repository over the past 30 days. Actors with at least one push in the 30-day window are classified as known maintainers and suppressed.
How detection works
The analyzer builds amaintainers CTE from all actors who pushed to the repository in the past 30 days. It then queries for push events whose payload mentions /.github/workflows/ and left-joins against that maintainer set. Any row where the join finds no match — meaning the actor is not a known maintainer — is emitted as a finding.
Finding description
Evidence fields
| Field | Description |
|---|---|
created_at | Timestamp of the push event |
pr-target-abuse
Severity: criticalRequired data: Events only
What it detects
APullRequestEvent with action: opened where the pull request originates from a fork (pull_request.head.repo.fork = true). This pattern is the precursor to pull_request_target privilege escalation.
How detection works
The analyzer queries for opened pull request events where the head repository is marked as a fork. Becausepull_request_target runs in the context of the base repository’s secrets — not the fork — any workflow that triggers on this event and checks out fork code can be exploited to access those secrets.
Finding description
Evidence fields
| Field | Description |
|---|---|
created_at | Timestamp of the event |
pr_number | Pull request number |
head_repo | Full name of the fork repository (e.g. attacker/target-repo) |
Real-world context: aquasecurity/trivy (February 2025)
Thepr-target-abuse pattern was exploited against the aquasecurity/trivy repository in February 2025 (PR #10254). The repository’s CI workflow used pull_request_target to run tests on fork-supplied code while retaining access to repository secrets. An external actor submitted a pull request from a fork that, when the workflow triggered, would have allowed execution of attacker-controlled code in the privileged runner context. The pr-target-abuse rule is designed to surface exactly this scenario as soon as the pull request is opened — before any workflow executes.
workflow-run-from-fork
Severity: criticalRequired data: Workflow runs (
--actions)
What it detects
A completed workflow run that was triggered by thepull_request_target event and whose head repository is an external fork — and where the triggering actor is neither in the contributor list nor has any prior push history in the repository.
How detection works
This rule operates on theworkflow_runs table populated by --actions collection. Unlike pr-target-abuse, which fires at PR open time, this rule fires when the workflow has actually run. It additionally cross-references the contributor list (repo_contributors) and push history to filter out trusted actors, and excludes bot accounts.
Finding description
Evidence fields
| Field | Description |
|---|---|
workflow_run_id | Internal ID of the workflow run record |
created_at | Timestamp when the run was created |
head_sha | Commit SHA from the fork that was executed |