Choose language

Responsible Disclosure

This page is for security researchers who want to report vulnerabilities to the NORVATO Security team. If you are a customer and need help with security questions, passwords, or account access, please use the official support channels for your product.

This policy explains what we consider good faith security research and what you can expect from us when you report a vulnerability.

I want to file a report Reporting guidelines
favicon-1

What you can expect from us

If you follow this policy, we will:

  • Provide safe harbour for research activities performed in line with this policy.

  • Acknowledge your report and provide an initial response within 48 business hours.

  • Work with you to understand and validate the issue.

  • Remediate confirmed vulnerabilities in a timely manner, based on severity and risk.

Safe harbour

Security research conducted under this policy is considered authorised and lawful and is viewed as a helpful contribution to improving security.

You must still comply with all applicable laws and regulations.

If you are unsure whether your research is consistent with this policy, stop and contact us first via the reporting channel below before continuing.

Ground rules

To avoid harm and reduce the risk of confusion with malicious activity, please:

  • Stay in scope. Test only systems covered by this policy and respect anything listed as out of scope.

  • Use only your own accounts and data unless you have explicit permission from the owner.

  • Avoid disruption. Do not degrade service availability or performance, and do not damage or destroy data.

  • Minimise data access. If you gain unintended access to data, access only what is strictly necessary to prove impact.

  • Stop if you encounter user data. If you come across personal data, sensitive personal data, payment data, or proprietary information, cease testing and report immediately.

  • No Denial of Service (DoS/DDoS) testing.

  • No social engineering (phishing, vishing, smishing, impersonation, physical attempts, etc.).

  • Report promptly after discovery.

  • No extortion. Do not request compensation as a condition of disclosure.

  • Use official channels only to share details with us.

If there is any conflict between this policy and other terms that might apply, this policy takes precedence for vulnerability research covered here.

Confidentiality and public disclosure

Do not publicly disclose, discuss, or publish details of a vulnerability until:

  1. It has been fixed (or otherwise mitigated), and

  2. You have received explicit written permission from NORVATO.

How to report

Send reports to: responsible.disclosure@norvato.com

Reports are triaged by a Security Analyst and escalated to the appropriate engineering or security team. Include as much detail as possible so we can reproduce and validate quickly.

Recommended content:

  • A clear description of the issue and affected product/service/URL

  • Impact and realistic attack scenario

  • Steps to reproduce (or a working proof of concept)

  • Any relevant logs, screenshots, or request/response samples (sanitise sensitive data)

Rewards

NORVATO does not offer monetary rewards for responsible disclosure reports at this time.

We recognise valid reports in our Security Hall of Fame when they:

  • describe a previously unknown vulnerability, and

  • result in a code or configuration change.

Scope

This policy applies to all Norvato Group services, products, and web properties.

Before you report

What we generally do not accept

Most inbound reports are duplicates, low impact, or already known. To avoid a disappointing experience, please confirm that your report has a realistic exploit scenario and clear security impact.

In particular, please do not submit:

  • Theoretical issues without evidence of exploitability in our environment

  • Automated scanner findings without a reproducible proof of concept

  • Issues that require man-in-the-middle (MITM), physical access to a user’s device/browser, access to a user’s email account, or reliance on rooted/jailbroken devices

  • Missing/weak HTTP security headers (as a standalone finding)

  • Non-sensitive information disclosure (e.g., server/version banners)

  • Content spoofing/text injection without a practical attack vector (e.g., cannot influence rendered HTML/CSS in a meaningful way)

  • CSRF on unauthenticated forms or forms without sensitive actions

  • Self-XSS

  • Email best-practice gaps (SPF/DKIM/DMARC misconfigurations) as a standalone finding

  • Host header injection unless you can demonstrate a practical exploit

  • Expired certificates, weak ciphers, or deprecated TLS/SSL versions (as a standalone finding)

  • Known vulnerable software/library versions without a working proof of exploitability

  • Rate limiting / brute force issues on non-authentication endpoints

  • Denial of Service (DoS/DDoS)

  • CSV/formula injection

  • Flash-based exploits

  • Clickjacking

  • Public Google Maps API key disclosure (as a standalone finding)

Duplicates

If we receive multiple reports for the same underlying issue, we will accept the first report received. A report is considered a duplicate if we were already aware of the vulnerability, regardless of how we became aware of it (including internal discovery).