Skip to content
The Gateway

Security disclosure

We take security reports seriously. This page tells you how to send one, what’s in scope, and what response to expect.

How to report

Section titled “How to report”

Email security@thegateway.pro with:

  • A clear description of the issue.
  • Steps to reproduce, ideally with a minimal test case.
  • The affected version (gatewayd --version if you can run the binary).
  • Your assessment of impact (information disclosure, RCE, kill-switch bypass, etc.).
  • Whether you’ve shared the issue with anyone else.

Please do not open a public issue, post to forums, or share publicly until we’ve had a chance to coordinate.

For sensitive reports, encrypt with our PGP key (fingerprint published at https://thegateway.pro/.well-known/security.asc).

Response timeline

Section titled “Response timeline”
  • Within 72 hours: acknowledgement of receipt and an initial assessment.
  • Within 7 days: confirmation of whether we’ve reproduced the issue and an estimate for a fix.
  • Within 90 days (typical): a patched release. Complex issues may take longer; we’ll keep you informed.

We follow coordinated disclosure. Once a fix is available and operators have had a reasonable window to update, we publish a CVE and credit the reporter (unless you’d rather stay anonymous).

In scope

Section titled “In scope”
  • The gatewayd daemon and the bundled web UI.
  • The gwctl CLI.
  • The bridge-node binary.
  • The default install script (install-gateway.sh).
  • Documented APIs (REST, Unix socket).

Out of scope

Section titled “Out of scope”
  • Issues in third-party dependencies we don’t maintain (file those upstream — we’ll help if you tell us).
  • Configuration mistakes by the operator that don’t represent a flaw in The Gateway itself (e.g. exposing the REST API to the public internet with a weak password).
  • Social-engineering or physical attacks against operators.
  • Best-practice gaps that aren’t exploitable (e.g. “you should use SHA-3 instead of SHA-256”).
  • Anything that requires already-root access to the daemon’s host (you’ve already lost — see the threat model).

What we will not do

Section titled “What we will not do”
  • Threaten legal action against good-faith researchers.
  • Demand exclusivity from you, or restrict how you write up the issue after disclosure.
  • Pay bounties (we’re a private project without a formal bounty program — but we’ll credit you publicly and send a thank-you).

Hardening guidance

Section titled “Hardening guidance”

The threat model page lists the recommended operator posture. The most important items:

  1. Restrict the REST API to the auth.local_net CIDR; for remote access, terminate mTLS at a reverse proxy.
  2. Run the daemon on a dedicated box.
  3. Keep gatewayd updated — security fixes ship in regular point releases.
  4. Take encrypted backups; verify restore quarterly.
  5. Treat the federation primary as a privileged role.
Section titled “Related”