Ubiquiti Inc.

Introduction

At Ubiquiti Inc. ("Ubiquiti"), we take security very seriously, and embrace the security research community. We provide products and services that millions around the world use every day, and understand privacy and security is very important to our customers. Therefore, Ubiquiti offers this Security Reward Program ("Program") to continuously improve the security of our products, while publicly recognizing the security enthusiasts submitting valid issues. If you believe you have found a vulnerability in any of Ubiquiti's products or services, let us know as soon as possible, and we'll do our best to get the issues addressed as quickly as possible.

By clicking "Submit Report", you consent to your information being transferred to and stored in the United States and acknowledge that you have read and accepted the Terms, Privacy Policy and Disclosure Guidelines presented to you when you created your account.

Please read the rules described in this policy carefully. By clicking "Submit Report", you agree to comply with all such rules. Violations of the rules are grounds for immediate forfeiture of any reward as well as possible removal from the Program

General Rules

• This Program is limited strictly to technical vulnerabilities of Ubiquiti products and services.
• Do not exploit, investigate or target vulnerabilities in any other user’s account or Ubiquiti product not owned by you.
• Do not cause harm to Ubiquiti, our customers, or third parties.
• Do not compromise the privacy or safety of our customers and the operation of our services. Any activity that would disrupt, damage or adversely affect any third-party data, account or equipment is not allowed.
• Do not violate any criminal law or other applicable laws.
• Confirm that you are not currently located in or otherwise ordinarily resident of a sanctioned country (for example, Cuba, Iran, North Korea, Sudan, Syria or Crimea) and not on the U.S. Department of the Treasury’s Specially Designated Nationals List.
• You must not be the author of the code with the vulnerability or bug.
• Public disclosure or limited private release of any vulnerability to any other party in violation of the Disclosure Guidelines below will disqualify such vulnerability from consideration.
• Any vulnerability disclosed to any third party that might potentially exploit the vulnerability, including vulnerability brokers, will disqualify such vulnerability from this Program.
• The following are strictly prohibited:
  • Physical attacks on Ubiquiti infrastructure or facilities
  • DOS attacks are not allowed
  • Social engineering attacks or phishing.

Program Scope

The Program encompasses all of Ubiquiti's products. Including, but not limited to:

Web Products

• *.ubnt.com and *.ui.com -- any web applications under ubnt.com or ui.com domains (WWW, SSO Account, etc.).
• Current and future cloud applications
• Exceptions: sites on *.ubnt.com or *.ui.com domains but hosted by a third party are not in scope. For example: training.ui.com (Training) and ir.ui.com (Investor Relations). While we are thankful for any reports against these sites, we are unable to issue rewards

Platform Products

• airMAX, UniFi, UniFi Protect, EdgeMAX, airFiber and UFiber embedded devices
• Distributed Software Platforms -- Any controller software, such as UniFi Network, and others
• Exceptions: any product that’s End-of-Life.

We consider a vulnerability to be an error, flaw, mistake, failure or fault in a computer program or system that impacts the security of a device, system, network or data.

Some examples of vulnerabilities include:

• Remote code execution
• Authentication bypass, unauthorized data access
• SQL injection
• XSS, XSRF, CSRF

You must be the first to report a certain issue. Vulnerabilities eligible for reward or recognition must be new and previously unreported. In the event of duplicate vulnerability submissions, only the earliest submission with sufficient actionable information will be considered for a reward.

In general, any vulnerability may be considered for this Program, however, please see exceptions below.

Exceptions & Additional Rules

