The following versions of KINDX are currently receiving security updates:

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

Opening a public issue exposes the vulnerability to all users -- including malicious actors -- before a patch is available.

1. Email the maintainer directly at: contact@riteshrana.engineer
2. Use the subject line: [SECURITY] KINDX - <brief description>
3. Include the following in your report:
   • A description of the vulnerability and its potential impact
   • Steps to reproduce the issue
   • Any proof-of-concept code or screenshots
   • The version(s) affected
   • Your suggested fix (if you have one)

We will keep you informed throughout the process and, with your permission, will credit you in the security advisory upon public disclosure.

The following are in scope for security reports:

• CLI tool (engine/kindx.ts): Arbitrary code execution, path traversal, command injection
• SQLite operations (engine/repository.ts, engine/runtime.ts): SQL injection, data corruption, unauthorized data access
• LLM model loading (engine/inference.ts): Model supply chain attacks, unsafe deserialization
• MCP server (engine/protocol.ts): Unauthorized access, data exfiltration, SSRF
• Collection management (engine/catalogs.ts): Path traversal via collection paths
• GitHub Actions workflows (.github/workflows/): Secrets exposure, workflow injection, supply-chain attacks
• Dependency vulnerabilities: Known CVEs in package.json dependencies

The following are out of scope:

• Vulnerabilities in upstream GGUF models or HuggingFace infrastructure -- report to those vendors
• Local file system access (KINDX is designed to read local files -- this is expected behavior)
• Social engineering attacks

When contributing to this project, please observe the following:

• Never hardcode credentials, tokens, or API keys -- use environment variables
• Validate all external data -- data from LLM responses and file paths should be treated as untrusted
• Pin dependency versions -- use exact versions in package.json to prevent supply-chain attacks
• Review GitHub Actions permissions -- workflows should request the minimum permissions required

When running KINDX in HTTP daemon mode (kindx mcp --http), the MCP endpoint binds to loopback (localhost/127.0.0.1) and enforces bearer-token authentication for /mcp, /query, and /search.

Authentication token source (in order):

1. KINDX_MCP_TOKEN if explicitly set.
2. Existing token file at ~/.config/kindx/mcp_token when it contains a non-empty token.
3. Auto-generated token persisted to ~/.config/kindx/mcp_token (mode 0600) on first HTTP startup.

If the token file exists but is empty/whitespace, KINDX treats it as missing and regenerates a fresh token before serving requests.

For shared hosts and networked deployments, set and rotate KINDX_MCP_TOKEN explicitly:

# Generate a token and export it before starting the daemon:
export KINDX_MCP_TOKEN="$(openssl rand -hex 32)"
kindx mcp --http --port 7700

When auth is active:

• All requests to /mcp, /query, and /search must include Authorization: Bearer <token>
• The /health endpoint is intentionally exempt (monitoring probe compatibility)
• Any request with a missing or incorrect token receives 401 Unauthorized

MCP client configuration: Pass the token via the Authorization header in your MCP client config. For Claude Desktop and most MCP-compatible clients, set the headers field in the server configuration:

{
  "mcpServers": {
    "kindx": {
      "url": "http://localhost:7700/mcp",
      "headers": { "Authorization": "Bearer <your-token>" }
    }
  }
}

If you do not explicitly set KINDX_MCP_TOKEN, use the generated token from ~/.config/kindx/mcp_token when configuring MCP clients.

Thank you for helping keep KINDX and its users safe.