Vulnerability Disclosure Policy

1. Reporting channel

Send a report to [email protected] with the subject “Vulnerability report”. This mailbox is active, tested, monitored, and assigned to an internal owner with an escalation path. Encrypted reporting is available only when kubbeevault publishes a current PGP key or secure-form link and its fingerprint.

• Describe the affected product, URL, version, endpoint, extension, repository, or component.
• Explain the vulnerability, security impact, preconditions, and reproducible steps.
• Include minimal proof such as redacted request/response details, screenshots, or code needed to reproduce safely.
• State whether any data was accessed, changed, retained, or disclosed and delete it securely when requested.
• Provide a safe contact method and any requested disclosure timeline. Do not include live passwords, tokens, private keys, or unrelated personal data.

2. In-scope systems

In-scope systems are kubbeevault-owned production web applications and APIs under kubbeevault.com, the official kubbeevault browser extension, and official kubbeevault Kubernetes or automation components that are currently supported and expressly identified by kubbeevault. Researchers who are uncertain whether a system is in scope must request written confirmation before testing.

A vulnerability in a third-party dependency is in scope only when the report demonstrates a specific impact on an in-scope kubbeevault system. Customer-managed deployments are in scope only with that Customer’s separate written authorisation.

3. Out-of-scope activity

• Denial of service, load testing, resource exhaustion, traffic flooding, or activity that degrades availability.
• Social engineering, phishing, physical access, harassment, bribery, or attempts to deceive kubbeevault personnel, customers, or providers.
• Accessing, modifying, deleting, downloading, or retaining another person’s data beyond the minimum accidental access needed to demonstrate the issue.
• Testing third-party services, Customer environments, or accounts without the system owner’s separate permission.
• Automated scanning that creates material traffic, repeated alerts, or destructive changes; password spraying; credential stuffing; brute force; or testing with stolen credentials.
• Public disclosure, sale, extortion, or threat to disclose before kubbeevault has had a reasonable opportunity to investigate and remediate.
• Reports limited to missing best-practice headers, version banners, self-XSS, clickjacking with no sensitive action, theoretical issues, spam, or scanner output without a demonstrated security impact.

4. Research rules

• Use accounts and data you own or have explicit written permission to use.
• Stop immediately if you encounter Customer Data, credentials, secrets, personal data, or evidence of active compromise; report what happened without exploring further.
• Use the least intrusive technique and the minimum data needed to confirm the issue. Do not establish persistence or pivot to another system.
• Do not evade security controls except to the minimum extent necessary to demonstrate the specific vulnerability.
• Keep findings confidential, protect all collected information, and coordinate any disclosure with kubbeevault.
• Comply with applicable law and this policy. If uncertain whether a test is permitted, ask for written authorisation before proceeding.

5. Good-faith safe harbour

When research is conducted in good faith, on in-scope systems, and in material compliance with this policy, kubbeevault will treat it as authorised for the purpose of the tested security controls and will not initiate legal action or recommend prosecution solely for that research. kubbeevault will work with the researcher to understand and resolve accidental policy deviations made in good faith.

This statement cannot bind third parties or law-enforcement authorities, does not authorise violation of law or third-party rights, and does not waive rights concerning malicious, reckless, extortionate, privacy-invasive, destructive, or out-of-scope activity. If a third party initiates action and the researcher complied with this policy, kubbeevault may clarify that the activity was conducted under this programme where appropriate.

6. What reporters can expect

kubbeevault aims to acknowledge a complete report within three business days, provide an initial triage update within ten business days, and share material status updates at least every 30 days while remediation is active. These operationally confirmed targets are not service-level guarantees, and complex or third-party issues may take longer.

kubbeevault will validate impact, prioritise remediation by risk, and coordinate a reasonable disclosure date. A researcher may request public credit, a pseudonym, or anonymity. kubbeevault will not publish the reporter’s identity without permission except when legally required.