ForgeWeave operates inside developer environments and handles file system operations, agent execution, and MCP integrations. Security is treated as a first-class concern, not an afterthought.

Only the latest stable release and the current dev branch receive security fixes.

Do not open a public GitHub Issue for security vulnerabilities.

Public disclosure before a fix is available puts all ForgeWeave users at risk.

Send a detailed report to:

razaibkhanofficial@gmail.com

Use the subject line: [SECURITY] <brief description>

If you want to encrypt your report, our PGP public key is available upon request.

A useful security report contains:

• Description: What is the vulnerability? What component does it affect?
• Impact: What can an attacker do by exploiting this? (e.g., arbitrary file write, agent command injection, template escape)
• Reproduction steps: Exact steps to reproduce the issue.
• Environment: Python version, OS, ForgeWeave version, TUI adapter in use.
• Proof of concept: Code or commands that demonstrate the vulnerability (do not include live exploits targeting other systems).
• Suggested fix: Optional, but appreciated.

ForgeWeave follows coordinated vulnerability disclosure:

1. Reporter submits vulnerability privately.
2. Maintainers assess, develop, and test a fix.
3. Fix is released.
4. A security advisory is published on GitHub (typically 7 days after fix release).
5. Reporter is credited (unless they prefer anonymity).

We do not support immediate full public disclosure before a fix is available. If a reporter disagrees with our assessment or timeline, we ask for direct communication before any public action.

Given the nature of ForgeWeave, contributors and users should be aware of these inherent risk surfaces:

ForgeWeave generates and modifies files in the user's project directory. All destructive operations (overwrite, delete) require explicit confirmation. Any PR that bypasses this confirmation requirement will be rejected.

Agents execute structured workflows. No agent may spawn subprocesses, make network calls, or access paths outside the project directory without explicit user configuration and documented behavior.

Templates are processed before being written to disk. Template variables must be sanitized before rendering. Untrusted input must never reach the template engine directly.

MCP servers are configured as external processes in TUI config files. Each server is scoped to the tools it exposes. MCP configuration is generated by forge init and the user controls which servers are enabled. No MCP server may grant write access beyond the project directory without user-level opt-in.

The core ForgeWeave system must function without external network calls. Any contribution that introduces a mandatory external API dependency in the core execution path will be rejected.

ForgeWeave does not currently offer a paid bug bounty program. We do offer:

• Public credit in the security advisory and CHANGELOG.
• A contributor badge on your GitHub profile (if desired).
• Our genuine gratitude.

The following are not considered security vulnerabilities for ForgeWeave:

• Issues in third-party TUI tools (OpenCode, Claude Code, Gemini CLI, Qwen Code) — report these to their respective maintainers.
• Theoretical vulnerabilities with no practical exploitation path.
• Vulnerabilities requiring physical access to the user's machine.
• Self-inflicted issues from deliberately misconfigured environments.