See also: Security on the docs site for a quick overview with self-hosted best practices.

We recommend always running the latest version. Security patches are backported to the previous minor release on a best-effort basis.

Please do NOT open a public GitHub issue for security vulnerabilities.

Use GitHub Security Advisories to report vulnerabilities privately. This ensures the report is only visible to maintainers until a fix is released.

Alternatively, email security@fim.ai with:

• A description of the vulnerability
• Steps to reproduce (or a proof-of-concept)
• Affected versions
• Potential impact assessment

For low-severity issues (e.g., missing security headers, informational disclosures that don't expose sensitive data), you may open a regular GitHub issue with the security label.

The following are in scope for security reports:

• Authentication and authorization bypass
• SQL injection, command injection, or code execution
• Cross-site scripting (XSS) or cross-site request forgery (CSRF)
• Credential or API key exposure
• Privilege escalation between users or organizations
• Data leakage across tenant boundaries

The following are out of scope:

• Vulnerabilities in third-party dependencies (report upstream; we monitor via Dependabot)
• Social engineering attacks
• Denial of service (DoS) without a realistic attack vector
• Issues in the demo/cloud environment that don't affect self-hosted deployments

• Keep your .env file out of version control (it's in .gitignore by default)
• Use strong, unique values for JWT_SECRET_KEY
• Run behind a reverse proxy (nginx, Caddy) with TLS in production
• Use PostgreSQL (not SQLite) for multi-user production deployments
• Regularly update to the latest release

We appreciate responsible disclosure. Contributors who report valid security vulnerabilities will be credited in the release notes (unless they prefer to remain anonymous).