GitHub Actions Security Auditor
Paste a GitHub Actions workflow and see the risky patterns GitHub itself warns about — pull_request_target checking out untrusted fork code, actions pinned to a mutable @main or @v4 instead of a full commit SHA, permissions: write-all or no permissions block at all, secrets echoed to logs, curl | bash, self-hosted runners and $${{ github.event.* }} script injection. Every finding has a severity, the offending line and a concrete fix. It runs entirely in your browser — the workflow is never uploaded or executed.
Paste a GitHub Actions workflow (.github/workflows/*.yml). It is analysed entirely in your browser with static pattern matching — nothing is uploaded and the workflow is never executed. Findings are heuristics, not a proof of (in)security; review each one in context.
Analysed entirely in your browser — the workflow is never uploaded or executed. The pattern library follows GitHub's own Security Hardening for GitHub Actions guidance. Educational — not affiliated with GitHub.
What this tool does
- Paste a GitHub Actions workflow YAML and get an instant, in-browser security audit — no signup, nothing uploaded, the workflow is never executed.
- Flags the patterns GitHub itself warns about: pull_request_target / workflow_run that checks out untrusted fork code, actions pinned to a mutable tag or branch instead of a full commit SHA, permissions: write-all or a missing permissions block, secrets echoed to the log, curl | bash remote-code execution, self-hosted runners, and ${{ github.event.* }} script injection.
- Each finding carries a severity, the offending line, why it matters, and a concrete fix — plus a copyable / downloadable report.
- The check library follows GitHub's Security Hardening for GitHub Actions documentation and GitHub Security Lab's "pwn request" guidance.
- Motivated by the October 2026 LiteLLM GitHub-identity supply-chain compromise, where a foothold in CI was used to exfiltrate secrets — least-privilege tokens and pinned, trusted workflow sources are the controls that contain that blast radius.
Why this matters
CI is a privileged place: it holds the tokens that push code, cut releases and reach production. The October 2026 LiteLLM GitHub-identity supply-chain compromise is the cautionary case this tool is built around. As publicly reported, the chain ran from a leaked key to an org-owner GitHub CLI token, then to CI secret exfiltration, a release built from a fork source, deletion of workflow run records and a force-push to hide the change.
Hardened workflows shrink every link in that chain. Least-privilege GITHUB_TOKEN permissions limit what a hijacked job can touch; pinning third-party actions to a full commit SHA stops a swapped-out version from running with your secrets; and never executing untrusted pull-request code under a privileged trigger removes the foothold a pwn request relies on. None of these would have prevented a leaked human credential on their own — but together they turn a single compromise into a contained one instead of a fleet-wide one. This is an educational analyser referencing a real, reported incident for context; PlayCISO is not affiliated with LiteLLM or GitHub.
Frequently asked questions
Does this upload or run my workflow?
No. The analysis is 100% client-side string and regular-expression matching in your browser. The YAML never leaves your device, no network request is made, and the workflow is never executed. You can disconnect from the network and it still works.
Why does it flag actions/checkout@v4 as a problem?
Tags like v4 and branches like main are mutable — the action's maintainer, or an attacker who compromises their account, can re-point the tag at new code that then runs in your pipeline with your secrets. GitHub's hardening guidance recommends pinning third-party actions to a full-length (40-character) commit SHA, which is immutable. The tool treats a tag as medium risk and a branch like @main as high.
What is the pull_request_target "pwn request"?
pull_request_target (and workflow_run) run in the context of the base repository with access to its secrets, unlike pull_request which runs without them for fork PRs. If such a workflow checks out the pull request head (the fork's code) and then builds or runs scripts from it, any contributor can open a PR whose code executes with your secrets. GitHub Security Lab calls this a "pwn request." Use pull_request for untrusted code, and never execute PR-head code in a privileged trigger.
How does this relate to the LiteLLM incident?
In the October 2026 LiteLLM compromise, as publicly reported, a leaked key led to an org-owner GitHub CLI token, which was used to exfiltrate CI secrets, publish a release built from a fork source, and then delete run records and force-push to cover the tracks. Hardened workflows reduce that blast radius: least-privilege GITHUB_TOKEN permissions limit what a hijacked job can touch, pinned action SHAs stop a malicious version from being pulled in, and not running untrusted code with secrets closes the initial foothold. This tool is attributing a real, reported incident for context — it is not affiliated with LiteLLM or GitHub.
Is a clean result a guarantee my workflow is safe?
No. This matches a fixed library of well-known footguns. A workflow can pass every check here and still be insecure through logic the tool does not model. Treat it as a fast first pass, not a substitute for review or GitHub's own code scanning.
This tool is free and always will be. Would a Pro workspace — saved designs, team sharing and exports — be worth paying for?
Show me Pro →No account needed to use this tool — this just tells us whether Pro is worth building out.