Vulnerability disclosure policy

Effective October 29, 2026

This policy specifies which systems you may test, how to test them safely, how to report what you find, and what we will do in response.

On this page

1. Authorization
2. Scope
3. Guidelines for testing
4. Methods that are not allowed
5. How to report
6. What to expect from us
7. Public disclosure
8. Supported releases
9. Advisories
10. Recognition and rewards
11. Questions and changes

1. Authorization

If you make a good-faith effort to follow this policy, we consider your research authorized. This covers only systems in scope, and only testing that follows the guidelines below. If you are not sure whether something is allowed, ask us at security@gravwell.io first. We cannot authorize testing of systems that others own, including our vendors and service providers.

2. Scope

In Scope

• The Gravwell core product
  • Test it on an installation you own and control, not on any hosted or third-party instance.
• gravwell.io
• kits.gravwell.io
• update.gravwell.io
• security.gravwell.io

If you find an issue in a system you think is ours but are not sure, report it anyway. We will tell you whether it is ours.

Out of Scope

• Systems and services that third parties run, even if we use them or link to them. Report those to the vendor.
• Customer deployments of our product, and any infrastructure our customers own, run or link to. If you find a flaw in the product, reproduce it on your own installation and report it to us.
• Physical security of our offices, data centers and staff.
• Any finding that relies on denial of service, social engineering or physical access to a device.

Usually not accepted unless you show an impact

People often report these, but they are rarely exploitable on their own. If you report one, describe a realistic attack:

• Missing security headers, cookie flags or best-practice settings, with no exploit shown.
• 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 affect only your own account.
• Version disclosure, banner grabbing or verbose error messages that reveal nothing sensitive.
• Email configuration findings (SPF, DKIM, DMARC).
• Unverified results from automated scanners.
• Rate-limiting or brute-force issues on endpoints other than authentication.

3. Guidelines for testing

Under this policy, you agree to:

• Tell us as soon as you can after you find a real or potential security issue.
• Do all you can to avoid privacy violations, harm to users, disruption to production systems, and destroying or changing data.
• Use an exploit only as far as you need to confirm a vulnerability. Do not use it to take data, keep access or move to other systems.
• Test only with accounts you own, or with the account holder’s explicit permission.
• Stop testing and report at once if you find personal data, financial information, credentials or proprietary information. Do not save, copy, share or use it.
• Delete any data you got during your research once your report is resolved, and confirm that to us if we ask.
• Keep the details confidential until the issue is resolved or we have agreed a disclosure date (see Public disclosure).
• Give us reasonable time to fix the issue before you discuss 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, changing or deleting anyone else’s data.
• Spamming forms, sending mass messages or creating large numbers of accounts.
• Installing malware, backdoors or persistent tools on our systems.
• Extortion, or any demand in exchange for not disclosing a vulnerability.

5. How to report

Email security@gravwell.io. You may report anonymously, but then we cannot contact you about the fix or credit you. Include:

• Where the vulnerability is: URL, hostname, application or component.
• What the issue is and what it could let an attacker do.
• Detailed steps to reproduce it, with proof-of-concept code, requests or screenshots where they help. Use harmless payloads.
• Any data you accessed or changed while testing.

We prefer reports in English. Encrypt sensitive reports with our PGP key, also on keys.openpgp.org. Fingerprint:

6. What to expect from us

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

1. Acknowledge your report within 10 business days.
2. Within 14 business days, tell you whether we could confirm the issue and how severe we rate it. We use the Common Vulnerability Scoring System (CVSS) as a guide.
3. Update you at least every 14 days while we work on a fix, including any delays.
4. Tell you when the issue is fixed, and let you check the fix if you want to.
5. Credit you publicly, if you want us to.

We aim to fix confirmed vulnerabilities as fast as their severity calls for, critical and high-severity issues first. Some fixes take longer, especially in third-party components. When that happens, we will tell you why.

7. Public disclosure

We practice coordinated disclosure. Please do not share details of a vulnerability publicly until we publish them or 90 days have passed since your report, whichever comes first. For vulnerabilities in Gravwell’s own code, we publish details 7 days after the fix ships (see Advisories), so customers have time to upgrade. If we need more time, we will explain why and agree a new date with you. If attackers are already exploiting a vulnerability, we may agree to disclose sooner.

Where it makes sense, we publish an advisory on this site that describes the issue and its fix, and we may request a CVE ID. We will agree the timing of any advisory with you.

8. Supported releases

Gravwell ships on a rolling release. Only the latest Gravwell release gets security fixes, and we do not backport them. To fix a vulnerability, upgrade to the release its advisory names. Unless an advisory says when an issue was introduced, every release before the fixed one is affected.

We upgrade Gravwell Cloud as one fleet. Each advisory says what we did for Gravwell Cloud and, separately, what Self-Hosted customers need to do.

9. Advisories

Each advisory has an ID of the form GVD-YYYY-NNNN and covers one or more vulnerabilities. There are two kinds:

• First Party: vulnerabilities in Gravwell’s own code.
• Third Party: vulnerabilities in upstream components that Gravwell ships or depends on. We publish one when an upstream issue affects Gravwell, or when customers are likely to ask whether it does. We do not publish an advisory for every upstream CVE.

We score every vulnerability ourselves, as it affects Gravwell, with CVSS 4.0 and CVSS 3.1. Our scores can differ from upstream ones, so third-party advisories link to the upstream records.

We may publish an advisory early, for example while we are still investigating, and update it as we learn more. Each update adds a dated entry to its changelog. A published advisory never gains vulnerabilities: an issue found later gets a new advisory. We also publish each advisory as a signed CSAF 2.0 document for vulnerability management tools.

For security vulnerabilities in Gravwell’s own code, we wait 7 days after the fix ships before we publish details. On the day of the fix, the advisory names the fixed release, says what to do and gives the severity and CVSS scores. It leaves out the affected component, how the flaw works and the CVE ID. This wait gives Self-Hosted customers additional time to upgrade. After 7 days, we add the details to the advisory and a dated entry to its changelog. We add CVE IDs as soon as they are assigned, which can be later.

10. Recognition and rewards

With your permission, we will list you on our acknowledgments page once the issue is resolved. This is a vulnerability disclosure program, not a bug bounty: we do not currently pay rewards, and a report does not oblige us to pay one.

11. Questions and changes

Send questions about this policy to security@gravwell.io. We welcome suggestions too.

We may update this policy. The effective date at the top shows when it last changed. Research done under an earlier version stays covered by the terms in force when you did it.

This policy follows the structure of ISO/IEC 29147 and the CISA vulnerability disclosure policy template. Machine-readable contact details: /.well-known/security.txt