Please do not open a public GitHub issue for security vulnerabilities.
To report a vulnerability, use one of these channels:
- GitHub private disclosure: Use the Security tab to submit a private advisory.
- Email: Send a description to
security.i9v75@8alias.comwith the subject line[task-queue-mcp] Security Report.
Include as much detail as possible: the affected component, steps to reproduce, and potential impact.
In scope:
- Task injection enabling unauthorized task creation, modification, or status manipulation
- Privilege escalation by dispatching tasks to unintended agents with elevated access
- Information disclosure through task payload content containing credentials or sensitive data
- Dependency vulnerabilities with a plausible exploitation path in task-queue-mcp's usage
Out of scope:
- Vulnerabilities in the host system, underlying services, or MCP transport layer
- Issues that require attacker control of configuration environment variables (operator-controlled trust boundaries, not input attack surfaces)
- Theoretical weaknesses without a realistic attack path against the MCP tool surface
Port 8485 serves two surfaces with separate credentials:
/mcp(agents): a per-agent bearer token inAuthorization. It authenticates the caller and names it;actoris derived from it./tasks…and/queue/summary(operator clients): a per-client token inX-Task-Queue-Token, with areadoroperator-writescope required per route. The server stores onlysha256:digests of client tokens. An agent bearer grants nothing on these routes, and a client token grants nothing on/mcp.
These contain a mistaken or prompt-injected agent acting through its own tool surface. They are not a boundary against a process running as the same OS user that owns the token files. A client token is only a boundary when its plaintext is held by a different OS user from the agents. See the README's Trust model section.
Reports that assume the attacker can read the operator's env or token files as the owning user are out of scope under "attacker control of configuration environment variables" below.
| Stage | Timeline |
|---|---|
| Acknowledgement | Within 3 business days |
| Initial assessment | Within 7 business days |
| Fix or remediation plan | Within 30 days for critical/high; 60 days for medium/low |
This is a personal project maintained by one developer. Response times are best-effort. If you haven't heard back within 3 business days, a follow-up email is welcome.
Coordinated disclosure is preferred. Please allow time for a fix to be released before public disclosure. The CHANGELOG documents remediated findings at an appropriate level of detail after each release.