GHSA-378x-q589-34mv: Heym: Command execution via POST /api/mcp/fetch-tools stdio transport: supplied command is spawned before MCP validation
Heym builds and runs agentic systems and business-process automations on self-hosted infrastructure. Prior to version 0.0.75, the same POST /api/mcp/fetch-tools endpoint (any authenticated user, lowest role) also accepts the stdio transport, which spawns the attacker-supplied command with attacker-supplied args and an environment merged over os.environ. The process executes on the shared backend host before MCP protocol validation fails — so side effects fire regardless of whether the command speaks MCP. This is a distinct weakness class and exploit primitive from the SSRF (Advisory 2) on the same endpoint, and needs a different fix (role gating / opt-in trust boundary rather than egress controls). This issue has been patched in version 0.0.75.
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Heymto a version that resolves this vulnerability.Fixed in 0.0.75
Event History
Frequently Asked Questions
Who can exploit this issue?
Any authenticated Heym user, including the lowest-privileged role, can exploit it if they can send requests to the POST /api/mcp/fetch-tools endpoint. Exploitation does not require user interaction.
What does an attacker need to provide?
The attacker supplies a stdio transport configuration containing a command and arguments. Heym spawns that command on the shared backend host before validating whether it implements the MCP protocol.
Are failed MCP validation attempts safe?
No. The spawned process can perform side effects even if MCP protocol validation subsequently fails, because execution occurs before that validation.
What should be done if an immediate upgrade is not possible?
Restrict access to the affected endpoint and prevent low-privileged users from using the stdio transport. The described mitigation is role gating or making stdio use an explicit opt-in trust boundary; egress controls alone address the separate SSRF issue rather than this command-execution primitive.
How can I determine whether an installation is affected?
Installations running a version earlier than 0.0.75 are affected. Version 0.0.75 contains the patch.