Ling Stack coordinates models, local files, tools, credentials, approvals, external services, and desktop capabilities. Please report security issues privately so they can be investigated before public disclosure.

Ling Stack is currently a source-first alpha with no stable supported release line.

Security fixes target the current development line. A published version support policy will replace this table before the first stable release.

Use GitHub's private vulnerability reporting flow:

https://github.com/ling-stack-org/ling-stack/security/advisories/new

Sign in to GitHub and use the Report a vulnerability entry under the repository's Security tab. Maintainers must keep private vulnerability reporting enabled; it is a repository setting, not an ordinary public Issue template. English and Chinese reports are welcome.

If the private reporting button is unavailable, do not publish sensitive details in an issue, discussion, or pull request. A public request to restore the reporting entry must contain no exploit details, credentials, private workspace data, or unpatched proof of concept. Wait for a verified private reporting channel before sharing those details.

Include only the information needed to reproduce and assess the issue:

• affected commit, package, platform, and configuration;
• impact and required attacker access;
• minimal reproduction steps;
• relevant logs with credentials, tokens, local paths, and personal data removed;
• whether the issue is already public or actively exploited;
• suggested mitigation, if known.

Do not access data that is not yours, disrupt other users, publish secrets, or perform destructive testing. Use a local disposable workspace and test credentials whenever possible.

Maintainers will handle reports on a best-effort basis during the alpha period. The expected process is:

1. Confirm receipt and establish a private discussion.
2. Reproduce and classify the affected authority boundary.
3. Prepare a fix and focused regression coverage.
4. Coordinate disclosure after a fix or mitigation is available.
5. Credit the reporter when requested and appropriate.

Response and release timing depend on severity, reproducibility, platform access, and whether signing or upstream dependencies are involved. Please do not assume that silence authorizes public disclosure.

Reports are especially important when they involve:

• approval or permission bypass;
• command, prompt, workflow, or tool injection leading to unintended authority;
• path traversal or access outside the approved workspace;
• API key, token, Keychain, log, artifact, or SQLite disclosure;
• unauthenticated daemon, remote-access, WebSocket, or IPC access;
• external mutations executed without current approval or stale-target validation;
• plugin, MCP, provider, update, package, or supply-chain integrity;
• Computer Use capture/input crossing lock-screen or platform permission boundaries;
• unsafe media downloads, artifact handling, or local workflow execution.

• The daemon is loopback-only by default and should not be exposed directly to a network.
• Skills are instructions, not authority grants.
• Provider capability labels do not grant tools or filesystem access.
• External mutations, paid generation, destructive tools, and credential changes require explicit policy and approval boundaries.
• Unsigned local Desktop builds are development artifacts, not production releases.

See Approval Policy, Secrets And Keychain, and State Machines And Recovery for current design boundaries.