Security disclosure - SiteCMD Docs

If you’ve found a security issue in SiteCMD, this page tells you how to tell us and what happens after you do. It matches the machine-readable policy at sitecmd.com/.well-known/security.txt.

We take security seriously because SiteCMD is, by design, the app on your machine that knows where all your bodies are buried. A scan of your site is a catalog of what’s wrong with it. We’re acutely aware of what that means.

Scope

We want to hear about:

Vulnerabilities in the SiteCMD desktop app (Tauri shell, Rust backend, React frontend).
Vulnerabilities in the SiteCMD MCP server (sitecmd-mcp).
Vulnerabilities in the SiteCMD release infrastructure (signing, update endpoint, distribution).
Vulnerabilities in the SiteCMD marketing site (sitecmd.com) that have real impact (XSS that leaks license keys, etc., not theoretical clickjacking on a static page).

We don’t consider these scope (please don’t report):

Findings the SiteCMD scan itself would surface (CSP report-only mode, missing security headers on the marketing site, etc.). These aren’t bugs; they’re product output.
“Your app makes network requests” reports. We document every network request we make in Privacy & data; if you find one we haven’t documented, that’s a real report.
Brute-force or denial-of-service against our public endpoints. We rate-limit and we don’t want to hear about it.
Social engineering attempts against our team or customers.
Anything that requires already having root on the target machine.

How to report

Email support@sitecmd.com (the address in our security.txt) with “security” in the subject line and:

A description of the issue
Steps to reproduce
The impact you believe it has
Your name and how you’d like to be credited (or “anonymous”)

If the report is highly sensitive, say so in your first email (the subject line is enough) and we’ll arrange a secure channel before you share the details.

We don’t currently run a paid bug bounty. We do credit reporters publicly in release notes when a fix ships (if you want credit; we’ll also respect “anonymous”).

What happens next

SiteCMD is built by a very small team, so we won’t dress this up as an enterprise security program. What you can expect:

A human reply confirming we received the report. We read every one.
A triage answer. “Yes, this is a real issue and we’re on it” or “We don’t consider this a vulnerability, here’s why.”
Confirmed vulnerabilities get prioritized ahead of feature work, with urgency matched to severity, and we’ll keep you posted while we work on the fix.
Public credit when the fix ships, if you want it, with a note describing what was vulnerable and what users need to do.

We do not threaten legal action for good-faith research. If you’re poking at SiteCMD to find security issues and you don’t disrupt other users or violate the law, we’re grateful, not adversarial.

Disclosure timeline

We ask that you delay public disclosure until we’ve shipped a fix, or until 90 days have passed (whichever comes first). If we go past 90 days without action, you’re free to disclose. We won’t be upset; that convention exists precisely so reporters don’t get stuck waiting on a vendor.

What to do while waiting

While we’re working on a fix:

Don’t share the vulnerability details publicly.
Don’t exploit the vulnerability against users other than yourself.
Feel free to discuss the existence of an unresolved issue in general terms (“I’m working with the SiteCMD team on a security issue”) but not the specifics.

If you need to disclose to a specific party (e.g., your security team, your employer), that’s fine; ask us to coordinate if it’s anything beyond your immediate team.

CVE assignment

If a confirmed vulnerability has real-world impact and you’d like a CVE, we’ll coordinate the request with you. Not every issue warrants one; we’ll say which way we’re leaning in the triage response.

Past advisories

There are no published advisories yet. When there are, they’ll be listed on sitecmd.com and linked from this page.

Why we have this page

SiteCMD is installed on customers’ machines, reads local project folders, and connects to third-party services. A clear reporting path belongs in the product from the start, not after the first vulnerability is found.