Responsible Disclosure Policy

Last reviewed: Jul 24, 2026

Purpose

We know that the best way to stay secure is to never stop learning, and at VIA, Learning Never Goes Out of Style. We value security researchers who take the time to test our defenses and help us find a better way forward. This policy establishes a foundation of trust. It gives you a clear roadmap for reporting vulnerabilities, and gives us the opportunity to turn your feedback into a stronger system. Together, we ensure that our high bar for security only continues to rise.

Scope

In-scope assets

Our Responsible Disclosure Policy includes all internet-facing services, applications, or APIs owned, operated, or controlled by VIA.

Guidelines for good-faith research

When we refer to good-faith research, we are essentially saying your actions are done with good-natured, honest, and responsible intentions to improve the security of our platform and the safety of our users, which includes following these ground rules:

  • Do not violate laws or regulations.
  • Avoid harm: Do not attempt to access, exfiltrate, modify, or delete data that does not belong to you. If you inadvertently access sensitive data, stop immediately, close out any open document, and report it immediately. Securely delete any data.
  • No disruption: Do not use your research to disrupt our services (e.g., no Denial of Service or brute-force testing).
  • Maintain confidentiality: Keep all details about the vulnerability confidential until we confirm a fix has been deployed. This protects the entire VIA Community while we work on a solution.
  • Social engineering: Do not perform phishing or physical security attacks against VIAneers or our facilities.
  • Minimize your footprint: Only access the minimum amount of data needed to demonstrate the vulnerability. Stop testing once you have confirmed the issue exists.

We will acknowledge your report and ask for more information, if needed.

What we’re looking for

We are most interested in high-impact vulnerabilities that could affect the confidentiality, integrity, or availability of our systems. Examples include:

  • Injection attacks (SQLi, XSS, Command Injection)
  • Broken access control (bypassing permissions to see data you shouldn’t)
  • Authentication flaws (circumventing MFA or account takeovers)
  • Cryptographic failures (weaknesses in how we protect data at rest or in transit)

Report a vulnerability

If you’ve found a potential weakness, we want to hear about it. The more detail you provide, the faster we can act.

What to include:

  • A brief summary of the vulnerability
  • The specific URL or system affected
  • Browser logs with session information
  • Step-by-step instructions to reproduce the issue
  • The potential impact if a “bad actor” were to find it
  • Recommended remediation actions
  • Contact information to ask follow-up questions or to be used in a follow-up report

Changes to this policy

We may update this policy from time to time. Any changes will be posted to this page with a new “Last reviewed” date. Your continued participation in the program after changes are posted means you accept the updated terms. We encourage you to check back periodically.