15 New Python Vulnerabilities - 15 High Severity, None With POC

Non-blind server-side request forgery in heym (heymrun) before 0.0.109 lets any registered user redirect backend HTTP requests to loopback, private, link-local, or cloud-metadata addresses and read the full response body in the workflow node output. The flaw is confined to the Slack, Discord, and Crawler workflow nodes, which build requests from user-supplied credential URLs (webhook_url / flaresolverr_url) with an unguarded HTTP client that bypasses the SSRF egress guard already enforced on the HTTP, WebSocket, and MCP nodes. No public exploit code or confirmed active exploitation was identified at time of analysis, but exploitation requires only a valid account (PR:L) on an affected instance and no user interaction; the fixed release is 0.0.109.

Credential exfiltration in Heym before version 0.0.106 allows an authenticated collaborator who has been granted shared access to a credential to cause the server to transmit the credential owner's decrypted secret to an attacker-controlled endpoint. The flaw lives in the POST /api/credentials/test endpoint, where the destination URL supplied in the config parameter is not validated, so a low-privileged collaborator can redirect a credential-verification request (CWE-918 server-side request forgery) and harvest plaintext secrets they were never entitled to read. The vendor CVSS 4.0 assessment (7.1, AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N) confirms high confidentiality impact with no integrity or availability effect, and no public exploit code or confirmed in-the-wild exploitation has been identified at time of analysis; risk is concentrated in multi-user, self-hosted deployments that rely on collaborator sharing, while single-user instances are not meaningfully exposed.

Cleartext storage and over-exposure of multiple capability secrets in Heym, a workflow automation platform, affects all versions prior to 0.0.91 and allows anyone with read access to a workflow, share/team membership, or read access to the database, a backup, or logs to recover and replay those secrets to execute workflows or act as the secret owner. Exposed values include webhook header-auth credentials returned in cleartext by GET /api/workflows/{id} and persisted into execution history, MCP API keys stored as a plaintext column and accepted via a ?key= query string that leaks into logs, proxies, and Referer headers, portal session tokens validated by plaintext equality with a 168-hour TTL, workflow execution JWTs re-listed by GET .../execution-tokens, Discord interaction tokens, and global variables. The vendor CVSS 4.0 score is 6.9 (medium) with a high-privilege prerequisite (PR:H), our independent assessment scores it CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N, exploitation is bounded by the need for prior authorized read access rather than a special configuration, a vendor patch is available in 0.0.91, and no public exploit was identified at time of analysis.

heym before 0.0.105 fails to enforce credential authorization in its Redis workflow node, letting an authenticated workflow author cause the node to fall back to unauthenticated defaults on the backend's loopback interface. When the credential lookup returns no accessible credential - because the ID does not exist, was deleted, or belongs to another user - the node treats the failure as empty configuration and connects to localhost:6379 with no password, executing the requested Redis operation there. The impact is deployment-gated: the stock docker-compose.yml ships no Redis, so default installs only surface a misleading connection error, while operators who have placed a passwordless Redis on loopback face unauthorized read/write access; no public exploit has been identified at time of analysis and no EPSS or KEV signal is available.

SSRF protections can be bypassed in heym before 0.0.105 by authenticated users who configure integration service credentials with base URLs pointing to internal or cloud-metadata addresses, enabling them to read internal service responses through workflow node output. This moderate-severity issue requires low-privileged authentication and has no public exploit identified at time of analysis.

Server-side request forgery in Heym 0.0.90 and earlier lets a caller-controlled workflow input steer an outbound HTTP fetch to loopback, RFC1918, link-local, or cloud metadata endpoints such as 169.254.169.254. Two distinct egress gaps exist: the LLM image-edit loader (_load_image_bytes) issues a bare httpx.get that skips the egress-pinning client, and _is_public_address only unwraps IPv4-mapped IPv6, so NAT64 (64:ff9b::/96), IPv4-compatible (::x.x.x.x), and 6to4 (2002::/16) encodings can smuggle internal IPv4 destinations past both URL validation and the dial-time IP pin. Exploitation is not automatic: an authenticated workflow author must have deliberately wired a caller-controlled expression such as "imageInput": "$userInput.body.imageUrl" before an unauthenticated webhook or API caller can pick the target, and this is best treated as a low-to-medium priority SSRF issue; no public exploit code was identified at time of analysis. The second, IPv6-based gap additionally depends on the Python 3.11.0 through 3.11.9 behavior that classifies 6to4 as globally routable.