Pluma is a self-hosted local-LLM chat app. The threat model assumes the operator runs it on a machine they own; the highest-risk surface is the HTTP API (chats, attachments, model downloads, character cards, image generation) reached over loopback, a tailnet, or a reverse proxy.

Open a private security advisory on GitHub: https://github.com/guygrigsby/pluma/security/advisories/new

Or email the maintainer directly if you can't use advisories. Expect an initial response within a few days; coordinated disclosure timeline is negotiable but 90 days from first contact is the default upper bound.

Please don't file public issues or send proofs-of-concept to the project's discussion channels until a patch is available.

• Authentication, session, and authorization flows (server/auth.go, server/auth_handlers.go, the WebAuthn pairing chain).
• Path-traversal or RCE-shaped issues anywhere a user-supplied string becomes part of a filesystem path or an exec argument.
• CSRF / SSRF / cross-origin paths against the local HTTP API.
• Cryptography (server/cryptostore.go, the keyring integration).
• The Tailscale (tsnet) integration's host trust boundary.

• The user voluntarily disabling safeties (require_auth=false, loopback_auth_bypass=true plus a misconfigured reverse proxy, etc.). Behaviour is documented; if there's a docs gap that makes the insecure configuration easy to fall into, that's in scope as a docs issue.
• Vulnerabilities in third-party providers pluma can be pointed at (Ollama, A1111, ComfyUI, OpenAI, Anthropic). Report those upstream.

• require_auth = true (default).
• Enroll a WebAuthn passkey on every device that reaches pluma off loopback.
• Set allowed_hosts if pluma is exposed on a LAN or behind a reverse proxy.
• Set trusted_proxies if pluma sits behind a reverse proxy.
• Use TLS for any non-loopback access. The embedded Tailscale path handles this automatically; behind a non-Tailscale proxy, terminate TLS at the proxy.