Threat model
The server assumes a hostile network and a non-malicious agent. It does not assume the agent is bug-free.
In practice: an agent can hallucinate a path, request a delete it should not have, or send a message to the wrong recipient. Every safety mechanism — confirm flag, path-guard, log redaction — is designed for that case, not for an attacker on the LAN.
For an attacker on the LAN, we rely on TLS to your NAS and (for non-stdio transports) MCP_AUTH_TOKEN. If you bind SSE to 0.0.0.0 without a token, the server refuses to start.
How secrets are handled
- 01Loaded once from the environment at startup. Never read from disk after.
- 02Never logged — redaction sits between the transport layer and the logger, not at the call site.
- 03Never sent in URLs. Auth uses POST with form body; session id is forwarded in the Cookie header only.
- 04Never echoed back through the MCP protocol. Tool errors carry typed codes, not values.
Network surface
| Surface | Default | When opened |
|---|---|---|
| Outbound to NAS | TLS verify on | Always. |
| Outbound to internet | None | Never. The server makes zero non-NAS calls. |
| Inbound (stdio) | pipes | Always — local only by definition. |
| Inbound (SSE/HTTP) | Loopback only | Non-loopback requires MCP_AUTH_TOKEN. |
| Telemetry / analytics | Off, no flag to turn on | Never. Not implemented. |
Reporting a vulnerability
Email [email protected] with a description and a reproduction. Encrypt with our PGP key (fingerprint below) if the issue is sensitive.
PGP fingerprint7C2A 8B19 4E3F 0D11 9F02 6A77 4F8C E1B3 8204 D9A6
Initial responseWithin 72 hours.
Disclosure window90 days, negotiable for fix-in-progress.
BountyNo formal program. We send thank-you notes and credit in the changelog if you want it.
Out of scopeDSM vulnerabilities themselves — please report those directly to Synology PSIRT. We are happy to help triage if you are not sure where a finding belongs.