Gitea Actions Pull_request_target Reusable Workflow Secrets Vulnerability
You fix the gitea actions pull_request_target reusable workflow secrets vulnerability by isolating untrusted code. You must never pass base repo secrets into a workflow that runs fork code. Engineering teams often use target triggers to help outside contributors run build checks. They link shared workflows to save time across many code projects. When roles or permissions are too broad, a bad actor can steal keys. An attacker can modify a build script in a fork and print secrets. How the gitea
Pull Request Security Checks + K8s Secrets Management: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You fix the gitea actions pull_request_target reusable workflow secrets vulnerability by isolating untrusted code. You must never pass base repo secrets into a workflow that runs fork code. Engineering teams often use target triggers to help outside contributors run build checks. They link shared workflows to save time across many code projects. When roles or permissions are too broad, a bad actor can steal keys. An attacker can modify a build script in a fork and print secrets.
How the gitea actions pull_request_target reusable workflow secrets vulnerability works
Standard pull request events run inside the context of the contributor fork. Those runs get a read-only token and cannot read base repo secrets. The target trigger works in a very different way. It runs inside the context of the base branch instead of the fork. This gives the job full write permissions and access to stored secrets. Teams set up this trigger so bots can label issues or post comments.
Trouble starts when this privileged trigger calls a shared workflow. Teams often set up the caller workflow to pass all secrets down. If any step checks out the contributor branch, the fork controls the code. The job now runs untrusted scripts while holding live production keys. An attacker can add a step that sends database keys to an outside server. The shared workflow hides this risk because the steps live in another file.
Even if the main file looks safe, the called file might check out code. A developer might update the shared workflow later and add a build step. That single change exposes every project that calls the shared file. The runner loads the secrets into memory before the untrusted script runs. Once the script starts, it can read any variable in that runner session.
How to set up safe workflows and where gaps remain
To fix this issue, teams must split their build jobs into two parts. The first workflow runs on a normal pull request without any secret keys. It checks out the untrusted fork code, runs tests, and saves build files. The second workflow uses the target trigger only to read those safe results. It never checks out code or runs scripts from the contributor fork.
Pull Request Security Checks + K8s Secrets Management: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
You should also stop passing all secrets at once to shared workflows. Pass only the single key that a specific step needs to do its job. Set the default runner token to read-only at the main settings level. Grant write roles only to the exact job that posts a comment. Keep shared workflows in a locked project that requires strict peer review.
These native workflow settings help you lock down who starts a build job. Still, they only control how the runner starts and which keys load first. Once a job has a database key, native rules cannot see what happens next. A valid build job still holds raw credentials in memory during the run. The setup decides who logs in, not what individual commands do in flight. If a trusted script has a bug, it can still run bad queries. It can also return raw emails, phone numbers, or card numbers in logs. Teams still need a way to check every command and mask data live.
Govern statements and responses across databases and APIs
Good config and scoped roles are needed setup. They do not check single queries in flight or mask sensitive fields in returned rows. Across Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, and internal HTTP endpoints, hoop.dev runs beside each supported service as an open-source proxy, a sidecar for your database or API.
First, hoop.dev guardrails block banned queries before they run. Then hoop.dev data masking rewrites matched sensitive values in responses in memory. The audit trail records every statement and verdict per resource. Furthermore, hoop.dev holds SOC 2 Type II and is open source on GitHub.
Frequently asked questions
Why do teams use the pull request target trigger at all?
Teams use it when a build job needs to comment on a pull request. Standard fork runs lack the write token needed to update the main board.
Does a reusable workflow get secrets by default?
No, a caller workflow must pass secrets down to the called workflow. The risk happens when teams pass all secrets down and run fork code.
How can we test untrusted fork code without leaking keys?
Run all tests using a standard pull request trigger with read-only permissions. Save any needed output as a file and process it in a separate job.