Heym EUVD-2026-98740

Requires an authenticated account on a Heym instance prior to 0.0.40 with permission to create or edit a workflow that contains an Agent custom Python tool; the attacker's tool code must reference operating-system/process/filesystem functionality through public attributes of standard-library modules that are on the allowlist, so that it survives _safe_import() and _validate_code_safety() before being run via exec(). Reachability is broadened when self-registration is enabled (an attacker can obtain the needed low-privilege account), but merely triggering a workflow from the portal is insufficient - the attacker must control the tool's Python source. Exploitation is limited by: needing workflow create/edit rights, needing the account itself (closed instances with only trusted users reduce exposure), and being fully mitigated by upgrading to 0.0.40 where tool code runs in a hardened Docker sandbox (default 'auto' mode fails closed if Docker is absent).

This is a genuine high-priority issue in the context of any multi-user deployment, but the real-world blast radius is constrained by product footprint rather than by exploit difficulty. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H, base 8.8) is internally consistent with the description: exploitation is network-reachable through the workflow editor, low-complexity (a deterministic blacklist bypass using public attributes of allowed standard-library modules), and requires only a low-privileged authenticated account (PR:L) that can create or edit a workflow containing an Agent custom Python tool - no user interaction. The outcome is full code/command execution as the backend application user, justifying C:H/I:H/A:H. No EPSS score, CISA KEV listing, or public proof-of-concept was provided in the input, so there is no public exploit identified at time of analysis and no evidence of active exploitation; the probability of opportunistic mass exploitation is therefore low, driven mainly by the product's small deployment base rather than by any mitigating technical factor. The description's note that 'self-registration affects reachability, but portal triggering alone does not grant code control' is an important nuance: if self-registration is enabled, the PR:L barrier is effectively lowered to anyone who can register, pushing real risk higher for internet-exposed instances; conversely, on a closed instance with trusted users only, the practical risk is lower. Net assessment: technically a reliable authenticated-to-RCE sandbox escape that should be patched promptly where deployed, but not a widespread internet-scale threat given the niche product.

An authenticated low-privileged user (or, where self-registration is enabled, an attacker who simply signs up) opens the workflow editor and defines an Agent custom Python tool whose code reaches operating-system, process, or filesystem capabilities via public attributes of allowed standard-library modules, slipping past the blacklist checks in _safe_import() and _validate_code_safety(). When the tool runs, the backend executes it with exec(), giving the attacker arbitrary command and file operations as the backend application user. No public exploit code was identified in the provided data, but the blacklist bypass is low-complexity and deterministic over the network.