Policy · security

Reporting a vulnerability

Email [email protected]. If you would rather report through GitHub, use private vulnerability reporting on the public releases repository. Either path reaches the maintainer privately; use whichever you prefer.

Do not open a public issue for a suspected vulnerability. The source repository is private, so its advisory form is not a route a customer can use — the two paths above are.

Include the affected version or commit, reproduction steps, impact, and any suggested mitigation. Remove API keys, tokens, session data, account details, raw provider responses and other secrets from the report before you send it.

• Local credential handling.
• Provider process invocation and cleanup.
• Terminal and protocol parsing.
• Cursor network requests.
• Capture-helper installation into another product’s settings.
• Projection and recovery behaviour.
• Nested helper integrity.
• Preference and snapshot boundaries.
• Diagnostics.
• Installation and packaging behaviour.

Security fixes are applied to the latest release and to the development branch.

Customer questions — the support email

[email protected] reaches a person and is the channel that works today. A web form will replace this at launch.

Diagnostics — the in-app support bundle

The in-app diagnostic flow produces a previewable redacted support bundle. You see exactly what it contains before anything is sent, and it carries no credentials, no raw provider responses and no transcripts.

Suspected vulnerabilities — the security address

[email protected], or private vulnerability reporting on the public releases repository. Privately, always.

Active incidents — the status page

The status page carries active incidents affecting checkout, activation, recovery and the update feed.

Public reproducible bugs — GitHub issues

The public issue tracker is reserved for public reproducible bugs that contain no account data.