VIVIBIT Vulnerability Disclosure Policy

Effective Date: March 10, 2026
Last Updated: March 16, 2026

VIVIBIT takes the security of its products, software, platform services, website, and business operations seriously. We also recognize the importance of privacy, data security, and responsible vulnerability handling.

If you believe you have discovered a potential security vulnerability affecting a VIVIBIT product, platform, website, software component, connected service, or related system, we encourage you to report it to us as soon as possible in accordance with this Vulnerability Disclosure Policy.

We are committed to reviewing reported issues in a timely manner and coordinating appropriate investigation, remediation, and response efforts.

1. Scope

This Policy applies to good-faith reports of potential security vulnerabilities affecting VIVIBIT-owned or officially operated:

  • hardware products;

  • firmware or software;

  • websites and web applications;

  • account systems;

  • connected product features;

  • APIs and developer-related services;

  • cloud-enabled or platform services; and

  • other digital services operated by VIVIBIT.

This Policy does not apply to unrelated third-party products, services, or systems unless the issue is directly caused by VIVIBIT-controlled components.

2. How to Report a Vulnerability

If you believe you have discovered a security vulnerability, please provide us with sufficient detail to help us understand, reproduce, validate, and assess the issue.

Your report should include, where available:

  • a clear description of the vulnerability;

  • the affected product, service, URL, API, software version, or component;

  • the conditions required to reproduce the issue;

  • step-by-step reproduction instructions;

  • proof of concept, screenshots, logs, or other supporting materials, if available;

  • the potential impact of the issue;

  • your contact information for follow-up.

Please do not publicly disclose the vulnerability before VIVIBIT has had a reasonable opportunity to validate and address the issue.

3. Our Handling Process

After receiving a vulnerability report, we generally follow a process similar to the following:

Step 1: Report Intake

We acknowledge receipt of the report and perform an initial review.

Step 2: Validation and Assessment

We evaluate whether the reported issue is reproducible, security-relevant, and within the scope of this Policy.

Step 3: Risk Analysis

We assess the severity, affected systems, exploitability, and potential business, security, or user impact.

Step 4: Remediation Planning

We determine whether the issue requires an immediate fix, a mitigation plan, a coordinated release, or another response.

Step 5: Fix and Verification

Where appropriate, we develop and validate a remediation, patch, configuration update, or other corrective action.

Step 6: Communication and Closure

We communicate the outcome to the reporter where reasonably possible and monitor the issue after deployment if needed.

4. Response Targets

VIVIBIT aims to review and handle vulnerability reports in a timely manner. Target response times may vary depending on complexity, reproducibility, product architecture, deployment conditions, hardware dependencies, supply chain factors, and severity.

As a general guideline:

  • Initial acknowledgment: typically within 3 business days

  • Initial assessment: typically within 7 business days

  • Remediation timeline: depends on severity, technical complexity, and operational constraints

For critical issues, VIVIBIT will prioritize investigation and remediation as appropriate.
For high-impact vulnerabilities, we may issue a security advisory, mitigation guidance, or emergency communication where necessary.

These timelines are targets rather than guarantees.

5. Vulnerability Severity Classification

VIVIBIT may evaluate reported vulnerabilities using generally accepted industry references such as CVSS v3.1, internal risk assessment criteria, exploitability, affected scope, and potential impact.

For general guidance, reported issues may be classified into the following categories:

Critical

Examples may include:

  • remote code execution without meaningful user interaction;

  • unauthorized access to administrative or execution-level privileges;

  • vulnerabilities that enable large-scale compromise of systems or sensitive data;

  • severe authentication bypass affecting core systems;

  • remote compromise of connected devices, platform services, or security-sensitive functions.

High

Examples may include:

  • unauthorized access to privileged functions or sensitive operational capabilities;

  • significant information disclosure affecting sensitive user or business data;

  • vulnerabilities enabling high-risk actions across accounts, systems, or services;

  • impactful SSRF, command execution, or service compromise scenarios under realistic attack conditions;

  • serious denial-of-service vulnerabilities affecting availability at scale.

Medium

Examples may include:

  • vulnerabilities requiring user interaction but capable of affecting security or privacy;

  • weaknesses in authentication, authorization, or rate limiting;

  • ordinary sensitive information disclosure;

  • non-persistent service disruption with meaningful impact;

  • security flaws that affect specific features, workflows, or deployment conditions.

Low

Examples may include:

  • low-impact information disclosure;

  • open redirects;

  • limited-scope reflected XSS under constrained conditions;

  • minor logic flaws with limited real-world impact;

  • local or low-impact service disruption.

6. Issues That Are Generally Not Considered In-Scope or Actionable

The following types of reports may be considered out of scope, non-security-related, or not actionable under this Policy:

  • issues unrelated to security, such as formatting issues, cosmetic bugs, or general performance complaints;

  • reports lacking sufficient detail to reproduce or assess the issue after reasonable follow-up;

  • issues that cannot be exploited in practice or have no meaningful security impact;

  • self-XSS, clickjacking without meaningful impact, or similar low-value findings;

  • reports involving only non-sensitive information exposure;

  • vulnerabilities affecting unsupported, deprecated, or end-of-life products or services;

  • issues already known internally or previously fixed;

  • issues already publicly disclosed before being reported to us;

  • vulnerabilities affecting only third-party products, modules, libraries, or hardware outside VIVIBIT’s control, unless directly caused by a VIVIBIT integration or implementation;

  • denial-of-service findings requiring unrealistic assumptions or lacking practical impact.

VIVIBIT reserves the right to determine whether a submitted report falls within the scope of this Policy.

7. Expectations for Responsible Disclosure

We ask security researchers and reporters to act in good faith and follow responsible disclosure practices.

When reporting a vulnerability, please:

  • avoid actions that would harm users, customers, VIVIBIT systems, or data;

  • avoid accessing, modifying, deleting, or downloading data beyond what is necessary to demonstrate the issue;

  • avoid disruption of production services;

  • avoid social engineering, phishing, physical attacks, spam, or denial-of-service testing;

  • avoid publicly disclosing the vulnerability before reasonable remediation efforts have been completed;

  • comply with applicable law.

We encourage coordinated disclosure and constructive engagement.

8. Use of Submitted Information

By submitting a vulnerability report to VIVIBIT, you grant VIVIBIT the right to use the information you provide for the purposes of:

  • validating the reported issue;

  • assessing impact;

  • developing mitigations or fixes;

  • improving product, platform, and service security;

  • documenting, auditing, and maintaining our security response processes;

  • complying with legal or regulatory obligations.

Any recognition, attribution, reward, or follow-up engagement is at VIVIBIT’s discretion unless otherwise stated in a separate program or written agreement.

9. No Waiver of Rights

This Policy does not create any obligation for VIVIBIT to provide compensation, public acknowledgment, or any specific remediation timeline. It does not waive any legal rights, defenses, or remedies available to VIVIBIT.

VIVIBIT reserves the right to modify this Policy at any time.

10. Contact

If you wish to report a vulnerability or have questions about this Policy, please contact VIVIBIT using the official security or support contact details provided on the official VIVIBIT website.