Skip to main content

​
Security Policy

Thank you for your interest in the security of Maestro. We welcome contributions from security researchers and the broader community to help keep this project safe.

​
Reporting a Vulnerability

​
For Most Issues

Please open a GitHub issue with the security label. Include:
  • A clear description of the vulnerability
  • Steps to reproduce
  • Potential impact
  • Suggested fix (if you have one)

​
For Serious/Critical Issues

If you discover a vulnerability that could cause significant harm if disclosed publicly before a fix is available, please contact us directly: Email: [email protected] This allows us to develop and release a patch before public disclosure.

​
Scope

​
In Scope

Security issues within these areas are in scope for Maestro security reports:

Application Code

  • Electron main process
  • Renderer process
  • Preload scripts

Security Mechanisms

  • IPC handler security
  • Process spawning
  • Command execution

File System

  • Local file access
  • Path traversal
  • Permission handling

Network

  • Web server
  • Tunnel functionality
  • Authentication

​
Out of Scope

The following are not in scope for Maestro security reports:
AI Agent Vulnerabilities - Security issues within Claude Code, OpenAI Codex, OpenCode, Factory Droid, or other integrated agents are the responsibility of their respective maintainers.
Upstream Dependencies - Vulnerabilities in Electron, Node.js, or npm packages should be reported to those projects (though please let us know if Maestro is using a vulnerable version).
Also out of scope:
  • Social engineering attacks
  • Denial of service on local application
  • Issues requiring physical access to the user’s machine

​
Response Timeline

We aim to respond to security reports as soon as possible. However, please understand that Maestro is an open source side project maintained by volunteers. Until there is a larger developer community behind it, we cannot commit to specific response timelines. What you can expect:
  1. Acknowledgment of your report
  2. Assessment of severity and impact
  3. A fix prioritized based on severity
  4. Credit in our release notes (unless you prefer to remain anonymous)

​
Recognition

We appreciate security researchers who help improve Maestro. Contributors who report valid security issues will be:
  • Credited in release notes and this document (with permission)
  • Thanked publicly (unless anonymity is preferred)

​
Security Contributors

  • @VVX7 - Reported multiple XSS vulnerabilities (#421, #422, #423) fixed in v0.15.x
  • Your name could be here!

​
Bug Bounty

There is no bug bounty program at this time. Maestro is an open source project without funding for monetary rewards. We hope the satisfaction of contributing to open source security and public recognition is sufficient motivation.
We also welcome pull requests! If you find a vulnerability and know how to fix it, PRs are greatly appreciated.

​
Known Security Considerations

The following are known aspects of Maestro’s design that users should be aware of:

​
Process Execution

Maestro spawns AI agents and terminal processes with the same privileges as the user running the application. This is by design—the agents need filesystem and command access to function. Users should:
  • Only run Maestro on projects they trust
  • Be aware that AI agents can execute commands on your system
  • Review agent actions, especially on sensitive repositories

​
Local Web Server

When the web/mobile interface is enabled, Maestro runs a local web server. The Cloudflare tunnel feature can expose this externally. Users should:
  • Only enable tunnels when needed
  • Be aware of who has access to tunnel URLs
  • Disable the web server when not in use

​
IPC Security

Maestro uses Electron’s IPC for communication between the main process and renderer. We follow Electron security best practices:
  • Context isolation: Enabled
  • Node integration: Disabled
  • Preload API surface: Minimal (only expose what’s necessary)
  • Input validation: All IPC inputs validated in main process handlers

​
Sentry DSN

The Sentry DSN in the codebase is a public secret by design. This is standard practice for client-side error reporting—the DSN is intentionally exposed to allow error telemetry. Reporting this as a vulnerability is not necessary. We monitor for abuse and will rotate keys if needed.

​
Security Best Practices in Codebase

For contributors, Maestro enforces these security patterns:

​
Command Execution

import { execFileNoThrow } from '../utils/execFile';

// Secure: Uses spawn with shell: false
const result = await execFileNoThrow('git', ['status'], { cwd });

​
File Path Validation

// Always sanitize and validate file paths
const sanitizedPath = path.normalize(userProvidedPath);
if (!sanitizedPath.startsWith(expectedBaseDir)) {
  throw new Error('Invalid path');
}

​
IPC Input Validation

// Main process IPC handler
ipcMain.handle('myNamespace:myAction', async (_, filePath: string) => {
  // Validate inputs
  if (typeof filePath !== 'string') {
    throw new Error('Invalid input type');
  }
  
  // Sanitize paths
  const safe = path.normalize(filePath);
  
  // Perform action
  return doSomething(safe);
});

​
Additional Resources

​
Contact

For security concerns:

Build docs developers (and LLMs) love

Get started for freeTalk to us