| Version | Supported |
|---|---|
| 1.x.x | ✅ |
| < 1.0 | ❌ |
We take security seriously. If you discover a security vulnerability in Debugssy, please report it responsibly.
- DO NOT open a public GitHub issue for security vulnerabilities
- Open a private security advisory at: GitHub Security Advisories
- Include:
- Description of the vulnerability
- Steps to reproduce
- Potential impact
- Suggested fix (if any)
- Initial response: Within 48 hours
- Status update: Within 7 days
- Fix timeline: Depends on severity (critical: ASAP, high: 2 weeks, medium: 1 month)
Debugssy implements multiple security layers:
┌─────────────────────────────────────────────────────────────┐
│ Security Layers │
├─────────────────────────────────────────────────────────────┤
│ 1. Network Security │ Localhost-only binding │
│ 2. Origin Validation │ DNS rebinding protection │
│ 3. Protocol Validation │ MCP version enforcement │
│ 4. Session Security │ Cryptographic UUIDs │
│ 5. Input Validation │ Zod schema validation │
│ 6. Expression Security │ Multi-layer pattern detection │
│ 7. User Confirmation │ Elicitation for risky operations │
└─────────────────────────────────────────────────────────────┘
The expression validator protects against code injection attacks through:
| Protection Layer | Attacks Blocked |
|---|---|
| Critical Operations | File system, process execution, network requests |
| Prototype Chain | __proto__, .constructor.constructor, pollution |
| Global Object Access | globalThis, window, global, self |
| String Obfuscation | String.fromCharCode, atob, Buffer.from |
| Meta-programming | Proxy, Reflect, Object.defineProperty |
| Comment Injection | /* */, //, # hiding malicious code |
| Dynamic Invocation | eval, Function, exec, compile |
| State Mutations | Assignments, push(), splice(), ++ |
| Bracket Obfuscation | Concatenation ["ev"+"al"](), template literals, variable identifiers [varName](), escape sequences ["\x65val"]() |
| Level | Risk Threshold | Use Case |
|---|---|---|
strict |
All risks | Maximum security |
moderate |
Medium+ | Balanced (default) |
permissive |
Critical + High | Experienced users |
disabled |
None | Fully trusted environments |
Start a new AI conversation for debugging sessions. This prevents:
- Prompt injection from previous web searches
- Context pollution from untrusted sources
- Accumulated malicious instructions
✅ Good: New chat → Debug session
❌ Bad: Web search → Debug in same chat
The primary attack vector for prompt injection is external content:
Attack Chain:
User searches web → Malicious site with hidden prompt injection
↓
AI reads poisoned content → AI manipulated
↓
AI calls evaluate_expression("malicious code")
Mitigation: Keep debugging sessions isolated from web searches.
{
"debugssy.expressionValidationLevel": "moderate"
}Never set to disabled unless in a fully trusted, isolated environment.
When the AI requests approval for an expression:
- Read the expression carefully
- Understand what it will do
- Reject if unfamiliar or suspicious
Restrict which tools the AI can use:
{
"mcpServers": {
"debugssy": {
"url": "http://localhost:3000/mcp",
"allowlist": [
"debugssy:get_debug_state",
"debugssy:get_variables",
"debugssy:get_call_stack",
"debugssy:list_breakpoints"
]
}
}
}See ALLOWLIST_GUIDE.md for complete examples.
| Threat | Mitigation |
|---|---|
| Prompt injection via AI | Expression validation, user elicitation |
| DNS rebinding attacks | Origin header validation |
| Remote access attempts | Localhost-only binding |
| Code injection via eval | Blocked at validator level |
| File system manipulation | Critical operation detection |
| Process execution | Critical operation detection |
| Prototype pollution | Prototype chain blocking |
| Obfuscated malicious code | Multiple obfuscation pattern detection |
| Threat | Reason |
|---|---|
| Malicious code in user's repo | User controls their own codebase |
| AI assistant vulnerabilities | Outside Debugssy's control |
| VS Code vulnerabilities | Outside Debugssy's control |
| Physical access attacks | Desktop security is user's responsibility |
| Social engineering | User education, not technical mitigation |
The regex-based expression validator has inherent limitations.
Previously, indirect invocation techniques (indirect calling conventions, array extraction, tagged template syntax) and Unicode confusable characters could bypass keyword detection. These have been addressed:
- Indirect
evalinvocation forms are now blocked by matching the bare keyword rather than onlyeval(call syntax - Unicode normalization (NFKC) is applied before validation to neutralize fullwidth and compatibility look-alike characters
Remaining inherent limitations of a regex-based approach:
- Novel obfuscation chains not yet covered by existing patterns may go undetected until identified and patched
- NFKC-invisible confusables — characters that are visually similar but have no NFKC decomposition to ASCII (e.g. some Cyrillic/Greek look-alikes) are not normalized away; a full Unicode confusables database would be needed for complete coverage
These residual risks are mitigated by:
- User elicitation for unrecognized patterns
- Operational security (fresh agent windows, avoiding web searches mid-session)
- Low likelihood of these specific techniques appearing in typical prompt injection attacks targeting a debug tool
Debugssy follows:
- MCP Security Best Practices 2025-06-18
- OWASP secure coding guidelines
- Principle of least privilege
See MCP_COMPLIANCE.md for detailed compliance information.
Security updates are released as patch versions (e.g., 1.4.5) and announced via:
- GitHub Releases
- VS Code Marketplace update notifications
- GitHub Security Advisories (for vulnerabilities)
Always keep Debugssy updated to the latest version.
We appreciate responsible security researchers who help make Debugssy safer. Contributors who report valid security issues will be acknowledged here (with permission).
- Security issues: GitHub Security Advisories
- General questions: GitHub Issues
- Documentation: README.md