Skip to content

Security: tomasfil/blazedex

Security

SECURITY.md

Security Policy

Reporting a vulnerability

If you believe you've found a security issue in BlazeDex — a vulnerability that could lead to remote code execution, path traversal, unauthorized access to a target solution, or similar — please report it privately.

How to report

Use GitHub's private vulnerability reporting:

  1. Go to https://github.com/tomasfil/blazedex/security/advisories
  2. Click New draft security advisory
  3. Fill in the form with what you found, how to reproduce it, and the impact

That creates a private thread that only the maintainer can see.

If that's not practical (e.g., you don't have a GitHub account), email the maintainer via the contact details on https://github.com/tomasfil — please prefix the subject with [BlazeDex security] so it's triaged quickly.

What to expect

  • An acknowledgment within 72 hours of your report
  • A first substantive response within 7 days
  • A fix or a reasoned workaround as soon as severity warrants
  • Credit in the release notes and the CVE (if one is issued), unless you ask to stay anonymous

Scope

In scope:

  • The BlazeDex MCP server binary (BlazeDex.Mcp.dll) and its direct dependencies as shipped in official releases
  • The add_parameter edit tool's write path (Roslyn SymbolEditor)
  • Any way to coerce BlazeDex into reading, modifying, or leaking files outside the configured solution / project directory

Out of scope:

  • Vulnerabilities in Claude Code, Claude Desktop, or other MCP hosts — report those to the respective projects
  • Vulnerabilities in Roslyn, MSBuild, or the official Anthropic C# MCP SDK — report those to their respective maintainers
  • Local-machine attacks that assume the attacker already has full code-execution as the BlazeDex-running user
  • Denial-of-service via a specially crafted Blazor solution that blows up memory or runs forever — BlazeDex is single-process and operates on user-supplied projects; we'll happily discuss tightening it, but such reports are triaged as quality issues, not vulnerabilities

Disclosure policy

  • We aim to coordinate disclosure — you report privately, we fix it, we publish the fix and the advisory together
  • If a fix is going to take more than 90 days, we'll keep you informed and discuss an extended timeline
  • If a fix has been shipped but the advisory hasn't been published yet (e.g., we're still crediting contributors), we'll sync with you before going public

Thanks for helping keep BlazeDex and its users safe.

There aren't any published security advisories