• While we encourage any submission affecting the security of Ubiquiti products or platforms, unless evidence is provided demonstrating exploitability, the following examples are excluded from this Program:
  • Clickjacking
  • Issues without clearly identified security impact, missing security headers, or descriptive error messages
  • Missing best practices, information disclosures, use of a known-vulnerable libraries or descriptive / verbose / unique error pages (without substantive information indicating exploitability)
  • Speculative reports about theoretical damage without concrete evidence or some substantive information indicating exploitability
  • Forms missing CSRF tokens without evidence of the actual CSRF vulnerability
  • Self-exploitation (e.g., cookie reuse)
  • Reports of insecure SSL / TLS ciphers (unless you have a working proof of concept, and not just a report from a scanner)
  • Our policies on presence/absence of SPF / DMARC records
  • Password complexity requirements, account/e-mail enumeration, or any report that discusses how you can learn whether a given username or email address has a Ubiquiti-related account
  • Missing security-related HTTP headers which do not lead directly to a vulnerability, including but not limited to X-Xss-Protection, X-Content-Type-Options, Content-Security-Policy-Report-Only, etc.
  • Self XSS vulnerabilities without evidence on how the vulnerability can be used to attack another user
  • Presence of autocomplete attribute on web forms
  • Missing secure cookie flags on non-sensitive cookies
  • Banner identification issues
  • Open ports which do not lead directly to a vulnerability
  • Open redirect vulnerabilities
  • Publicly accessible login panels
  • Content spoofing / text injection
  • Any vulnerability that makes use of Spanish Inquisition, we aren’t expecting that!
  • Reports involving backup file decryption, since backups are not considered encrypted and can be restored on any other installation.
  • Reports that rely on a device, service, or system being unconfigured, unclaimed, or still in the initial setup process are not eligible. Administrators are responsible for exposing systems publicly only after setup has been completed.

Reporting Template

Please be aware that the quality of your report is critical to our evaluation of your submission. We encourage you to use the list below as a template for your report. This does NOT mean you need to fully exploit the issue, just provide the information with as much detail as possible.

• State the name of the applicable product or platform, including the version numbers.
• Describe the type of issue with as much detail as possible.
• What are all the steps required to reproduce the issue?
• What is the impact of your issue?
• What are some scenarios where an attacker would be able to exploit this vulnerability? A proof of concept or functional exploit code would be helpful.
• If available, what would be your recommended fix?

Rewards

Rewards may vary depending on the application, the risk, complexity, impact and overall severity of the vulnerability. The internal criteria that we use to determine a reward is subject to change from time to time. Historical rewards paid for a vulnerability report does not indicate and will not be used as a basis to determine future payout for vulnerability of a similar type.

Our reward panel will review each vulnerability submission for eligibility and final reward consideration. Final reward amounts are at the sole and final discretion of Ubiquiti's reward panel. In some instances, our reward panel may choose higher rewards for unusually major, clever or complex vulnerability submissions.

If we receive several reports for the same issue, we offer the reward to the earliest report for which we have enough actionable information to identify the issue.

If a single fix resolves multiple vulnerabilities, we treat this as a single vulnerability, which will receive a single bounty.

Rewards may be reduced or declined if there is evidence of abuse, such as data exfiltration or withholding reports in order to chain multiple issues together.

PLEASE NOTE: Due to the significant increase in vulnerability submissions since March 2026, primarily from AI-assisted research and automated testing, Ubiquiti has changed its bounty payment process. For eligible submissions, 100% of the reward will be paid only after the vulnerability has been remediated and the report has been closed as Resolved. Ubiquiti no longer provides partial or advance payments when a vulnerability is initially confirmed. This allows Ubiquiti to complete all eligibility and duplicate checks, as related or duplicate reports may be identified during remediation. When requested, payment may also be dependent on successful verification of the remediation by both the researcher and Ubiquiti.

Rewarding Formula

Starting on August 1st, 2020, all-new reports will be based on the following rules.

Base Formula: (3^(x,x-1))*(AV/(3^9))

Where "x,x" is the CVSS score and maximum bounty is AV limit USD

Payment Limits: Limits will be applied based on Attack Vector rules: Limit 1 (Physical) = 1,000 Limit 2 (Local)= 2,500 Limit 3 (Adjacent)= 4,000 Limit 4 (LAN Side) = 8,000 Limit 5 (Server) = 10,000 Limit 6 (WAN Side) = 25,000 Limit 7 (Ubiquiti Cloud) = 30,000

