HackerOne bug bounty automation - parses scope CSVs, deploys parallel pentesting agents per asset, validates PoCs, and generates platform-ready submission reports.
The English summary is being prepared. Showing the original description.
Run score Not tested
See how to installReview the instructions the agent will receive before you install.
Automates: scope parsing → parallel testing per asset → authoritative finding validation → submission reports.
skills/coordination/SKILL.md).validate-findings workflow per asset (authoritative submission gate). Generate HackerOne reports from the validated set ONLY — never submit a finding that is not VALID/REPAIRED.Expected columns:
identifier — asset URL/domain.asset_type — URL, WILDCARD, API, CIDR.eligible_for_submission — must be true.max_severity — critical / high / medium / low.instruction — asset-specific notes.Parse with skills/hackerone/tools/csv_parser.py. Filter for eligible_for_submission=true.
One coordinator per asset, spawned in parallel:
coordinator_role = Read("skills/coordination/SKILL.md")
Agent(prompt=f"{coordinator_role}\n\nTARGET: {asset_url}\nSCOPE: {program_guidelines}\nOUTPUT_DIR: ...",
run_in_background=True)
10 assets → 10 parallel coordinators (~2-4 h vs 20-40 h sequential). Each coordinator follows skills/coordination/SKILL.md and reference/role-matrix.md.
Every finding requires poc.py (executable exploit), poc_output.txt (timestamped execution proof), manual repro steps, and evidence (screenshots / HTTP captures / video). This is the input the validator consumes.
After each asset's coordinator returns, the orchestrator runs the validate-findings workflow for that asset and submits ONLY findings it marks VALID or REPAIRED:
v = Workflow(name="validate-findings", args={
"output_dir": asset_output_dir, # the coordinator's OUTPUT_DIR
"target": asset_url,
"business_tier": "revenue", # production/external bug-bounty scope; else "unknown"
"votes": 3, # adversarial refuters per finding (bounty = stricter)
"repair": True, # regenerate broken/absent PoCs so each finding has a runnable evidence script
"strict": True, # one failed gate => REJECTED
})
# v.counts -> {total, valid, repaired, rejected}; v.validated[] / v.rejected[]
# Verdicts at {asset_output_dir}/artifacts/validated/{id}.json (+ false-positives/).
# Asset report at {asset_output_dir}/reports/validation-report.md.
validate-findings is the authoritative gate because it directly preempts the most common HackerOne rejections: it verifies each CVE against NVD + a recomputed CVSS base score (from the vector) + CISA KEV + the vendor advisory, runs (and repairs) every PoC until it emits the evidence that proves the issue, recomputes the risk/severity, corroborates every claim against raw evidence, and kills false positives via adversarial refutation.
The orchestrator is the only layer that runs this workflow (it is top-level; the workflow is one level below — legal nesting). To avoid double work, coordinators may treat their interleaved per-finding validators (run the instant each candidate is materialized) as a provisional self-check; the standalone validate-findings verdict is authoritative for submission. A REJECTED finding is a false positive — it never enters a submission, an appendix, or a count; its artifacts/false-positives/{id}.json is the sole record. Likewise a coordinator-dropped candidate (uncured DEMOTED, in artifacts/dropped/) is never submitted.
The HackerOne PoC contract is a superset of the standard finding contract (skills/coordination/reference/validator-role.md).
Build each report from a validated finding only. Required sections per HackerOne standard:
validate-findings recomputed from the vector and the risk bucket it assigned, not a hand-typed number.verification-script.py.evidence/validation/).Validate report format with skills/hackerone/tools/report_validator.py (complements the finding validation).
Standard OUTPUT_DIR (skills/coordination/reference/output-discipline.md) plus a per-asset reports/submissions/ containing the platform-ready markdown. validate-findings writes the verdicts under artifacts/validated|false-positives/ and the asset reports/validation-report.md.
{OUTPUT_DIR}/
├── findings/
│ └── finding-NNN/evidence/validation/ # validate-findings proof packages
├── reports/
│ ├── submissions/ # built ONLY from artifacts/validated/
│ │ ├── H1_CRITICAL_001.md
│ │ └── H1_HIGH_001.md
│ ├── validation-report.md # validate-findings asset report
│ └── SUBMISSION_GUIDE.md
├── recon/
├── logs/
└── artifacts/
├── validated/ # {id}.json — submit these
└── false-positives/ # {id}.json — never submit these
High-value: new programs (< 30 days), fast response (< 24 h), high bounties, large attack surface. Avoid: slow response (> 1 week), low bounties, restrictive scope.
validate-findings verdict = VALID or REPAIRED (artifacts/validated/{id}.json exists). Never submit a REJECTED finding.evidence/validation/cve-verification.md).poc_output.txt (the validator re-ran/repaired it and confirmed the evidence token).evidence/validation/risk-assessment.md).eligible_for_submission=true.| Rejection | Prevention |
|---|---|
| Out of Scope | Verify eligible_for_submission=true and asset-type match |
| Cannot Reproduce | validate-findings re-runs (and repairs) the PoC 3× and requires a vuln-class evidence token — only reproducible findings pass the gate |
| Duplicate | Search disclosed reports before submission; submit quickly |
| Insufficient Impact | Document realistic attack scenario; validate-findings recomputes risk/severity so the rating is defensible |
| Incorrect severity / CVSS | validate-findings recomputes the base score from the vector and cross-checks NVD + KEV; any mismatch is flagged before you submit |
skills/hackerone/tools/csv_parser.py — parse HackerOne scope CSVs.validate-findings workflow — authoritative per-asset finding validation (NVD/CVSS-math/KEV/exploit-run/repair/risk/adversarial). The submission gate; run once per asset.skills/hackerone/tools/report_validator.py — validate report format completeness (the 6 submission sections). Complements validate-findings (which validates the finding); run it on each report built from a validated finding.skills/coordination/SKILL.md — coordinator scaffold./hackerone <program_url_or_csv_path>
No reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
Offensive AI security testing and exploitation framework. Systematically tests LLM applications for OWASP Top 10 vulnerabilities including prompt injection, model extraction, data poisoning, and supply chain attacks. Integrates with pentest workflows to discover and exploit AI-specific threats.
The English summary is being prepared. Showing the original description.
API security testing - GraphQL, REST API, WebSocket, and Web-LLM attack techniques.
The English summary is being prepared. Showing the original description.
Stitches confirmed single-asset findings into multi-hop attack paths across the organization. Builds a graph where nodes are assets and edges are confirmed exploit hops citing the findings that enable them.
The English summary is being prepared. Showing the original description.
Acquire an authenticated session THROUGH MFA/OTP on an in-scope target and emit a reusable session artifact (Playwright storageState + Bearer) so executors can test the post-auth attack surface. Use when the highest-value authenticated classes (BOLA/IDOR/mass-assignment/injection on the real data APIs) are blocked because login is gated by SMS-OTP or TOTP MFA. Distinct from the authentication skill (which ATTACKS auth); this one legitimately authenticates and hands the session to the rest of the engagement.
The English summary is being prepared. Showing the original description.
Authentication security testing - auth bypass, JWT attacks, OAuth flaws, password attacks, 2FA bypass, CAPTCHA bypass, and bot detection evasion.
The English summary is being prepared. Showing the original description.
Smart contract security testing and blockchain CTF exploitation. Covers Solidity vulnerability analysis, EVM storage manipulation, delegatecall attacks, CREATE/CREATE2 address prediction, and common DeFi exploit patterns. Use when analyzing Solidity contracts, solving blockchain challenges, or testing smart contract security.
The English summary is being prepared. Showing the original description.