---
title: "Bug Bounty Program"
description: "Learn how to report vulnerabilities in TurboPentest itself, understand severity tiers and rewards, and follow responsible disclosure practices."
canonical: https://turbopentest.com/learn/ecosystem/bug-bounty
source: "TurboPentest Learn"
---

# Bug Bounty Program

## Why TurboPentest Has a Bug Bounty

A security platform must hold itself to the highest security standards. TurboPentest's bug bounty program invites the security community to test the platform itself and report vulnerabilities responsibly. If we ask you to trust us with your pentesting, we must prove our own security posture is robust.

The program is open to all security researchers. You do not need to be a TurboPentest customer to participate.

## Scope

### In Scope

The following assets are in scope for the bug bounty program:

- **Web Application** - `turbopentest.com` (all routes including `/api`, `/learn`, etc.)
- **REST API** - All `https://turbopentest.com/api` endpoints
- **Authentication System** - Login, registration, session management, OAuth flows
- **Webhook System** - Webhook delivery, signature verification, callback handling
- **MCP Server** - The npm-distributed MCP server package
- **GitHub Action** - The `integsec/turbopentest-action` GitHub Action
- **Payment Processing** - Stripe integration, credit purchasing, and billing flows

### Out of Scope

The following are explicitly excluded:

- **Phase 1 Tools** - Vulnerabilities in the underlying third-party scanning engines should be reported to their respective maintainers
- **Paladin Agents** - The AI agents themselves (prompt injection against the pentesting agents is not a vulnerability in TurboPentest)
- **Social Engineering** - Phishing, pretexting, or social engineering attacks against TurboPentest employees
- **Denial of Service** - Volumetric DoS or DDoS attacks
- **Third-Party Services** - Vulnerabilities in Neon, Upstash, Vercel, or other infrastructure providers
- **Previously Reported** - Issues already reported by another researcher and under remediation

## Severity Tiers and Recognition

Every valid report is assigned a severity tier, and recognition scales with that tier. TurboPentest records a single `rewardTier` on each report and recognizes researchers at its discretion - there is no fixed, guaranteed per-severity credit payout. The tiers below describe the classes of vulnerability, from most to least impactful; treat any specific reward as discretionary recognition, agreed case by case, not an automatic scale.

### Critical

Vulnerabilities that could lead to:

- Remote code execution on TurboPentest infrastructure
- Access to other users' pentest results or account data
- Bypass of authentication to access any user's account
- Access to stored payment information or billing data
- Compromise of the webhook signing mechanism allowing forged notifications

### High

Vulnerabilities that could lead to:

- Privilege escalation (regular user gaining admin access)
- Stored XSS that executes in other users' sessions
- IDOR (Insecure Direct Object Reference) exposing other users' data
- API authentication bypass
- Credit manipulation (spending others' credits or generating free credits)

### Medium

Vulnerabilities that could lead to:

- Reflected XSS requiring user interaction
- CSRF on sensitive actions (password change, email change, API key generation)
- Information disclosure of non-sensitive internal data
- Rate limiting bypass on sensitive endpoints
- Insecure default configurations

### Low

Vulnerabilities that could lead to:

- Missing security headers (with demonstrated impact)
- Verbose error messages revealing stack traces or internal paths
- Subdomain takeover on non-sensitive subdomains
- Email enumeration via login or registration endpoints
- Missing best practices with minimal security impact

### Informational (acknowledged, no reward)

- Theoretical vulnerabilities without a proof of concept
- Issues requiring unlikely or impractical attack scenarios
- Best practice recommendations without security impact

## Reporting Process

### How to Submit

1. **Use the in-app form** - Submit your report through the bug-bounty submission form on the security page at `turbopentest.com/security`. Submissions post to the `/api/bounty/submit` endpoint and are run through an AI triage step before a human reviews them.
2. **Include** - A clear description of the vulnerability, steps to reproduce, proof-of-concept (screenshot, video, or code), and the potential impact
3. **Do not** - Exploit the vulnerability beyond what is necessary for the proof of concept. Do not access other users' data, exfiltrate data, or cause service disruption.

### Report Template

Use this structure for your report:

```
**Title**: [Brief description of the vulnerability]

**Severity**: [Your assessment: Critical/High/Medium/Low]

**Affected Asset**: [URL, endpoint, or component]

**Description**: [Detailed explanation of the vulnerability]

**Steps to Reproduce**:
1. [Step 1]
2. [Step 2]
3. [Step 3]

**Proof of Concept**: [Screenshots, video, or code]

**Impact**: [What an attacker could achieve]

**Suggested Fix**: [Optional but appreciated]
```

### Response Timeline

- **Acknowledgment**: Within 24 hours of submission
- **Triage**: AI triage runs on submission, then a human confirms validity and assigns a severity tier (target: within 3 business days)
- **Fix**: Depends on severity - Critical (24 hours), High (7 days), Medium (30 days), Low (90 days)
- **Recognition**: Discretionary, based on the assigned tier and agreed case by case after the fix is deployed
- **Disclosure**: Coordinated disclosure allowed 90 days after fix, or earlier with mutual agreement

## Responsible Disclosure

TurboPentest follows a coordinated disclosure model:

- **Do not disclose publicly** until the fix is deployed and the disclosure window has passed
- **Do not test against other users' accounts** - Create your own test accounts
- **Stop testing if you access real user data** - Report immediately and do not proceed further
- **Do not automate at scale** - Manual testing with reasonable request volumes only

Researchers who follow responsible disclosure practices receive public acknowledgment (with permission).

## Public Recognition

> **Roadmap - security hall of fame.** A dedicated public hall-of-fame page listing researchers who responsibly disclosed valid vulnerabilities is planned, but no such route exists yet - the security page (`turbopentest.com/security`) currently hosts the program overview and the submission form only. Until it ships, recognition is arranged directly with the researcher (with their permission).

Public acknowledgment requires:
- A valid, in-scope report
- Following responsible disclosure practices
- Opting in to public acknowledgment

## Bug Bounty Hunter Discord Role

Researchers who submit at least one valid report earn the Bug Bounty Hunter role on the TurboPentest Discord server. This role provides recognition and access to the #bug-bounty channel for discussing security research methodology with other hunters.
