> ## Documentation Index
> Fetch the complete documentation index at: https://trigger.dev/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Security & vulnerability reporting

> How to report security issues in Trigger.dev, our response targets, and how self-hosters receive security notices.

We take the security of Trigger.dev seriously, for both Cloud and self-hosted deployments. This page covers how to report a vulnerability, what to expect, and how to stay informed about security releases.

> [!NOTE]
>
> Unlike Trigger.dev Cloud, the self-hosted setup is optimized for single-tenant use, with code and
> users you trust. It is not designed to run untrusted code or untrusted payloads.

> [!WARNING]
>
> Do not report security vulnerabilities through public GitHub issues, pull requests, or Discord. Use one of the private channels below.

## What is in scope

A self-hosted deployment is a single trust domain: as above, it is built for code and users you trust. Role separation inside an organization is therefore not a security boundary there. Role-based access control comes from a plugin that is not part of the open-source distribution, and without it the permission layer falls back to a permissive ability for session users and personal access tokens. That is deliberate.

**Out of scope for self-hosted:** a member of an organization performing a privileged action inside that same organization, such as renaming or deleting the organization or managing other members. Control who you invite, or use Cloud, if you need that separation.

**In scope from any deployment:** reaching data or actions belonging to an organization the caller is not a member of, or bypassing authentication. Organization is a hard boundary on Trigger.dev Cloud, and Cloud runs this same code, so report these even though your own install is single-tenant.

Tell us which deployment you tested against. The same report can be out of scope for self-hosting and in scope for Cloud.

The [security policy](https://github.com/triggerdotdev/trigger.dev/blob/main/SECURITY.md) is canonical.

## Reporting a vulnerability

**1. Choose a private channel**

* **GitHub (preferred):** open a private report from the repository's **Security** tab using **"Report a vulnerability"** ([direct link](https://github.com/triggerdotdev/trigger.dev/security/advisories/new)).
* **Email:** `security@trigger.dev`

**2. Include the details**

A description and impact, steps to reproduce (a proof of concept helps), affected versions/components, and any suggested fix.

**3. We track it privately**

Every report is tracked in a private GitHub Security Advisory. If you email us, we open the advisory on your behalf.

## What to expect

| Stage | Target |
| - | - |
| Acknowledgement | within 3 business days |
| Validation + CVSS 3.1 severity assessment | within 1 week |

We score issues with CVSS 3.1 and prioritise remediation by severity:

| Severity (CVSS 3.1) | Target time to resolve |
| - | - |
| Critical (9.0–10.0) | 7 days |
| High (7.0–8.9) | 30 days |
| Medium (4.0–6.9) | 90 days |
| Low (0.1–3.9) | As needed |

> [!NOTE]
>
> These are best-effort targets measured from when we validate and accept a report, not guarantees. We follow coordinated disclosure with a default 90-day window, and publish a GitHub Security Advisory (requesting a CVE where applicable) once a fix ships.

## Supported versions

We patch the **latest released version line** only. Run the latest version-tagged release to receive security fixes — see [Self-hosting overview](https://trigger.dev/docs/self-hosting/overview.md).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.