Email hello@vale.sh with what you found and how to reproduce it. We'll acknowledge it, fix what's real, and credit you if you'd like — we're not going to argue with a good-faith report.

Please don't open a public issue for a vulnerability. Everything in this tracker is public and indexed the moment it's posted.

Useful to include, if you have it:

• What an attacker gets out of it, concretely.
• Steps to reproduce, ideally against a throwaway account.
• The affected URL or endpoint.
• Anything you'd want credited — name, handle, or nothing at all.

This tracker covers Vale CMS at cms.vale.sh, including its API and its MCP server.

Adjacent things go elsewhere:

• The Vale engine and CLI — report at vale-cli/vale. It's open source; you can read the code.
• Vale Studio v1 (studio.vale.sh) — email the same address, and say which host you were testing.

Test against your own account and your own data. Don't run automated scanners against the production host, don't attempt denial of service, and don't access or modify another user's content — if a flaw would let you, stop and tell us rather than proving it.

The short version, which may save you a report on something that's already the design:

• Git tokens (GitHub, GitLab) and any AI provider key live in browser storage, not on our servers. Git tokens are forwarded per request, used, and discarded.
• The engine (valed) is stateless — it processes a request and keeps nothing. Your documents aren't stored after a request completes.
• The app ships a strict Content-Security-Policy that limits what an injected script could reach even if one ran.

Browser storage is not invisible to someone with hands-on access to your device, or to a browser extension you've granted broad permissions to. We know; that's a stated limitation, not an oversight.

If you find something that contradicts any of the above, that's exactly the kind of report we want.