Listen to this Post
Introduction
The cybersecurity industry relies on bug bounty platforms like HackerOne to act as trusted intermediaries—safeguarding vulnerability reports until vendors can deploy fixes. But what happens when the very platform designed to protect sensitive disclosures inadvertently exposes them? A security researcher recently discovered that multiple public GitHub repositories belonging to HackerOne-managed triage teams contained private vulnerability Proofs-of-Concept (PoCs), exploitation scripts, CI/CD secrets, and internal testing artifacts. This incident—rewarded with a $2,700 bounty—exposes a profound irony: even the guardians of vulnerability disclosure can become targets, and the lessons learned extend far beyond HackerOne to every organization that uses GitHub for security-sensitive work.
Learning Objectives
- Understand how private bug bounty reports can be indirectly leaked through public GitHub repositories and commit histories
- Learn to identify and mitigate CI/CD secret exposures, including GitHub Actions secrets and Personal Access Tokens (PATs)
- Master practical commands and configurations to audit, harden, and continuously monitor GitHub repositories against information disclosure
- The Disclosure Mechanism: How Public Repositories Leak Private Reports
The researcher (reported by w2w) identified public GitHub profiles associated with HackerOne’s managed triage team. By reviewing recent commits across 44 public repositories, they discovered traces of IDOR exploitation scripts, GitHub Actions secret leak PoCs, token disclosures, CI/CD command injection payloads, and private program vulnerability details.
The core issue stems from a simple oversight: when security analysts create public repositories to reproduce vulnerabilities (sometimes necessary for demonstrating GitHub Actions leaks), they must either delete or privatize them afterward. In this case, the repositories remained public, and commit histories preserved sensitive artifacts including access tokens, server URLs, and secret leaks for various organizations’ tools and services.
Step-by-Step: Auditing Your Own GitHub Organization for Similar Leaks
Linux/macOS:
1. Clone a repository and examine its full commit history for secrets git clone https://github.com/target-org/target-repo.git cd target-repo git log -p | grep -iE "token|secret|key|password|api_key|private" --color=always <ol> <li>Use truffleHog to automatically scan for secrets in commit history Install: pip install truffleHog trufflehog --regex --entropy=True https://github.com/target-org/target-repo.git</p></li> <li><p>Search GitHub for your organization's sensitive strings Using GitHub CLI (gh) gh search code "ORG_NAME" --language=yml --extension=yml | grep -i "secret|token"
Windows (PowerShell):
Clone and search commit history git clone https://github.com/target-org/target-repo.git cd target-repo git log -p | Select-String -Pattern "token|secret|key|password|api_key" -CaseSensitive Use Gitleaks (download from https://github.com/gitleaks/gitleaks) gitleaks detect --source . --verbose
What This Does: These commands recursively scan repository commit histories for patterns matching common secret formats. TruffleHog and Gitleaks use entropy analysis to detect high-entropy strings that resemble API keys, even if they don’t match known patterns. Regular `git log -p` reviews are useful for manual inspection of recent commits.
- CI/CD Secrets Exposure: The GitHub Actions Attack Surface
The leaked repositories contained multiple examples of GitHub Actions secrets exposure. This mirrors real-world incidents like the tj-actions/changed-files compromise, where malicious code leaked CI/CD secrets to workflow logs, affecting approximately 23,000 repositories.
The attack vector is deceptively simple: a threat actor creates a pull request containing a malicious command injection in a workflow file (e.g., .github/workflows/pr-build.yml). When the workflow executes, it leaks secrets—including AWS keys, GitHub tokens, and database credentials—into publicly accessible logs.
Step-by-Step: Hardening GitHub Actions Workflows
Example of a vulnerable workflow (DO NOT USE):
name: CI
on: pull_request
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- run: echo "Deploying to ${{ secrets.AWS_SECRET_KEY }}" LEAKS SECRET!
Hardened workflow (RECOMMENDED):
name: CI
on:
pull_request:
branches: [bash]
permissions:
contents: read
pull-requests: read
jobs:
build:
runs-on: ubuntu-latest
permissions:
contents: read
steps:
- name: Checkout
uses: actions/checkout@v3
with:
persist-credentials: false
<ul>
<li>name: Run security scan
run: |
Never echo secrets
make test
env:
Use OIDC instead of static secrets where possible
AWS_ROLE_ARN: ${{ secrets.AWS_ROLE_ARN }}</p></li>
<li><p>name: Harden Runner
uses: step-security/harden-runner@v2
with:
egress-policy: block
Key Hardening Measures:
- Pin actions to commit SHAs, not version tags: `uses: actions/checkout@c85c95e3d72511b15b5d7af0f4d4f5b4d4f5b4d4` instead of `@v3`
2. Set explicit permissions using the `permissions:` field—never grant `contents: write` unless absolutely necessary - Use OpenID Connect (OIDC) for cloud authentication instead of storing static secrets
- Never echo or encode secrets in logs—GitHub automatically masks secrets in output, but encoding (Base64, hex) bypasses this protection
-
Implement runtime monitoring with tools like Harden-Runner to detect anomalies
-
IDOR Exploitation Scripts: What Was Exposed and How to Prevent It
The leaked repositories contained scripts specifically designed to exploit Insecure Direct Object References (IDOR) vulnerabilities in private HackerOne-managed programs. IDOR occurs when an application exposes internal object references (e.g., user_id=123) without proper authorization checks, allowing attackers to access unauthorized resources.
Step-by-Step: Detecting and Preventing IDOR Vulnerabilities
Using ScytheFuzzer for authorized IDOR testing (recon tool):
Install dependencies go install github.com/lc/gau/v2/cmd/gau@latest go install github.com/projectdiscovery/httpx/cmd/httpx@latest pip install uro Clone and run ScytheFuzzer git clone https://github.com/scythesec/scythefuzzer.git cd scythefuzzer chmod +x scythefuzzer.sh Single target ./scythefuzzer.sh example.com Review IDOR candidates cat scythe_output_/idor_candidates.txt
Manual IDOR testing approach:
1. Identify parameterized endpoints Look for patterns like: /api/user/123, /profile?id=456, /order/789 <ol> <li>Test horizontal privilege escalation curl -X GET "https://target.com/api/user/124" -H "Authorization: Bearer $TOKEN" Compare response for user 124 vs user 123 (your own)</p></li> <li><p>Test vertical privilege escalation curl -X GET "https://target.com/api/admin/users" -H "Authorization: Bearer $TOKEN" Check if regular user token grants admin access
Prevention Measures:
- Implement server-side authorization checks for every object access—never trust client-side references
- Use indirect reference maps (e.g., UUIDs instead of sequential integers)
- Apply Role-Based Access Control (RBAC) consistently across all API endpoints
- Conduct regular access control audits and use automated tools to detect IDOR patterns
4. Personal Access Token (PAT) Scope Abuse
The HackerOne disclosure also highlighted a related vulnerability: Personal Access Tokens (PATs) without the required `repo` scope could still retrieve issues and commits from private repositories via GitHub’s search REST API endpoints. This Incorrect Authorization flaw (CVE-2026-3582) allowed users who already had repository access through organization membership to leak private issues and commits using under-scoped tokens.
Step-by-Step: Auditing and Hardening PATs
List all PATs in a GitHub organization (GitHub CLI):
List all tokens for the authenticated user gh auth status gh api /users/octocat/personal-access-tokens Audit organization-level tokens gh api /orgs/ORG_NAME/personal-access-tokens --paginate Check token permissions gh api /user/personal-access-tokens/TOKEN_ID
Revoke tokens with excessive permissions:
Revoke a specific token gh api -X DELETE /user/personal-access-tokens/TOKEN_ID Or via GitHub UI: Settings > Developer settings > Personal access tokens
Best Practices for PAT Security:
- Limit PAT scopes to the minimum necessary (never use `repo` scope unless required)
- Regularly audit token permissions and revoke unused tokens
- Rotate tokens periodically and implement expiration dates
- Use fine-grained PATs (beta) that restrict access to specific repositories
- Monitor unusual PAT usage patterns—sudden spikes in API calls may indicate exfiltration
- Implement MFA on all accounts with PAT access
5. Secrets Detection and Continuous Monitoring
The exposed repositories contained multiple examples of secrets—access tokens, server URLs, and environment variables—leaked through commit histories and GitHub Actions logs. This underscores the need for automated secrets detection in CI/CD pipelines.
Step-by-Step: Implementing Secrets Detection
Using Gitleaks (cross-platform):
Install Gitleaks macOS: brew install gitleaks Linux: wget https://github.com/gitleaks/gitleaks/releases/latest/download/gitleaks_linux_x64.tar.gz Scan a repository gitleaks detect --source /path/to/repo --verbose Scan in CI/CD (GitHub Actions) Add to .github/workflows/security.yml:
name: Secrets Detection
on: [push, pull_request]
jobs:
secrets-scan:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
with:
fetch-depth: 0
- name: Run Gitleaks
uses: gitleaks/gitleaks-action@v2
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
Using truffleHog for deep history scanning:
Install truffleHog pip install truffleHog Scan entire repository history trufflehog --regex --entropy=True https://github.com/target-org/target-repo.git Scan GitHub organization trufflehog github --org=ORG_NAME --token=$GITHUB_TOKEN
Continuous Monitoring Strategy:
- Pre-commit hooks that block commits containing secrets
- CI/CD gates that fail builds if secrets are detected
- Runtime monitoring of GitHub Actions logs for suspicious patterns
- Regular secret rotation—assume any exposed secret is compromised
- Use external secret managers (HashiCorp Vault, AWS Secrets Manager) instead of hardcoding secrets in workflows
6. The Remediation Response and Lessons Learned
HackerOne’s response was swift: public repositories were hidden, sensitive repositories were deleted, internal security guidelines were improved, and additional analysts reviewed the exposure. The bounty of $2,700 was awarded for an Information Disclosure vulnerability with Medium severity (5.3 CVSS).
However, the incident raises deeper questions. As one observer noted: “Even if public repo creation is needed for vulnerability reproduction (for example, it’s compulsory for GH actions leak), it should be deleted or changed to the private state”. Furthermore, “All HackerOne-managed triage team GitHub and GitLab profiles should be private to avoid additional info leaks” and “shouldn’t have predictable usernames”.
Step-by-Step: Post-Incident Remediation Checklist
- Immediate: Identify and privatize or delete all public repositories containing sensitive data
2. Rotate all exposed credentials—tokens, keys, and secrets
- Audit commit histories of all repositories (public and private) for accidental secrets
- Implement repository scanning (Gitleaks, truffleHog) in CI/CD pipelines
- Enforce branch protection rules requiring PR reviews before merging
- Restrict GitHub Actions permissions at the organization level
7. Enable secret scanning in GitHub Advanced Security
- Conduct security awareness training for all team members with repository access
What Undercode Say
- Key Takeaway 1: The HackerOne incident demonstrates that security platforms are not immune to operational failures. The very act of reproducing vulnerabilities for triage purposes created a new attack surface. Organizations must treat their internal security tooling and repositories with the same rigor they apply to customer-facing systems.
-
Key Takeaway 2: CI/CD pipelines represent a critical and often overlooked attack vector. The combination of public repositories, GitHub Actions workflows, and exposed secrets creates a perfect storm. Implementing least-privilege access, OIDC authentication, and automated secrets detection is no longer optional—it’s a baseline requirement.
Analysis: This incident is emblematic of a broader trend: the democratization of security research has lowered barriers to entry, but it has also increased the complexity of managing sensitive data. Bug bounty programs, by their nature, involve sharing vulnerability details across organizational boundaries. Without strict operational security (OPSEC) controls—including repository hygiene, token management, and access controls—these programs can become liabilities. The $2,700 bounty, while modest, underscores an important point: information disclosure vulnerabilities in security platforms are often more valuable to attackers than to defenders. Organizations should treat their internal security repositories as crown jewels, applying the same zero-trust principles they recommend to their customers. The irony is palpable: the platform that protects vulnerabilities became the vulnerability. The lesson is clear—security is a continuous process, not a destination, and every component of the security ecosystem, including the tools used to manage it, must be continuously audited and hardened.
Prediction
- +1 This incident will accelerate adoption of automated secrets detection and repository scanning tools as standard components of CI/CD pipelines, reducing the frequency of similar leaks across the industry.
-
+1 Bug bounty platforms will implement stricter repository management policies, including mandatory privatization of reproduction repositories and randomized usernames for triage accounts, setting new industry standards for operational security.
-
-1 The increasing complexity of CI/CD pipelines and the proliferation of third-party GitHub Actions will continue to create supply chain vulnerabilities, with more incidents like tj-actions/changed-files exposing secrets at scale.
-
-1 As bug bounty programs grow, the attack surface for information disclosure will expand—attackers will increasingly target the platforms themselves, not just the vendors they protect, exploiting operational gaps in triage workflows.
▶️ Related Video (76% Match):
https://www.youtube.com/watch?v=1pG_jY1ybVY
🎯Let’s Practice For Free:
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
IT/Security Reporter URL:
Reported By: Bugbounty Hackerone – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