Decrease Bounty Drivers: Privileges Required High (Admin access, other than view/read-only access) = Base Score / 6 High (View/Read-only admin access) = Base Score / 4 Low (User without admin permissions) = Base Score / 2

User Interaction: Required = Base Score / 4

Example: UI + Priv(L)(H) = (Score/4) /2 or /4 or /6

• LAN Side (Internal Network) Applies to all reports involving devices or services that are not directly accessible from the Internet, or that are intended to operate only within a local network. Examples: Switches, Access Points, NAS, NVR, Cloud Keys, UniFi Protect, UniFi Connect, UniFi Talk, UniFi Access and UniFi Play devices.

• Server Applies to vulnerabilities affecting Ubiquiti server applications, including customer-hosted deployments and the following Ubiquiti-hosted server services:

• UniFi OS Server
• UniFi Network Server
• UISP Server
• UniFi Official Hosting
• UISP Hosting Professional

The Server limit applies regardless of whether the affected server is operated by the customer, hosted by Ubiquiti, accessible from the Internet, or restricted to a local network.

For clarity, reports affecting UniFi Official Hosting or UISP Hosting Professional are classified under the Server category, not the Ubiquiti Cloud category.

• WAN Side (Internet) Applies to reports involving products or services that are directly accessible from the Internet by design.

This category excludes:

• Products classified under the Server or LAN Side categories
• Products designed exclusively for local network operation
• Reports that require changing the default firewall configuration, forwarding ports, or otherwise exposing a product to the Internet

• Ubiquiti Cloud

Applies to vulnerabilities whose root cause and affected component are part of a Ubiquiti-operated cloud service.

Reports are classified based on the affected component, not merely the domain or access method used during exploitation. Accessing a device or server through unifi.ui.com (Site Manager) or uisp.com does not automatically classify the report as Ubiquiti Cloud.

These services may act as a proxy or remote access path to a customer-managed device or server. If the vulnerability and required remediation are located on the customer-managed device, server, or its application, the applicable LAN Side or Server limit applies.

The Ubiquiti Cloud limit applies only when the vulnerability and required remediation are within the Ubiquiti-operated cloud service itself.

Recognition

Ubiquiti may publish a leaderboard of vulnerability reporters based on previous security vulnerability and bug reports. These previous reporters may receive special access to Ubiquiti engineers. If you wish to remain anonymous to the public, we will honor your request.

Disclosure Guidelines

Guidelines for Web Products:

We ask you to please wait until thirty (30) days after the vulnerability relating to the Web Products is fixed and the fix is publicly released before any disclosure.

When the completion date of a fix is not yet available or cannot be ascertained, we ask you to give us time to remediate the issue and refrain from any public disclosure.

Guidelines for Platform Products:

Because the users of our Platform Products have exclusive control over their devices, HackerOne’s disclosure guidelines shall not apply with respect to any vulnerabilities submitted in relation to our Platform Products.

The disclosure guidelines for vulnerabilities submitted in relation to our Platform Products are determined by reference to the significance of the vulnerability (as determined in the sole and absolute discretion of Ubiquiti), as follows:

• Minor issues: Limited disclosure (i.e., a summary written by Ubiquiti) is allowed 60 days after we publicly release the security fix.
• Significant, but non-critical issues: Limited disclosure (i.e., a summary written by Ubiquiti) is allowed 120 days after we publicly release the security fix.
• Critical issues: Limited disclosure (i.e., a summary written by Ubiquiti) may be allowed on a case-by-case determination after we publicly release the security fix.

All disclosure shall be limited to a summary of the relevant vulnerabilities written by Ubiquiti. Full disclosure of the submitted report or the underlying vulnerabilities relating to the Platform Products is not allowed under any circumstances.

Posting details or conversations about the vulnerabilities in violation of the disclosure guidelines reflects poorly on this Program and jeopardize the security and privacy of our customers. VIOLATION OF THE DISCLOSURE GUIDELINES ABOVE WILL RESULT IN FORFEITURE OF ANY REWARD AND/OR IMMEDIATE REMOVAL FROM THIS PROGRAM.

Legal

Ubiquiti reserves the right to modify this policy or terminate this Program at any time and for any reason.

