Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessObtain collaborator access to workspace
-
DeliveryMint scoped workflow:execute JWT with long TTL
-
ExploitShare access revoked by owner
-
ExecutionReuse unexpired token to call execute API
-
ImpactRepeatedly run workflow consuming shared credentials
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A07:2025 - Authentication Failures
ASVS 5.0
V7 - Session Management Session expiration enforcement
|
| Exploitation Conditions | Exploitation requires that the attacker previously held collaborator access to a Heym workspace and minted a scoped 'workflow:execute' JWT token while authorized; the flaw is that this token remains valid after the share is removed because it carries a long configurable TTL (up to 10 years) and cannot be listed or revoked by the owner. Limiting factors: the attacker must have been a legitimate collaborator at some point (PR:L - not an anonymous external attacker), must retain the previously issued token, and the target workflow must still exist and have functioning shared credentials. It does not require user interaction or any non-default configuration - the token-reuse-after-removal behavior is inherent to the affected versions. |
| Impact | This is a moderate, context-dependent issue rather than an urgent priority. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N) and score of 5.3 describe a network-reachable, low-complexity flaw requiring low privileges (PR:L) and no user interaction, with low confidentiality and integrity impact (VC:L/VI:L) and no availability impact (VA:N) or scope change to subsequent systems. Critically, PR:L reflects that the attacker must first have been a legitimate collaborator who minted a scoped 'workflow:execute' token - this is a post-access, trust-abuse scenario, not open internet-facing compromise. No EPSS score, CISA KEV listing, POC, or SSVC decision data was provided, so there is no signal of active exploitation or automatable mass exploitation; the realistic threat is targeted abuse by a specific former collaborator rather than widespread attack. The signals are internally consistent (no CVSS-vs-description conflict), but the main aggravating factor not captured in the base score is the long-lived, non-revocable, non-listable token (up to 10-year TTL), which turns a one-time share into indefinite persistent access and is the real reason this warrants prompt patching in affected deployments. |
| Exploit ScenarioDerived | A contractor is granted collaborator access to a Heym workspace and, before their access is revoked, mints a scoped 'workflow:execute' JWT with a multi-year TTL. After the owner removes the share, the former collaborator continues presenting the still-valid token to repeatedly execute the workflow and consume the owner's shared credentials, with no way for the owner to see or revoke the token. No public exploit code is required - only possession of a previously issued token. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 12, 2026
Former collaborators of a Heym workspace can keep running JWT-authenticated workflows after their share is removed, because scoped 'workflow:execute' tokens minted while they still had access remain valid and cannot be listed or revoked by the workspace owner. Heym versions from v0.0.5 up to (but not including) v0.0.113 are affected, matching CPE cpe:2.3:a:heymrun:heym; the issue is an insufficient session expiration flaw (CWE-613) rated CVSS 5.3 with an authenticated-remote vector (CVSS:4.0 PR:L, corroborated by the assessed CVSS:3.1 AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N), so only someone who legitimately held collaborator privileges can abuse it. The token's configurable TTL can extend to roughly ten years, letting the removed collaborator repeatedly trigger the workflow and consume the shared credentials it uses; there is no public exploit identified at time of analysis and no evidence of active exploitation, and no EPSS score was supplied.
RemediationAI
Upgrade Heym to v0.0.113 or later, the boundary at which the affected range ends according to the vendor advisory GHSA-pwr6-6377-3cgv (see also the VulnCheck advisory at https://www.vulncheck.com/advisories/heym-0.0.5-before-0.0.113-broken-access-control-via-workflow-execution-tokens); this is the only complete fix, since the underlying problem is server-side token validation and revocation, not a configuration toggle. Note that upgrading alone may not neutralize already-issued long-lived tokens if the new version does not rotate the signing key, so pair the upgrade with a rotation of the JWT signing secret or an explicit invalidation of outstanding tokens, accepting the side effect that all legitimate collaborators must re-authenticate. Where immediate upgrade is not possible, the highest-value compensating control is to rotate every shared credential that any workflow consumes (API keys, OAuth grants, service accounts, database passwords) so that a replayed 'workflow:execute' token can only trigger a workflow that immediately fails authentication - the trade-off is breaking the workflow until all legitimate consumers are updated with the new secrets. Additionally, audit Heym workflow execution logs for invocations originating from users whose collaboration was removed, and temporarily disable or pause the affected workflows if such activity is observed, accepting a functional outage for that automation. Longer term, avoid granting collaboration shares that require long-TTL workflow:execute tokens, and prefer short-lived tokens re-issued per run, since heym provides no owner-facing token listing or revocation capability in the affected versions.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
Heym issues JSON Web Tokens to collaborators to authorize workflow execution, with the scope claim 'workflow:execute' restricting the token to that single operation. The design flaw is in token lifecycle management rather than in cryptographic validation: revocation is tied to share membership, but the token itself carries a long, configurable expiry (up to ten years) and is not tracked in any owner-visible list, so deleting the collaborator's share does not invalidate the already-issued credential. This is a textbook CWE-613 (Insufficient Session Expiration) condition - the session/credential outlives the authorization context that justified it, and there is no server-side revocation list or key-rotation checkpoint to invalidate it. Because the token is scopable and signed, Heym continues to accept it as a legitimate caller for the target workflow, allowing the former collaborator to invoke the workflow repeatedly and, in doing so, consume any shared credentials or downstream quotas the workflow depends on. The public disclosure is tracked in the GitHub advisory GHSA-pwr6-6377-3cgv and VulnCheck advisory for versions 0.0.5 through before 0.0.113.
Know when Heym gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N
Network-reachable token reuse (AV:N/AC:L) requires a previously authorized collaborator token so PR:L, not PR:N; limited confidentiality/integrity impact from credential reuse and workflow execution, no availability loss.
Primary rating from Vendor (VulnCheck).
CVSS VectorVendor: VulnCheck
Lifecycle Timeline
1DescriptionCVE.org
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.
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Information disclosure occurs when an application unintentionally exposes sensitive data that aids attackers in reconnaissance or directly compromises security.
Authenticated users with workflow create/edit rights on self-hosted Heym deployments prior to 0.0.40 can escape the appl
Sandbox escape in the heym workflow platform before 0.0.91 allows an authenticated user who can author or edit workflow
Python eval()-based remote code execution in Heym (heymrun/heym) before 0.0.53 lets an authenticated user who can edit a
Sandbox escape in Heym's custom Python tool executor (versions before 0.0.21) allows authenticated workflow authors to b
Heym deployments prior to 0.0.53 leave their Telegram webhook endpoints without verification of the X-Telegram-Bot-Api-S
Forged Slack webhook events can trigger Heym workflows with the owner's credentials because Heym before 0.0.53 skips Sla
Non-blind server-side request forgery in heym (heymrun) before 0.0.109 lets any registered user redirect backend HTTP re
Authorization bypass in Heym's workflow execution engine (versions before 0.0.21) allows any authenticated user to run w
Arbitrary file write (and read/delete) in Heym before 0.0.21 lets an authenticated user escape the intended upload stora
Credential exfiltration in Heym before version 0.0.106 allows an authenticated collaborator who has been granted shared
Cleartext storage and over-exposure of multiple capability secrets in Heym, a workflow automation platform, affects all
heym before 0.0.105 fails to enforce credential authorization in its Redis workflow node, letting an authenticated workf
EUVD-2026-97664
GHSA-7v8m-98rf-rgvw
NVD
CVE.org
EPSS
Exploit-DB