Do not report security vulnerabilities in public GitHub issues, discussions, social channels, screenshots, or public battle content.

This root file exists for GitHub community health and mirrors the canonical guide at docs/en/how-to/contributors/security.md.

LenserFight is experimental beta software. Security fixes are applied to the default development branches and current public beta release line. The project does not currently provide long-term support for old releases, forks, private deployments, or modified distributions unless maintainers announce a supported release line.

Preferred channel: GitHub Security Advisories.

1. Open the repository on GitHub.
2. Go to Security.
3. Choose Advisories.
4. Select Report a vulnerability.

If GitHub private vulnerability reporting is unavailable, contact lets@conectlens.com or ask a maintainer for a private reporting path before sharing details. Do not include secrets, personal data, exploit payloads, or third-party data unless strictly necessary for triage.

• Acknowledgement target: within 72 hours.
• Initial triage target: within 7 days.
• Maintainers may ask for a minimal reproduction, affected version/commit, deployment mode, logs with secrets removed, and impact assessment.
• Coordinated disclosure timing depends on severity, fix complexity, affected users, and whether a public advisory or CVE is appropriate.

• Authentication, authorization, account, token, or session bugs.
• Supabase RLS, grants, SECURITY DEFINER, storage, migration, RPC, or policy bypasses.
• Cross-user data exposure in profiles, comments, likes, leaderboards, battles, workflows, media, prompts, logs, telemetry, or generated content.
• Prompt-injection or model-output paths that can cause unauthorized tool use, file access, data leakage, command execution, provider-key exposure, unsafe delegation, workflow loops, or cross-user actions.
• BYOK/API key storage, encryption, logging, transmission, or disclosure weaknesses.
• Hosted platform, API, CLI, installer, deployment-template, or documentation issues that create practical security harm.
• Dependency, supply-chain, build, CI, or release issues with a clear LenserFight-specific impact.

• Generic AI hallucinations without a security, privacy, or abuse impact.
• Denial-of-service tests, scraping, load testing, spam, or rate-limit exhaustion without prior written authorization.
• Physical attacks, social engineering, phishing maintainers, or attacks against third-party providers.
• Findings that require destructive testing, persistence on systems you do not own, or access to another user's account or data.
• Vulnerabilities only present in substantially modified forks unless the same issue affects this repository.

We will not pursue legal action for good-faith security research that follows this policy, avoids privacy harm, avoids service disruption, uses only accounts and data you are authorized to access, and reports privately with enough detail for maintainers to reproduce and fix the issue. This is not permission to attack third-party services, bypass law, exfiltrate data, or run destructive tests.

• Do not access, modify, delete, copy, or retain another user's data.
• Do not publish exploit details before maintainers confirm a disclosure plan.
• Do not run malware, credential theft, phishing, spam, mass scraping, or persistence tests.
• Do not test against production infrastructure in a way that degrades availability or increases costs.
• Stop immediately if you encounter secrets, personal data, private prompts, API keys, tokens, or cross-user content. Report what happened and delete local copies unless maintainers request a secure transfer.

For agentic issues, include the smallest safe reproduction:

• deployment mode: local, self-hosted, hosted arena, CLI, gateway, or BYOK;
• affected agent, workflow, tool, connector, battle, or provider path;
• prompt/input/output snippets with secrets and personal data removed;
• whether the issue can trigger file access, command execution, network calls, external writes, cost consumption, or data exposure;
• expected approval/sandbox behavior and actual behavior.

Local BYOK keys (user_byok_local) live under ~/.lenserfight/keys/ on the user's machine. They are encrypted at rest with AES-256-GCM under a master passphrase held in the OS keychain. The LenserFight web app never stores ciphertext or plaintext locally — it accesses keys through the loopback gateway daemon (apps/gateway), authenticated by a paired bearer token.

Full threat model: docs/en/explanation/security/local-keys.md.

Quick rules for contributors touching libs/data/local-keys/, apps/gateway/src/handlers/keys.ts, or apps/gateway/src/auth/bearer.ts:

• Do not log plaintext key material, ciphertext, or the master passphrase.
• Do not introduce a path that lets the browser read or write directly to ~/.lenserfight/keys/; the gateway is the only sanctioned bridge.
• Keep the strict id regex (/^[A-Za-z0-9_-]{20,40}$/), O_NOFOLLOW, and O_EXCL checks intact.
• Update tests in libs/data/local-keys/tests/ and apps/gateway/src/{auth,handlers}/ when modifying any of the above files.

If you find a leaked API key, model-provider key, OAuth token, Supabase service key, webhook secret, signing key, or private key:

1. Do not use it.
2. Do not paste it into public issues or chat.
3. Report privately with the file path, commit hash, log location, or screenshot context.
4. Maintainers should rotate the secret, invalidate affected sessions or tokens, review logs for misuse, and remove the secret from history where appropriate.