_{English · Español}

_{Website · Documentation · Home · Changelog}

Only the latest commit on main receives security patches.

Do not open a public issue. Instead, email:

trinaxcode@gmail.com

We aim to respond within 72 hours and publish a fix within 7 days of confirmation.

• A clear description of the vulnerability
• Steps to reproduce (proof-of-concept code helps)
• Affected components (RAG API, PWA frontend, shell scripts, CLI, installer)
• Whether you believe it's exploitable remotely or only locally
• Any suggested mitigations

1. You report privately via email.
2. We acknowledge within 72 hours and begin triage.
3. We develop and test a fix.
4. We publish a GitHub Security Advisory (GHSA) and patch release.
5. You receive credit in the advisory (unless you prefer anonymity).

TrinaxAI is local-first: inference and persisted application data use the configured host by default. Installation/model downloads, explicit web research, external assets, and operator-configured remote endpoints are network activity. The primary attack surface is:

• Vulnerabilities in third-party dependencies (Ollama, LlamaIndex, Node.js modules) — report those upstream
• Social engineering attacks against users
• Physical access to the host machine
• Denial of service via resource exhaustion (inherent to running LLMs locally)

TrinaxAI's threat model assumes:

1. Trusted local machine — the host is not compromised
2. Untrusted LAN by default — possession of the same WiFi is not identity; protected remote requests require a scoped paired-device token or the administrator credential
3. Untrusted internet — TrinaxAI should never be exposed directly to the internet without a VPN or authenticated reverse proxy

• LAN attacker (same WiFi, no credential): The gateway preserves the signed original IP, so a proxied client cannot inherit loopback privilege. The rate-limited new-device bootstrap can issue only chat/web; app state, attachments, sources, memory, index/system routes and the agent still return 403 without their scopes.
• Stolen device token: A device token is a bearer capability limited to its recorded scopes. A new PWA claim keeps it only in an HttpOnly; SameSite=Strict cookie scoped to /api; the browser never receives a new bearer in JSON or persists it in browser storage. FastAPI stores only a keyed hash, and host/admin operators can revoke it immediately. A legacy bearer stored in the browser is read only for the explicit /v1/pairing/me migration and cleared after a successful response. Legacy CLI bearers remain header-only and are never copied into a response cookie. Pair only devices you control and revoke a lost device with trinaxai pair revoke; the CLI remains header-based.
• Forged proxy identity: Client-supplied TrinaxAI/forwarding headers are stripped by the gateway. FastAPI accepts a fresh, single-use HMAC signature only from loopback or an explicitly configured private runtime peer; network membership alone grants no privilege without the secret in storage/.proxy_secret.
• Prompt injection in indexed/web content: Retrieved material is delimited and labelled untrusted. It cannot authorize a tool. Keep dangerous-action approval on; HTTP yolo is off and restricted to real loopback even when explicitly enabled.
• Remote attacker (internet): Should be impossible if ports are not forwarded. Use a VPN for remote access.
• Malicious tarball (backup.sh restore): Only the expected .env, storage/ and local_sources/ trees are accepted; absolute/traversal paths, links and device entries are rejected before staged replacement.

1. Keep FastAPI and Ollama on loopback. Leave TRINAXAI_UNSAFE_BIND_BACKEND=0; publish only the authenticated PWA gateway.
2. Pair devices with least privilege. trinaxai pair start grants chat,read_private by default. Add web, or the elevated index, agent and modify permissions, only for a device you trust with your files: index lets it index/watch folders and delete sources, agent lets it run the Agent (still confirming every dangerous action), and modify lets it edit memory and web-search settings. Change a device later with trinaxai pair set ID --scopes ..., review trinaxai pair list, and revoke devices that are lost or no longer used.
3. Administer only from https://localhost:3334. Power and lifecycle actions, model and device management, factory reset, and the Agent's YOLO (auto-approve) mode require verified loopback and can never be granted to a device. Elevated permissions are granted only by the localhost operator; a device cannot raise its own, and an admin token sent over the network does not unlock them.
4. Keep credential secrets private. Never share storage/.proxy_secret or storage/.device_secret; preserve mode 0600 on those files and on storage/device_pairing.json.
5. Use a firewall to restrict the PWA port to intended devices and block direct ports 3333/11434.
6. Use a VPN (Tailscale, WireGuard) for remote access — never forward ports directly to the internet.
7. Keep dependencies reproducible and audited — install requirements.lock, run pip-audit --require-hashes -r requirements.lock and npm audit. There are no advisory exceptions: CI fails on any known vulnerability.
8. Keep shell isolation fail-closed. Install bubblewrap on Linux; do not enable TRINAXAI_AGENT_ALLOW_UNSANDBOXED_COMMANDS on a remotely reachable service.
9. Encrypt backups when they leave the host; the archive includes .env, chats, attachments, sources and indexes even though its filesystem mode is private.
10. Audit your install with trinaxai doctor --strict --json and python3 scripts/public_readiness.py.

• CI runs tests/build/typecheck/lint, hashed-lock pip-audit, Bandit, npm audit, gitleaks, CodeQL and public-readiness checks. It produces a CycloneDX Python SBOM.
• Dependabot monitors Python and npm dependencies weekly
• No secrets, tokens, or credentials are committed (enforced by .gitignore)
• Tagged releases build a deterministic archive, SHA-256 sums and GitHub/Sigstore provenance. The scheduled updater only checks availability; installation changes remain a reviewed manual operation.

We thank all security researchers who responsibly disclose vulnerabilities. Contributors will be listed here (with permission).