Heym before version 0.0.53 contains multiple independent weaknesses that allow an attacker to execute arbitrary Python code on the backend process, bypass authentication for webhook triggers, exploit weak OAuth redirect handling, and exfiltrate sensitive bearer tokens. The use of Python eval without sandboxing directly enables remote code execution, exposing the system to full compromise. Webhook endpoints that do not validate signing secrets or credential identifiers permit unauthorized workflow execution, providing a foothold for privilege escalation. Likewise, an insecure OAuth redirect_uri validation allows a malicious website to retrieve an authorization code and inject client‑side JavaScript into the Heym origin, potentially accessing HttpOnly authentication cookies. Plaintext storage of workflow and OAuth tokens creates a secondary vector where database exposure results in immediate, scoped access to the application.

The vulnerabilities affect all instances of the Heym application running any release before 0.0.53, including versions 0.0.0 through 0.0.52. Users of these versions should verify the application level and any custom workflow definitions for the exposed conditions and webhook configurations.

The CVSS score of 8.7 indicates high severity, and while the EPSS score is not available, the lack of a KEV listing suggests the vulnerability has not yet been widely exploited. Based on the description, the likely attack vector is a remote actor who can create or modify a workflow, import a malicious workflow template, or simply know a public webhook URL. Such an attacker can trigger the vulnerable code paths, leading to arbitrary code execution or impersonation of the backend process user. The risk is amplified by the permissive authentication bypass and the fact that exposed tokens have a 168‑hour TTL, allowing extended misuse if database defenses are weak.