You hereby represent and warrant that all submissions are your original work and you own all right, title and interest therein and thereto. You grant Ubiquiti and its affiliates a worldwide, perpetual, irrevocable, non-exclusive, transferable, fully paid and royalty-free license under any intellectual property rights or other rights to use, copy, modify, create derivative works based upon and otherwise exploit the materials submitted by you.

All reward payments are subject to compliance with local laws, rules and regulations. Before you receive your reward, we may require that you sign an affidavit of eligibility, a questionnaire, and a release of liability. You will be solely responsible for all applicable taxes relating to any reward under this Program.

Any information you receive or collect about Ubiquiti, its affiliates or any of their customers, employees or agents in connect with this Program ("Confidential Information") must be kept confidential and only used in connection with this Program. You may not use, disclose or distribute any such Confidential Information without Ubiquiti’s prior written approval.

Security Vulnerability Report Submission and Validation Policy

1. Purpose

This policy defines the minimum quality, testing, validation, and documentation requirements for security vulnerability reports submitted to Ubiquiti.

The purpose of this policy is to:

• Ensure reported issues can be reproduced efficiently.
• Confirm that reported vulnerabilities affect supported, real-world deployments.
• Reduce delays caused by incomplete, speculative, or unvalidated reports.
• Help the security team make accurate severity and bounty decisions.
• Establish consistent requirements for all security researchers.

2. Scope

This policy applies to:

• All security researchers.
• All new vulnerability reports.
• Updates and follow-up information added to existing reports.
• Proof-of-concept scripts and supporting evidence.
• Reports created with automated tools or AI assistance.

All reports must be manually reviewed and validated by the researcher before submission.

3. General Submission Requirements

Every report must clearly demonstrate:

• How the affected product is normally configured and used.
• How the reported condition is reached through a supported deployment.
• What access, role, and permissions the attacker has.
• How another person can reproduce the issue.
• What security boundary is crossed.
• What practical security impact results from successful exploitation.

The use of AI tools is permitted. However, AI-generated content, scripts, hypotheses, and conclusions must not replace manual testing, product knowledge, or real-world validation.

Researchers are responsible for the accuracy of every statement, command, endpoint, request, response, screenshot, script, and conclusion included in a report.

4. Testing the Latest Available Software

Before submitting a report, researchers must confirm that the issue reproduces on the latest version available for testing.

The latest available version may be:

• An Official release.
• A Release Candidate.
• An Early Access release.

Researchers should create an account at account.ui.com, enroll in Early Access, and configure their test environment so they can access and evaluate the latest publicly available versions.

Every report must include:

• The exact UniFi OS version and build number.
• The exact application version and build number.
• The firmware version of any relevant devices.
• The release channel tested.
• The date on which the latest available version was checked.
• Confirmation that the issue still reproduces on that version.
• The version on which the issue was originally discovered, if different.

Testing only an older Official release is not sufficient when a newer Release Candidate or Early Access version is available to researchers.

Reports submitted against outdated versions may be returned without full triage unless the researcher confirms that the issue remains present in the latest available release.

5. Account Creation, Roles, and Permissions

When a report claims that an issue can be exploited by a low-privileged, limited, or non-administrative user, the report must clearly establish the account's actual role and permissions.

The report must include step-by-step evidence showing:

1. How the account was created through the product's web interface.
2. Which account type or role was selected.
3. Which permissions were assigned.
4. Whether the account is an administrator, limited administrator, operator, viewer, or non-administrative user.
5. How the account signs in.
6. How the account reaches the affected functionality.
7. Any configuration or permission changes required before exploitation.

Screenshots must show the relevant web interface, role selection, and permission settings.

A report must not describe an account as "low privileged" without evidence supporting that classification. The triage team should not need to infer the account type or reconstruct the permission model from an exploit script.

Passwords, authentication tokens, personal information, private keys, recovery codes, and other sensitive information must be removed or redacted from all evidence.

6. Supported Hardware and Deployment Requirements

Reported vulnerabilities must be validated in a supported product configuration.

