CVE-2026-100862 in heym
Summary
by MITRE • 09/27/2026
heym, a workflow automation platform, stores and returns multiple capability secrets in plaintext in versions prior to 0.0.91. Affected secrets include webhook header-auth values (returned in cleartext by GET /api/workflows/{id} and persisted unsanitized into execution history), MCP API keys (stored as a plaintext column, returned in config/list responses, and accepted via the ?key= query string so they leak into logs, proxies and Referer headers), portal session tokens (stored and validated by plaintext equality with a 168-hour TTL), workflow execution JWTs (stored in full and re-listed by GET .../execution-tokens), Discord interaction tokens (the full interaction body is stored in execution history), and global variables. A user with read access to a workflow, share/team membership, or anyone able to read the database, a backup, or logs can recover these secrets and replay them to execute workflows or act as the secret owner.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/27/2026
The vulnerability identified in heym versions prior to 0.0.91 represents a critical failure in credential management and data protection mechanisms within a workflow automation platform. This flaw is classified under CWE-312, which addresses Cleartext Storage of Sensitive Information, indicating that the application fails to protect sensitive data at rest or during transmission through adequate encryption or obfuscation techniques. The core issue stems from the architectural decision to store and expose various types of secrets in plaintext formats across multiple endpoints and internal storage systems. This includes webhook header-auth values, MCP API keys, portal session tokens, workflow execution JWTs, Discord interaction tokens, and global variables. By treating these high-value credentials as plain text rather than encrypted or hashed entities, the platform exposes them to a wide range of potential attackers who gain access to any layer of the system's data persistence or logging infrastructure.
The operational impact of this vulnerability is severe due to the breadth of secrets exposed through different vectors. Webhook header-auth values are returned in cleartext via GET requests for workflow details and are also persisted unsanitized into execution history, allowing an attacker with read access to a specific workflow to retrieve authentication credentials used by external services. MCP API keys present another significant risk vector; they are stored as plaintext columns in the database, exposed through configuration list responses, and accepted via query strings. This design choice causes these sensitive keys to leak into server logs, reverse proxy records, and browser Referer headers when accessed improperly or logged for debugging purposes. Such leakage expands the attack surface beyond direct application access to include log files and network monitoring tools that might be accessible by lower-privileged users or compromised systems.
Further compounding the risk are portal session tokens and workflow execution JWTs which suffer from inadequate lifecycle management and exposure. Portal session tokens are stored and validated using simple plaintext equality checks with a long-lived TTL of 168 hours, making them highly susceptible to theft and replay attacks if intercepted. Similarly, workflow execution JSON Web Tokens are stored in full and re-listed via API endpoints dedicated to retrieving execution tokens. This means that any user or process capable of querying these endpoints can obtain valid authentication artifacts for ongoing workflows. Additionally, Discord interaction bodies containing sensitive data are fully stored within the execution history without sanitization, exposing private communication contexts associated with automated interactions on social platforms.
The exploitation scenario is straightforward and relies primarily on access to underlying infrastructure rather than complex code injection techniques. An attacker who obtains read-only access to a workflow configuration, gains membership in a shared team environment where they can view workflows, or compromises the database directly through SQL injection or unauthorized backup retrieval can extract these plaintext secrets. Once obtained, an adversary can replay webhook headers to impersonate legitimate services, use MCP API keys to interact with external APIs as authorized users, utilize session tokens and JWTs to hijack active workflow executions, and leverage Discord tokens to perform actions on behalf of the token owner. This capability aligns closely with ATT&CK techniques such as T1552 Unsecured Credentials, where attackers gather credentials from local systems or networked resources, and T1078 Valid Accounts, allowing them to authenticate using stolen legitimate credentials to maintain persistence and execute malicious workflows without detection by standard authentication monitoring tools.
Mitigation strategies must focus on immediate remediation of storage mechanisms and API responses alongside long-term architectural improvements. The most urgent action is to upgrade the heym platform to version 0.0.91 or later, where these plaintext exposure issues have been addressed. For environments unable to immediately patch, it is critical to rotate all exposed secrets including webhook auth values, MCP keys, session tokens, JWTs, and Discord tokens as they are likely compromised given their historical storage in plaintext. Access controls must be tightened to ensure that workflow execution history and configuration endpoints do not expose sensitive fields to users with only read permissions. Furthermore, logging configurations should be audited to prevent the inclusion of query parameters containing API keys or other secrets in log files. Future development should enforce encryption at rest for all credential data, implement strict input sanitization before storing execution histories, and utilize secure token management practices such as short-lived tokens and proper hashing mechanisms rather than plaintext equality checks.