Bug Bounty Program
216Labs welcomes good-faith security research against our public application portfolio. This page describes scope, rules, safe harbor, and how to report findings.
Program overview
We run a coordinated disclosure program. Please report vulnerabilities to us first and give us reasonable time to remediate before any public disclosure. Do not access, modify, or destroy data that does not belong to you; limit impact to what is necessary to demonstrate the issue.
This program covers Internet-facing properties we operate for the portfolio hosted under *.6cubed.app. The list of apps evolves; the canonical entry point is 6cubed.app.
In scope
Generally in scope when testing in good faith:
- Public web applications and APIs served under
*.6cubed.appas part of the 216Labs production deployment (each app subdomain, the root site, and documented public endpoints). - Vulnerabilities that affect confidentiality, integrity, or availability of these services or their users (e.g. XSS, CSRF where impactful, SSRF, injection, authentication or authorization flaws, sensitive data exposure).
- Misconfiguration that materially increases risk (e.g. open redirects combined with other issues, clear exposure of secrets in public responses), assessed case by case.
Authenticated testing
If you need an account to validate a report, describe the limitation in your initial email. We may provide a test account or guidance where appropriate. Do not use or guess other people's credentials.
Out of scope
The following are not eligible unless we explicitly say otherwise:
- Denial of service or load testing that degrades production (including application-layer floods). Use minimal traffic to confirm a logic bug.
- Physical security, social engineering (including phishing support or staff), or attacks against our suppliers' employees.
- Spam, mass automated scanning without regard for rate limits, or brute-force / credential stuffing against production accounts.
- Issues in third-party services, libraries, or infrastructure we do not control (report them to the vendor; we still appreciate a heads-up if it affects us).
- UI-only bugs with no plausible security impact, missing best-practice headers without demonstrable exploit, or self-XSS.
- Known-vulnerable dependencies already tracked by our process, or issues we have already triaged as duplicates (we will tell you).
- Content issues (typos, SEO) and non-security functional bugs (use normal product channels).
The admin and internal operations surfaces may require separate coordination. Do not pivot from a finding into bulk access of deployment keys, user databases, or infrastructure beyond what is needed for a concise proof of concept.
Rules of engagement
- Comply with applicable laws and this policy.
- Minimize harm: no destructive actions, no extortion, no public leaks of user data.
- Stop and report if you accidentally encounter highly sensitive data; do not download large datasets to "prove" access.
- One account per researcher where we issue test credentials; do not share access.
- We may update this page; check the live policy when you test.
Safe harbor
When you act in good faith and follow this policy, we will not pursue civil action or law-enforcement complaints against you for accidental, policy-conforming research. This does not bind third parties and is not a promise of immunity from all legal risk—if you are unsure, consult qualified counsel.
We consider good faith to include: proportional testing, prompt reporting, and avoiding privacy violations and service disruption as described above.
Severity & rewards
We triage using industry-standard concepts (e.g. CVSS-style impact). Rewards, if any, are at our discretion, may vary by impact and exploitability, and can include public recognition where you agree. Past rewards do not guarantee future ones.
| Tier | Examples (non-exhaustive) |
|---|---|
| Critical | Remote code execution, systemic auth bypass exposing many accounts, wormable XSS chain with proven impact |
| High | Significant data breach, account takeover at scale, severe SSRF to internal services |
| Medium | Targeted privilege issues, stored XSS with real user impact, meaningful IDOR with sensitive data |
| Low | Minor information leaks, limited CSRF, issues requiring unlikely user interaction |
Duplicates: first actionable report wins; variants of the same root cause may be merged.
How to report
Email security@6cubed.app with the subject line starting [216Labs BB]. Include:
- Affected URL(s) or endpoint(s) and whether production or staging (production preferred for impact).
- Step-by-step reproduction and, if possible, a minimal proof of concept.
- Your assessment of severity and impact; screenshots or redacted logs if helpful.
- Whether you want public credit (name / handle / link) after fix.
PGP: if you need encrypted email, ask for our current key in your first message.
What to expect
We aim to acknowledge reports within a few business days and keep you informed through triage and fix. Timelines depend on severity and complexity. We may ask clarifying questions; responsiveness helps resolution.
Eligibility
Employees, contractors, and others with privileged insider access are excluded from rewards for issues they could have reported through internal channels. Researchers must not be on sanctions lists where it would prohibit payment or engagement. Void where prohibited by law.