Responsible disclosure
Gate runs with access to your credentials. If it can be made to misbehave, we want to know before anyone else does.
Reporting
- Name
Preferred- Type
- GitHub private advisory
- Description
Report a vulnerability. Private, threaded, and tied to the fix.
- Name
Email- Type
- [email protected]
- Description
If you cannot use GitHub. Please say "Gate security report" in the subject.
- Name
Response time- Type
- within 3 working days
- Description
An acknowledgement, not necessarily a fix. If you have not heard back in five days, please chase. It means the message went astray.
Please do not open a public issue for a security bug. Gate's output is designed to be safe in public logs; a report about how to break that is not.
What to include
- What you did, and what happened
- The Gate version (
gate --version) and Node version - A synthetic reproduction: a config file that triggers the behaviour, with every credential replaced by a fake one
- The impact as you see it
A short synthetic .mcp.json is almost always the fastest path to a fix.
Our promises
We will never ask you for a real credential. Not to reproduce a bug, not to confirm a fix, not for any reason. If someone claiming to be from Gate asks you for one, that is not us.
We will never ask you for unredacted Gate output. If Gate leaked something, sending us the leak makes the problem worse. Describe the shape.
We will credit you in the advisory and the changelog, unless you would rather we did not.
We will tell you what we are doing. An acknowledgement within three working days, an assessment within a week, and a fix timeline you can plan around. If we decide something is not a vulnerability, we will say why rather than going quiet.
We will publish. Every fixed security issue gets an advisory, including the ones that are embarrassing.
Scope
In scope
- Gate printing, storing or transmitting a credential it should have redacted
- Telemetry carrying data outside the documented allowlist
- Code execution triggered by scanning a repository, without
--allow-stdio-launch - Reading or writing files outside the repository root
- Terminal escape or control-character injection through scanned content
- Denial of service from a small, plausible input
- A rule that can be silently bypassed by hostile configuration
- Anything in the threat model that we claim is mitigated and is not
Out of scope
--allow-stdio-launchexecuting a command. That is the documented behaviour of a flag that prints a warning and asks for confirmation.- Gate finding fewer issues than another tool. That is a bug, not a vulnerability. Please open a normal issue.
- Missing hardening in the docs site that has no security impact.
- Vulnerabilities in dependencies with no exploitable path through Gate. Report them upstream; tell us and we will bump.
- Social engineering, physical access, or anything requiring a compromised machine.
Safe harbour
We will not pursue or support legal action against anyone who reports a vulnerability in good faith, follows this policy, and does not access, modify or destroy data belonging to anyone else.
Test against your own repositories and synthetic fixtures. Gate ships fixtures designed for exactly this.