- Top reward
- $7,500
- Top severity paid
- Critical
- Assets in scope
- 9
- Public CVEs
- 0
- Last change
- No changes yet
At a glance
What to know before you start testing.
- Pays up to $7,500
- for critical bugs.
- Report on HackerOne
- Submit through the program page.
- Replies within 2 days
- As the policy promises.
- No public write-ups
- Keep findings private.
Rewards
What HackerOne lists as the payout for each severity.
| Severity | Relative size | Reward |
|---|---|---|
| Critical |
|
$7,500 from $1,500 |
| High |
|
$3,000 from $500 |
| Medium |
|
$1,000 from $150 |
| Low |
|
$400 from $200 |
- Response
-
Within 2 days
First Response | 2 days
Summarised with AI from the program policy on HackerOne, read 12 Nov 2026, and checked word for word against it. Read the original
Scope
9 assets you may test, 6 excluded.
Web 8
- 10x.redoxengine.com Critical
- docs.redoxengine.com Medium
- explore.redoxengine.com Medium
- fhir.redoxengine.com Medium
- help.redoxengine.com Medium
- testapi.redoxengine.com Critical
- testapp.redoxengine.com Critical
- www.redoxengine.com Medium
Wildcard domains 1
- test*.redoxengine.com Critical
Out of scope (6)
- api.redoxengine.com
- candi.redoxengine.com
- dashboard.redoxengine.com
- https://redoxengine.atlassian.net
- redox.slack.com
- sso.redoxengine.com
Rules
What the policy asks of you, and the bug types it won't reward, quoted from Redox (via HackerOne)'s policy.
While testing
-
Social engineering (e.g., phishing, vishing, smishing) is prohibited.
-
Make a good faith effort to avoid privacy violations, data destruction, and service interruption or degradation.
-
Only interact with accounts you own or with explicit permission from the account holder.
-
Use your `@wearehackerone.com` email address when creating accounts
-
Always use the staging equivalents below for testing.
-
Submit one vulnerability per report, unless you need to chain vulnerabilities to demonstrate impact.
-
Provide detailed reports with reproducible steps.
-
As this is a private program, do not discuss the program or any vulnerabilities (even resolved ones) outside of the program without express consent from Redox.
Not accepted
-
Clickjacking on pages with no sensitive actions
-
Cross-Site Request Forgery (CSRF) on unauthenticated forms or forms with no sensitive actions
-
Attacks requiring MITM or physical access to a user's device
-
Previously known vulnerable libraries without a working Proof of Concept
-
CSV injection without demonstrating a vulnerability
-
Missing best practices in SSL/TLS configuration
-
Content spoofing and text injection issues without showing an attack vector or ability to modify HTML/CSS
-
Missing best practices in Content Security Policy
-
Missing HttpOnly or Secure flags on cookies
-
Missing email best practices (invalid, incomplete, or missing SPF/DKIM/DMARC records, etc.)
-
Vulnerabilities only affecting users of outdated or unpatched browsers (less than 2 stable versions behind the latest release)
-
Software version disclosure, banner identification issues, or descriptive error messages/headers (e.g., stack traces, application or server errors)
-
Public zero-day vulnerabilities that have had an official patch for less than 1 month (awarded on a case-by-case basis)
-
Tabnabbing
-
Open redirect (unless an additional security impact can be demonstrated)
-
Any activity that could lead to service disruption (DoS)
-
Removing all organization owners or demoting all users to "basic user" role
-
Creating an organization with the same name as an existing organization
-
Broken Link Hijacking on https://www.redoxengine.com
-
Demo Personal Identifiable Information (PII) in `/static/js/main.*.js` or in API Actions
-
Ability to create resources (alerts, sources, destinations) as a Free Tier User/Org
Summarised with AI from the program policy on HackerOne, read 12 Nov 2026, and checked word for word against it. Read the original
Changes
Tracked since 11 Nov 2026. Last checked 17 minutes ago.
No changes yet. When the rewards or scope move, you will see it here and in the RSS feed.
Public CVEs
Published vulnerabilities in this vendor's products, from the NVD.
No CVEs matched yet. We match NVD records by vendor name, so products sold under another name can be missing.
Original policy
Copied from hackerone.com on 12 Nov 2026. The summaries on this page are made from it; the live page may have changed since.
Our Security team identifies, evaluates, and manages vulnerabilities across Redox, including corporate assets, applications, and cloud infrastructure. Our purpose is to reduce risk exposure and support our goal to become the most trusted brand in healthcare technology.
With you as an extension to our team, we can achieve that goal and ultimately protect patient data.
Response Targets
Redox will make a best effort to meet the following SLAs for hackers participating in our program:
| Type of Response | SLA in business days |
|---|---|
| First Response | 2 days |
| Time to Triage | 2 days |
| Time to Bounty | 14 days |
| Time to Resolution | depends on severity and complexity |
Important: Even after HackerOne triage, the Redox team may close a ticket at any time with no payout (e.g., if it's a duplicate or we decide not to fix the issue). For duplicates, we may not provide links to the original ticket, especially if the original reporter prefers privacy or the ticket is in our internal system.
We’ll try to keep you informed about our progress throughout the process.
Program Rules
Report Requirements:
- Provide detailed reports with reproducible steps. Reports lacking sufficient detail for reproduction are not eligible for rewards.
- Submit one vulnerability per report, unless you need to chain vulnerabilities to demonstrate impact.
- When duplicates occur, we only award the first report received (provided it can be fully reproduced). Evidence will be provided via the original ticket number and/or title.
- Multiple vulnerabilities caused by one underlying issue will receive one bounty.
Testing Guidelines:
- Social engineering (e.g., phishing, vishing, smishing) is prohibited.
- Make a good faith effort to avoid privacy violations, data destruction, and service interruption or degradation.
- Only interact with accounts you own or with explicit permission from the account holder.
Eligibility:
- Current Redox employees and contractors are not eligible. Former employees and contractors become eligible 6 months after termination.
Getting Started
Account Setup and Permissions
To begin testing, request elevated permissions through our Service Portal: - Google Form - Request for Elevated Permissions / Account Provisioning
This allows us to provision resources specific to your testing.
Account Requirements:
- Use your
@wearehackerone.comemail address when creating accounts - If you need separate accounts, you can use an alias
- This helps us identify you as a researcher, not a malicious user
Testing Guidance:
- Reference our Change Log for the latest product additions and functionality to test
Test Environment URLs
Important: All documentation references production resources. Always use the staging equivalents below for testing.
| Staging URL (Use for Testing) | Production Equivalent | Description |
|---|---|---|
| 10x.redoxengine.com | dashboard.redoxengine.com | UI - Frontend of Dashboard |
| testapp.redoxengine.com | candi.redoxengine.com | API - Backend of Dashboard |
| testapi.redoxengine.com | api.redoxengine.com | API - FHIR/DataModel API |
API Documentation
Program Scope
Critical Application Resources
We are primarily looking for vulnerabilities in these critical resources:
- 10x.redoxengine.com (Main Dashboard)
- testapp.redoxengine.com (Dashboard Backend API)
- testapi.redoxengine.com (FHIR/DataModel API)
Out of Scope
When reporting vulnerabilities, please consider (1) attack scenario/exploitability, and (2) security impact. The following issues are out of scope:
- Clickjacking on pages with no sensitive actions
- Cross-Site Request Forgery (CSRF) on unauthenticated forms or forms with no sensitive actions
- Attacks requiring MITM or physical access to a user's device
- Previously known vulnerable libraries without a working Proof of Concept
- CSV injection without demonstrating a vulnerability
- Missing best practices in SSL/TLS configuration
- Content spoofing and text injection issues without showing an attack vector or ability to modify HTML/CSS
- Missing best practices in Content Security Policy
- Missing HttpOnly or Secure flags on cookies
- Missing email best practices (invalid, incomplete, or missing SPF/DKIM/DMARC records, etc.)
- Vulnerabilities only affecting users of outdated or unpatched browsers (less than 2 stable versions behind the latest release)
- Software version disclosure, banner identification issues, or descriptive error messages/headers (e.g., stack traces, application or server errors)
- Public zero-day vulnerabilities that have had an official patch for less than 1 month (awarded on a case-by-case basis)
- Tabnabbing
- Open redirect (unless an additional security impact can be demonstrated)
- Any activity that could lead to service disruption (DoS)
- Rate limiting or bruteforce issues on non-authentication endpoints and our external Help Desk forums (https://redoxengine.atlassian.net/servicedesk/customer/portals)
- Removing all organization owners or demoting all users to "basic user" role
- Creating an organization with the same name as an existing organization
- Broken Link Hijacking on https://www.redoxengine.com
- Demo Personal Identifiable Information (PII) in
/static/js/main.*.jsor in API Actions - Ability to create resources (alerts, sources, destinations) as a Free Tier User/Org
- Note: There is a frontend UI block, but no backend resource blocking for this.
Denial of Service (DoS) Policy
DoS vulnerabilities are out of scope (any attack requiring more than a small number of resources). DoS vulnerabilities causing application "slowdown" will be considered Informational, unless the researcher can demonstrate the bug is severe enough to disable other sessions and site functionality without significant resources. Bugs that cannot clearly show impact on other users without significant resources will be considered DDoS.
Rate Limiting Infrastructure:
We utilize a Web Application Firewall (WAF) for rate limiting:
- API traffic: 5000 requests per 5 minutes per IP
- HTTP traffic: 500 requests per 5 minutes per IP
Disclosure Policy
- As this is a private program, do not discuss the program or any vulnerabilities (even resolved ones) outside of the program without express consent from Redox.
- Follow HackerOne's disclosure guidelines.
Thank you for helping to secure Redox!