Skip to content

Security: RunMaestro/Maestro

SECURITY.md

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: pedram@runmaestro.ai

This allows us to develop and release a patch before public disclosure.

Maintainers handle every report with the same procedure, from triage to advisory, CVE, patched releases, and credit: docs/agent-guides/SECURITY-RUNBOOK.md.

Scope

In Scope

  • Maestro application code (Electron main process, renderer, preload scripts)
  • IPC handler security
  • Process spawning and command execution
  • Local file system access
  • Web server and tunnel functionality
  • Authentication and session management

Out of Scope

The following are not in scope for Maestro security reports:

  • AI agent vulnerabilities - Security issues within Claude Code, OpenAI Codex, Gemini CLI, Qwen3 Coder, 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)
  • 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:

  • Acknowledgment of your report
  • Assessment of severity and impact
  • A fix prioritized based on severity
  • 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:

  • CopperKoi - web control server exposure and cross-origin access (October 2026), with thanks to their mentor notwo1f, who guided the audit
  • YoAm - web control server exposure and token file permissions (August 2026)

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

Maestro always runs a local web server so maestro-cli can control the app. Every route requires a random token in the URL, and that token grants full control, including terminals.

  • While Live Mode is off, the server listens on 127.0.0.1 only. The token is in cli-server.json in the app data directory, readable only by your user.
  • Turning Live Mode on restarts the server on every interface so a phone on your LAN can connect. The LAN URL is plain HTTP, so anyone who can watch your network traffic while Live Mode is on can read the token.
  • Browser requests from a page the server did not serve are refused, so a web page that learns the URL cannot use it.
  • The Cloudflare tunnel feature publishes the same server on a public HTTPS URL.

Users should:

  • Turn Live Mode on only when they need it, and only on networks they trust
  • Prefer the Cloudflare tunnel (HTTPS) over the LAN URL on shared Wi-Fi
  • Be aware of who has access to Live and tunnel URLs

IPC Security

Maestro uses Electron's IPC for communication between the main process and renderer. We follow Electron security best practices including context isolation and a minimal preload API surface.

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:

  • Always use execFileNoThrow for external commands-never shell-based execution
  • Validate all IPC inputs in main process handlers
  • Minimize preload API surface-only expose what's necessary
  • Sanitize file paths before filesystem operations

See CLAUDE.md and CONTRIBUTING.md for more details.

Learn more about advisories related to RunMaestro/Maestro in the GitHub Advisory Database