Skip to content

Redox

Bug bounty on HackerOne redoxengine.com

Accepting reports
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 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.

Search 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.com email 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.*.js or 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!