# How to report a vulnerability

_Security_

Privately, with the exact version, the steps and the impact. Here is what you get back, before you send it.

In force · Reviewed 2026-11-06

On this page: [Report](#report) · [What you get back](#response) · [A good report](#good-report) · [Supported versions](#versions)

## Privately, never in public

_Report_

> Report suspected vulnerabilities through GitHub Private Vulnerability Reporting for this repository. If that route is unavailable, email dev@openlup.com.
>
> — SECURITY.md · reviewed 2026-11-06

**Never in public.** Never open a public issue, pull request, or discussion for a vulnerability report.

## Credit, not a bounty

_What you get back_

- **No bug bounty** — Credit is the whole reward (SECURITY_RESPONSE_POSTURE.md)
- **Targets, not commitments** — Acknowledgement within 3 business days, a status update within 10 (SECURITY_RESPONSE_POSTURE.md)
- **No SLA** — Neither the posture nor SECURITY.md creates a service-level agreement (SECURITY_RESPONSE_POSTURE.md)

> OpenLup does not run a bug bounty and does not pay for vulnerability reports.
>
> — SECURITY_RESPONSE_POSTURE.md · reviewed 2026-11-06

**The right to go quiet.** A report may be closed without a detailed rationale, and a thread may simply end.

## Specific, reproducible, verified

_A good report_

- **Specific** — A weakness in this codebase, with the exact version or commit. A theoretical class of problem without an instance here is not a report.
- **Reproducible** — The steps that trigger it, and the concrete impact.
- **Verified** — A scanner's output pasted without verification is not a report. Verify it yourself first.
- **Disclosed** — If an AI tool helped you find or write it, say so.

## Which code receives fixes

_Supported versions_

**During development preview**

OpenLup-owned core and official-experimental code on the default branch or an exact immutable source preview may receive best-effort fixes, without support or backport commitment.

**Community and private modules**

They remain contributor- and adopter-owned, even when used with an OpenLup preview or stable release.

**After the stable release**

Committed maintenance applies only to core and official-stable modules present in the exact supported release and version window.

**Outside the window**

Official-experimental modules stay best-effort beside a stable release, and stable versions outside the window receive no fixes.