When a product or application requires Ubiquiti hardware, the issue must be reproduced on compatible Ubiquiti hardware.

The following do not establish that an issue is exploitable in a supported customer environment unless the same behavior is also reproduced in a supported deployment:

• Unsupported server installations.
• Emulated environments.
• Modified application packages.
• Artificial test harnesses.
• Unofficial installation methods.
• Assumed or theoretical deployment paths.
• Configuration states that cannot be created through normal product use.

For example, UniFi Access is not supported on UniFi OS Server. It is supported on compatible UniFi OS Consoles. Reports involving UniFi Access must therefore demonstrate reproduction on supported Ubiquiti hardware.

Hardware-related reports must include:

• The exact Ubiquiti console model.
• The exact Ubiquiti device models.
• The UniFi OS version and build number.
• The application version and build number.
• The firmware version of relevant devices.
• The relevant network topology.
• The supported installation, setup, or adoption process used.
• Any required peripheral devices.
• Evidence of successful reproduction on the stated hardware.

Acceptable evidence may include:

• Screenshots.
• Screen recordings.
• Logs.
• Packet captures.
• Raw HTTP requests and responses.
• Console output.
• Application output.
• Photographs of the physical test environment when relevant.

Reports involving products that require Ubiquiti hardware will be considered unvalidated until evidence from supported hardware is provided.

7. Proof-of-Concept Requirements

Every proof of concept must be complete, executable, and manually validated by the researcher in the same supported environment described in the report.

A proof of concept must include:

• All prerequisites.
• The complete test environment.
• Required dependencies and their versions.
• Dependency installation commands.
• Exact execution commands.
• Required arguments and example values.
• Authentication requirements.
• Account roles and permissions.
• Relevant product configuration.
• Raw requests and relevant responses.
• Expected output.
• Actual output from a successful test.
• Clear indicators showing that exploitation succeeded.
• Any cleanup, recovery, or reset steps.

Scripts must run as submitted.

Proof-of-concept scripts must not depend on:

• Guessed or nonexistent endpoints.
• Unverified API behavior.
• Undocumented assumptions that were not validated.
• Unexplained placeholder values.
• Fabricated responses or output.
• Unsupported deployment paths.
• Configuration states that cannot be reached through normal product use.
• Permissions that the stated attacker does not possess.
• Manual steps that are omitted from the report.

Before submission, the researcher must manually verify every:

• Command.
• Endpoint.
• Parameter.
• Header.
• File path.
• Dependency.
• Request.
• Response.
• Expected result.

The triage team should be able to reproduce the issue by following the report. The team should not need to:

• Reverse-engineer the proof of concept.
• Correct generated code.
• Determine missing prerequisites.
• Guess required configuration.
• Identify which parts of the report are hypothetical.
• Replace unsupported steps with valid product behavior.

8. Realistic Exploitability and Security Impact

A report must demonstrate more than:

• A theoretical behavior.
• A source-code observation.
• An error message.
• An unusual response.
• A potentially dangerous code path.
• An automated scanner result.
• A behavior observed only in an unsupported configuration.

The report must explain how the behavior can be reached and exploited in a real, supported deployment.

Every report must clearly identify:

• The attacker's starting position.
• Whether authentication is required.
• The exact privileges required.
• Whether administrative access is required.
• Any required user interaction.
• Any required network position.
• Whether the affected interface is reachable locally, remotely, or only from a management network.
• The security boundary being crossed.
• The account, device, data, or functionality affected.
• The practical impact of successful exploitation.
• Any environmental assumptions.
• Any limitations or conditions that reduce exploitability.

The report should demonstrate the complete path from a normal product state to the claimed security impact.

Source-code observations, AI-generated hypotheses, speculative attack paths, or behavior found only in unsupported configurations are not sufficient without evidence that the issue is reachable and exploitable in a supported environment.

9. AI-Assisted Research and Report Preparation

AI tools may be used to assist with:

• Research.
• Scripting.
• Analysis.
• Translation.
• Formatting.
• Report preparation.

All AI-assisted content must be reviewed, tested, and validated by the researcher before submission.

