Vulnerability disclosure policy

Effective October 1, 2026

This policy explains which systems you may test, how to test them safely, how to report what you find, and what you can expect from us in return.

1. Authorization and safe harbor

If you make a good-faith effort to follow this policy during your research, we consider your research authorized. Specifically:

• We will not pursue or support legal action against you for research that complies with this policy, including claims under anti-hacking laws such as the Computer Fraud and Abuse Act or anti-circumvention laws such as the DMCA.
• We will treat your research as exempt from any terms of service that would otherwise prohibit it, to the extent needed to carry it out under this policy.
• If a third party brings legal action against you over activity that followed this policy, we will make it known that your actions were authorized by us.

This authorization covers only systems in scope and only conduct that follows the guidelines below. If you're unsure whether something is allowed, ask us at security@gravwell.io before you proceed. We can't authorize testing of systems owned by others, including vendors and service providers we use.

2. Scope

In scope

• gravwell.io
• update.gravwell.io
• The Gravwell core product. Assess it against an installation on local infrastructure that you own and control, not against any hosted or third-party instance.

If you find an issue in a system you believe belongs to us but aren't sure, you may still report it. We'll tell you whether it's ours.

Out of scope

• Systems and services operated by third parties, even if they're used by or linked from our sites. Report those to the vendor directly.
• Customer deployments of our product, and any infrastructure owned by, operated by, or linked to our customers. Don't test these. If you find a vulnerability in the product itself, reproduce it on your own installation and report it to us.
• Physical security of our offices, data centers, or staff.
• Any finding that relies on a denial-of-service attack, social engineering, or physical access to a device.

Usually not accepted without a demonstrated impact

These are commonly reported but rarely exploitable on their own. Include a realistic attack scenario if you report one:

• Missing security headers, cookie flags, or best-practice configurations with no shown exploit.
• Clickjacking on pages with no sensitive actions.
• Cross-site request forgery on logout or other actions with no security impact.
• Self-XSS, or issues that only affect the reporter's own account.
• Version disclosure, banner grabbing, or verbose error messages without sensitive data.
• Email configuration (SPF, DKIM, DMARC) findings.
• Results from automated scanners submitted without verification.
• Rate-limiting or brute-force issues on non-authentication endpoints.
• Findings that depend on proxying or intercepting connections, such as placing an attacker-controlled proxy or man-in-the-middle position between a client and our systems. We don't consider this a realistic attack scenario.

3. Guidelines for testing

Under this policy, you agree to:

• Notify us as soon as possible after you discover a real or potential security issue.
• Make every effort to avoid privacy violations, degradation of user experience, disruption to production systems, and destruction or manipulation of data.
• Use exploits only to the extent needed to confirm a vulnerability. Don't use an exploit to compromise or exfiltrate data, establish persistent access, or pivot to other systems.
• Test only against accounts you own or have explicit permission from the account holder to use.
• Stop testing and report immediately if you encounter personal data, financial information, credentials, or proprietary information. Don't save, copy, share, or otherwise use it.
• Delete any data you obtained during research once your report is resolved, and confirm that to us if asked.
• Keep the details of the vulnerability confidential until it's resolved or until we've agreed on a disclosure date (see Public disclosure).
• Give us a reasonable amount of time to fix the issue before discussing it publicly.

4. Methods that are not allowed

• Denial of service, load testing, or any test that degrades availability.
• Phishing, pretexting, or any other social engineering of our staff, contractors, or users.
• Physical testing of our premises or equipment.
• Accessing, modifying, or deleting data belonging to anyone other than yourself.
• Spamming forms, sending mass messages, or creating large numbers of accounts.
• Installing malware, backdoors, or persistent tooling on our systems.
• Attempting extortion, or making any demand in exchange for not disclosing a vulnerability.

5. How to report

Send reports to security@gravwell.io. You may report anonymously. If you do, we can't contact you about the fix or credit you.

Please include:

• Where the vulnerability is: URL, hostname, application, or component.
• A description of the issue and its potential impact.
• Detailed steps to reproduce it, with proof-of-concept code, requests, or screenshots where helpful. Benign payloads are preferred.
• Any data you accessed or changed in the course of testing.

We prefer reports in English. Encrypt sensitive reports with our PGP key (fingerprint 3D6E B802 8BC5 73DE 47A5 9410 8F93 5E93 0667 8D59), also available from keys.openpgp.org.

6. What to expect from us

When you report a vulnerability under this policy, we will:

1. Acknowledge receipt of your report within 5 business days.
2. Within 14 business days, tell you whether we could confirm the issue and how we've assessed its severity. We use the Common Vulnerability Scoring System (CVSS) as a guide.
3. Keep you informed at least every 14 days while we work on a fix, including any delays.
4. Tell you when the issue is fixed, and give you the chance to verify the fix if you'd like.
5. Credit you publicly for the finding if you want us to.

We aim to fix confirmed vulnerabilities as quickly as their severity warrants. Critical and high-severity issues take priority. Some fixes, particularly those involving third-party components, may take longer, and we'll explain why when that happens.

7. Public disclosure

We practice coordinated disclosure. We ask that you not share details of a vulnerability publicly until either it has been fixed or 90 days have passed since your report, whichever comes first. If we need more time, we'll explain why and agree on a new date with you. If a vulnerability is being actively exploited, we may agree to an earlier disclosure.

Where appropriate, we'll publish an advisory describing the issue and its fix, and we may request a CVE identifier. We'll coordinate the timing of any advisory with you.

8. Recognition and rewards

With your permission, we'll list you on our acknowledgments page once the issue is resolved. This is a vulnerability disclosure program, not a bug bounty: we don't currently offer monetary rewards, and submitting a report doesn't create any obligation to pay one.

9. Questions and changes

Questions about this policy can be sent to security@gravwell.io. We also welcome suggestions for improving it.

We may update this policy from time to time. The effective date at the top of this page shows when it last changed. Research carried out under an earlier version remains covered by the terms in effect when it was performed.