Reporting a Vulnerability

Last updated: 6 October 2026.

If you think you have found a security vulnerability in livediagram, thank you. Please tell us privately so we can fix it before anyone else finds it. This page explains how to report it, what is in scope, and how to test without putting anyone else's data at risk.

How to report

Report it privately through GitHub:

Report a vulnerability on GitHub

This opens a private security advisory that only you and the livediagram maintainers can see. You will need a GitHub account. We keep the conversation, the fix and the eventual disclosure in that advisory.

Please do not report a vulnerability in a public GitHub issue, discussion or pull request, on social media, or in the Community. There is no separate security mailbox: a report sent to hello@livediagram.app is not ignored, but we will ask you to move it to a private advisory.

This page is also what livediagram.app/security, our /.well-known/security.txt file and the repository's SECURITY.md point to.

A good report includes:

• what is affected (a URL, an API endpoint, or a file and line in the source);
• the steps to reproduce it;
• what an attacker could do with it;
• any proof-of-concept code or screenshots.

What is in scope

• The hosted service at livediagram.app and the livediagram subdomains we run, including mcp.livediagram.app.
• The source code. A flaw in the code affects every self-hosted copy too, so it is in scope even if you found it on your own copy.

What is out of scope

• Third-party services we rely on, such as Clerk (sign-in), Cloudflare (hosting), Resend (email) and GitHub. Please report those to the vendor.
• A self-hosted copy that someone else runs. Its operator is responsible for it. A flaw in livediagram's own code is still in scope.
• Reports from automated scanners with no demonstrated impact.
• Missing security headers or best-practice settings with no working exploit.
• Rate limits that only slow an attacker down.
• Self-XSS, and clickjacking on pages with no state-changing action.
• Anything that relies on a share link you were given. A share link is a key by design: anyone who holds it can open the document (see Share Link Security).
• Social engineering of anyone.

Rules for testing

When you look for vulnerabilities, please:

• use only accounts and documents you own, or that you have explicit permission to test;
• stop as soon as you reach someone else's data, keep only what proves the issue, and do not keep, share or change it;
• not run denial-of-service, load or volume tests, or anything that degrades the service for other people;
• not send spam or phishing, or try to trick our users or anyone else;
• give us a reasonable time to fix the issue before you disclose it publicly, and agree the disclosure with us.

Safe harbour

If you follow these rules in good faith, we consider your research authorised. We will not take legal action against you or report you to law enforcement for it. If someone else takes action against you over research that followed these rules, we will make it known that it was authorised. If you are unsure whether something is allowed, ask us in the advisory before you try it.

What to expect from us

livediagram is free and has no paid tier, so we cannot promise response times and we do not offer a bug bounty. We do promise to:

• read every report and handle it in good faith;
• keep your report confidential while we work on it;
• keep you updated in the advisory;
• ship a fix before any details are published;
• credit you in the published advisory, unless you would rather we didn't.