CVE-2026-109362 in Heym
Summary
by MITRE • 10/12/2026
Heym v0.0.5 before v0.0.113 contains a broken access control vulnerability that allows former collaborators to keep executing JWT-auth workflows by reusing scoped workflow:execute tokens after share removal. Attackers can mint a token with a TTL up to 10 years, which the owner cannot list or revoke, and repeatedly run the workflow consuming shared credentials.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/12/2026
The vulnerability identified in Heym versions prior to v0.0.113 represents a critical failure in access control mechanisms within its JWT-based authentication system. Specifically, this flaw allows former collaborators who have been removed from a project or workspace to retain the ability to execute workflows that rely on shared credentials and resources. The core of the issue lies in how workflow execution tokens are minted and validated against user membership status at runtime. When a token is generated with specific scopes such as workflow:execute, it remains valid for its entire time-to-live period regardless of subsequent changes to the user's permissions or their removal from the associated entity. This creates a significant gap between authorization decisions made during initial access granting and those enforced during actual resource consumption.
From a technical perspective, this is an instance of improper privilege management where session state does not reflect current permission states. The attacker can exploit this by obtaining a valid JWT with high-value scopes before being revoked or removed from the collaboration space. Once obtained, these tokens possess a maximum time-to-live of up to ten years, which effectively renders any revocation mechanism useless for that specific token instance. Because the system does not perform real-time validation against an access control list when executing workflows, the malicious actor can continue to run automated processes indefinitely using shared secrets such as API keys or database credentials embedded within those workflows. This persistence is particularly dangerous because it bypasses standard administrative controls designed to limit exposure after personnel changes or security incidents.
The operational impact of this vulnerability is severe, enabling persistent unauthorized access and potential data exfiltration over extended periods. An adversary who gains initial foothold through compromised collaborator accounts can maintain long-term presence in the environment without detection by normal means since they are not actively listed as active users yet still possess valid execution rights. This leads to resource abuse including excessive compute costs due to repeated workflow executions, but more critically it risks exposure of sensitive data processed within those workflows. Since shared credentials are often used across multiple services or environments, compromise through this vector could lead to lateral movement and broader system infiltration beyond the immediate application scope.
This behavior aligns with CWE-639 which describes authorization bypass through vulnerability in session management and token handling. It also maps directly to MITRE ATT&CK technique T1078 Valid Accounts where attackers leverage legitimate credentials or tokens that have not been properly invalidated upon loss of trust relationship. The inability for owners to list or revoke these specific long-lived tokens further exacerbates the risk by removing standard remediation paths available in most identity and access management systems. Organizations relying on Heym must recognize that static token lifetimes combined with lack of revocation capability create a persistent threat surface even after explicit deauthorization actions are taken against individual users.
Mitigation strategies should focus primarily on upgrading to version v0.0.113 or later where this logic has been corrected to enforce dynamic permission checks at execution time rather than relying solely on static token validity periods. Until an upgrade is feasible, administrators must manually audit and rotate all shared credentials associated with workflows that may have been executed by former collaborators. Implementing shorter TTLs for JWT tokens wherever possible reduces the window of opportunity for exploitation while also limiting the duration of any potential unauthorized access. Additionally adopting a zero-trust architecture principle where every request is authenticated and authorized regardless of previous interactions can help prevent similar issues in future implementations ensuring that removal from collaboration spaces immediately invalidates all derived privileges including those encapsulated within long-lived tokens.