aneo
Aneo B.V.

Responsible Disclosure

We appreciate good-faith security research that helps keep aneo customers safe. This policy explains how to report vulnerabilities to Aneo B.V. and what you can expect from us. It applies to aneo.io and all subdomains and aliases operated by Aneo B.V., including examples such as app.aneo.io, api.aneo.io, docs.aneo.io, status.aneo.io, and future subdomains under *.aneo.io.

Last updated: 24 June 2026

1. How to report

Send vulnerability reports to rd@aneo.io. If that address is unavailable, send the report to hello@aneo.io and include Responsible Disclosure in the subject line.

Please provide enough information for us to reproduce and assess the issue. If your report contains sensitive exploit details, personal data, secrets, or customer-impacting information, request encrypted reporting instructions before sending the full details.

We prefer reports in English. Do not include personal data unless it is required to demonstrate impact. If you encounter personal data, stop testing and include only a general description and minimal metadata needed for triage.

  • Affected asset, URL, endpoint, or product area.
  • Vulnerability type and clear impact.
  • Step-by-step reproduction instructions.
  • Minimal proof-of-concept details, screenshots, or logs.
  • Suggested severity and CVSS vector if known.
  • Research timeline and IP addresses or test accounts used.

2. Our commitment

We aim to acknowledge reports within 5 business days, provide an initial assessment within 10 business days, and keep reporters updated at least every 21 days until resolution.

Validated issues are prioritized based on severity, exploitability, customer impact, and operational risk. We may provide recognition after remediation if you want to be credited and if disclosure is appropriate. We do not offer a paid bug bounty unless separately announced.

3. Encrypted reports

If your report contains sensitive exploit details, personal data, secrets, or customer-impacting information, you may request encrypted reporting instructions from rd@aneo.io before sending the full report.

A public PGP key can be published on this page when available. Until a key is published, do not send secrets, customer data, or exploit material that is not necessary for initial triage.

4. Safe harbor

If you make a good-faith effort to comply with this policy, avoid harm, and report promptly, Aneo B.V. will not pursue legal action for the research activity described in your report.

If a third party brings a claim related to research that followed this policy, we will make it clear that your actions were authorized under this policy where appropriate and lawful.

Safe harbor does not apply to illegal, harmful, extortive, privacy-invasive, destructive, or bad-faith conduct, including exfiltrating data, affecting availability, violating privacy, or creating risk for users.

5. Rules of engagement

Use only accounts you own or test accounts you have explicit permission to use. Keep testing to the minimum required to demonstrate impact.

Do not access, modify, exfiltrate, retain, or disclose data that is not yours. If you encounter personal data or customer data, stop testing and report only the minimum details needed.

  • No denial of service or availability-impacting testing.
  • No social engineering, phishing, spam, or physical security testing.
  • No excessive automated scanning, vulnerability scanners that generate excessive traffic, spam, or brute forcing at scale.
  • No persistence, lateral movement, or destructive actions.
  • No public disclosure before coordinated remediation unless agreed in writing.

6. In scope

We are interested in vulnerabilities that could affect confidentiality, integrity, or availability of aneo websites, applications, APIs, accounts, customer data, or infrastructure.

  • Authentication and session management flaws.
  • Authorization bypass, IDOR, or access control issues.
  • Injection flaws with meaningful impact.
  • Cross-site scripting with meaningful impact.
  • Cross-site request forgery leading to meaningful state change.
  • Server-side request forgery with data access or pivot risk.
  • Misconfigured storage, CORS, or cloud controls exposing data.
  • Leakage of secrets or credentials.
  • Security misconfigurations that could lead to takeover or data exposure.

7. Out of scope

The following are generally out of scope unless you can demonstrate a clear user-impacting risk.

  • Self-XSS or content spoofing without meaningful impact.
  • Clickjacking on non-sensitive pages.
  • CSRF on logout or non-state-changing actions.
  • Missing security headers or low-impact TLS configuration issues.
  • Rate limiting suggestions without demonstrated exploitation.
  • Version disclosure or descriptive errors without exploitability.
  • SPF, DKIM, or DMARC suggestions without abuse impact.
  • Issues in third-party services we do not control.

8. Coordinated disclosure

Please allow us time to remediate before public disclosure. A standard disclosure timeline is 90 days from acknowledgement unless we agree on a different timeline.

We may provide recognition after remediation if you want to be credited and if disclosure is appropriate.

9. Privacy and data handling

Vulnerability reports may contain personal data. We use report information only to investigate, remediate, and improve security. Reports are stored securely and shared internally or with providers only on a need-to-know basis.

See the Privacy Policy and Data Processing Agreement for more information about data handling.

10. Legal

This policy does not grant permission to access or use systems beyond the activity described here. Testing must comply with applicable law, the Terms of Service, and the Acceptable Use Policy.

11. Changes

We may update this Responsible Disclosure policy as our products, infrastructure, legal requirements, and security practices evolve. The Last updated date shows the current version. Continued testing after changes means you accept the updated policy.