Researchers must not submit:

• AI-generated exploit scripts that have not been executed successfully.
• AI-generated endpoints, parameters, or API behavior that have not been verified.
• AI-generated product configurations that are not supported.
• AI-generated responses presented as actual test output.
• Conclusions based solely on AI analysis.
• Claims of exploitability that have not been reproduced.
• Instructions that cannot be followed in a real product environment.
• Reports that require the triage team to determine which information is real and which information was generated.

The researcher remains fully responsible for the accuracy and reproducibility of the submission, regardless of which tools were used to prepare it.

10. Report Quality and Submission Volume

Researchers should prioritize complete, validated, and security-relevant reports over submission volume.

Researchers should not submit:

• Multiple speculative reports before completing validation.
• Minor variations of the same underlying behavior as separate vulnerabilities.
• Reports that share the same root cause without explaining why they represent separate security issues.
• Reports based only on automated output.
• Reports that have not been manually reviewed.
• Reports for behavior that cannot occur in a supported deployment.
• Multiple reports that could reasonably be consolidated into one complete report.

When multiple observations share the same root cause, they should normally be consolidated into one well-supported report unless they represent separate vulnerabilities with materially different exploit paths or security impacts.

11. Required Submission Checklist

Before submitting a report, the researcher must confirm that it includes all applicable items below.

Software and Hardware

• The latest available Official, Release Candidate, or Early Access version was tested.
• Exact UniFi OS, application, firmware, and build information is included.
• The release channel and testing date are included.
• The issue was reproduced in an officially supported deployment.
• Exact hardware models are identified when hardware is required.
• The relevant network topology and configuration are documented.

Accounts and Permissions

• Account creation is shown through the web interface.
• The attacker's role and permissions are clearly documented.
• The attacker's initial access is clearly explained.
• Any required administrative access is disclosed.
• Any required permission changes are documented.

Reproduction and Evidence

• Complete reproduction steps are provided.
• All prerequisites and dependencies are documented.
• The proof of concept was manually executed and verified.
• Exact execution commands are included.
• Actual requests and responses are included when relevant.
• Logs, screenshots, recordings, or other supporting evidence are included.
• The report contains clear evidence of successful exploitation.
• Evidence from supported Ubiquiti hardware is included when required.

Impact and Validation

• The affected security boundary is identified.
• The practical security impact is demonstrated.
• Environmental assumptions and limitations are disclosed.
• The report is not based solely on automated or AI-generated conclusions.
• All AI-assisted content has been manually reviewed and validated.
• Sensitive information has been removed or redacted.

12. Triage and Enforcement

Reports that do not meet these requirements may be:

• Returned to the researcher with a request for additional information.
• Placed on hold until the missing evidence is provided.
• Deprioritized because the issue cannot be efficiently reproduced.
• Closed as insufficiently validated.
• Closed as affecting an unsupported configuration.
• Treated as a duplicate when the issue has already been addressed in a newer available version.
• Considered ineligible for severity assessment or bounty determination until validation is complete.

Submitting a report does not establish that a vulnerability exists.

A reported issue must be reproducible, security-relevant, and applicable to a supported deployment before it can be fully assessed.

Repeated submission of speculative, unvalidated, incomplete, or non-reproducible reports may result in additional review restrictions or reduced triage priority.

13. Policy Objective

This policy is not intended to discourage security research or the responsible use of AI assistance.

Its purpose is to ensure that reports accurately reflect:

• How people use Ubiquiti products.
• How supported deployments operate.
• How the affected product state is reached.
• How the claimed issue can be reproduced.
• How the vulnerability can be exploited in the real world.
• What practical security impact results from exploitation.

Complete and well-validated reports allow the security team to spend less time reconstructing test environments, correcting unsupported assumptions, and troubleshooting incomplete proof-of-concept scripts.

This results in:

• Faster triage.
• More accurate severity decisions.
• Faster remediation.
• More efficient communication with researchers.
• More consistent bounty decisions.

All researchers are expected to follow this policy when submitting vulnerability reports.