hunt-cicd

Detect and validate CI/CD pipeline vulnerabilities across Jenkins, GitHub Actions, GitLab CI, and Terraform state.

Updated Sep 6, 2026

Search Tags:#github actions #terraform #jenkins #ci/cd security #bug bounty #vulnerability hunting #secret leakage

One-click install

npx skills add https://github.com/inventashif/helpful-code-sidekick --skill hunt-cicd-inventashif

Or copy as Structured Prompt for Agent▼

Please help me install this Agent Skill.
Skill: hunt-cicd
Source: https://github.com/inventashif/helpful-code-sidekick/tree/main/scripts/hackerai/skills/bughunter/hunt-cicd
Command: npx skills add https://github.com/inventashif/helpful-code-sidekick --skill hunt-cicd-inventashif

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Security researchers and bug bounty hunters often waste effort on CI/CD findings that look exploitable but are not, such as Jenkins login pages mistaken for open script consoles or pull_request_target workflows with no injectable sink. This Skill provides a structured, validation-first methodology to find and prove real CI/CD vulnerabilities with concrete evidence. ## Core Features & Use Cases - Jenkins Exploitation & Validation: Fingerprint versions via X-Jenkins headers, test for unauthenticated script console RCE, and exploit CVE-2024-23897 CLI file read to recover credential stores. - GitHub Actions Attack Paths: Identify pull_request_target injection (Pwnrequest), ${{ }}-into-shell template injection, self-hosted runner poisoning, OIDC trust-policy abuse, and Actions cache poisoning, with correct exfiltration techniques (printenv, /proc/self/environ) and OOB confirmation via Collaborator/interactsh. - Secrets & State Leakage: Hunt secrets in pipeline logs, artifacts, container image layers (trufflehog --only-verified), GitLab runner registration tokens, and public Terraform state files, with jq-based extraction and false-positive filtering. - Use Case: Given a target organization with a public GitHub org and an exposed Jenkins dashboard, enumerate workflows for dangerous triggers, confirm a template-injection sink with a blind OOB callback, and produce a validated Critical-severity report instead of a retracted false positive. ## Quick Start Use the hunt-cicd skill to assess the target organization's public GitHub workflows and exposed Jenkins instance for exploitable CI/CD vulnerabilities, validating each finding before reporting.

Frequently Asked Questions about hunt-cicd

High-intent search queries and answers about installing and using this skill.

FAQPage Schema

How do I test GitHub Actions for pull_request_target injection?▼

Enumerate org workflows for pull_request_target or workflow_run triggers, then check whether untrusted ${{ github.event.* }} data flows into a shell run step or whether the workflow checks out the PR head and runs attacker-controlled build code. Confirm blind injection with a Burp Collaborator or interactsh callback before reporting.

How to exploit Jenkins script console for RCE?▼

POST a Groovy script to /scriptText such as println "id".execute().text and verify the response contains your command output like uid=(jenkins). A returned login or SSO page means the console requires authentication and is not a finding. From there, dump the credential store using CredentialsProvider Groovy code.

What is CVE-2024-23897 and how do I validate it?▼

CVE-2024-23897 is a pre-auth arbitrary file read in Jenkins CLI (versions up to 2.441 / LTS 2.426.2) via args4j @-file expansion. Validate by running jenkins-cli.jar connect-node "@/etc/passwd" and confirming real file content appears in the error response; a generic error with no leaked line means the instance is patched.

Why is my pull_request_target finding a false positive?▼

A pull_request_target workflow is only exploitable if untrusted input reaches an execution sink. If the input is used only in an if: condition, wrapped safely in an env: block and quoted in the shell, or the workflow actually uses pull_request, there is no injection and the report will be retracted.

Does a public Terraform state file count as a vulnerability?▼

Only if it contains live credentials. Parse the tfstate with jq to extract password, private_key, token, or access_key attributes, then prove impact with a read-only authentication such as aws sts get-caller-identity. State files containing only resource IDs, ARNs, and tags are not reportable findings.

How do I avoid false positives when scanning container images for secrets?▼

Run trufflehog with the --only-verified flag so it reports only credentials it could actually authenticate, filtering out expired or example keys. Also inspect docker history --no-trunc for secrets in ENV or ARG instructions that persist in earlier layers even after removal.