Eight Heym CVEs Landed at Once — and the Oldest Was Patched Three Months Ago

2026-09-27 AI Vulnerabilities & CVEs by al-ice.ai Editorial

In the early hours of 27 September 2026, the National Vulnerability Database published eight CVE records — CVE-2026-100858 through CVE-2026-100865 — all against Heym, the self-hosted agentic workflow platform from heymrun (around 1,300 GitHub stars, Python, MCP-native). All eight are still marked Received. And all eight describe bugs that were already fixed, in releases dating back as far as 26 June 2026.

That is the story worth reading first. The two highest-severity records in the batch, both scored 8.8 CVSS v3.1 / 8.7 CVSS v4.0, point at patches in 0.0.53 (June) and 0.0.91 (15 August). The newest, CVE-2026-100858, points at 0.0.109, released 12 September. The project is on 0.0.117 as of 26 September and ships a release roughly every day or two. A shop that upgrades regularly was never exposed to most of this. A shop that pinned a version in July and waited for a CVE to justify the upgrade ticket has been running known-vulnerable code for three months with nothing in its scanner to show for it.

Two authenticated RCEs, both in the expression layer

CVE-2026-100864 (8.8, patched in 0.0.91, advisory GHSA-87x2-9jwx-7gh4) is a sandbox escape in Heym's expression engine. Per the NVD record, the DotList map/filter construct and the fallback resolver permit dunder attribute access through item expressions, reaching os.system and executing commands as the backend process user. GitHub's advisory lists affected versions as <= 0.0.90.

CVE-2026-100865 (8.8, patched in 0.0.53, GHSA-pm6h-x3h5-j38h) is a bundle of five distinct issues in versions <= 0.0.52, and it is the most instructive record in the set. The workflow condition evaluator used Python eval() with no effective sandbox, so anyone who could edit a branch node — or who could get a workflow template imported — got arbitrary Python on the backend. Slack webhook signature verification and Telegram secret-token verification both failed open when the trigger node had no credential ID or an empty signing secret, so knowing the public webhook URL was enough to run workflows with the owner's credentials. The OAuth authorization endpoint did not validate the redirect_uri scheme, making javascript: and data: redirects into stored XSS in the Heym origin — including access to the victim's HttpOnly auth cookie. And execution tokens, portal sessions, HITL public tokens, and OAuth authorization codes were all stored in plaintext.

The template-import path deserves emphasis. Most authenticated-RCE findings in agent platforms assume an attacker who already has an editor account. Here the same code executes when a user imports a shared workflow — the agent-ecosystem equivalent of the poisoned-package problem this site has tracked through a placeholder domain serving ClickFix to agent skills and MCP docs and Deadbugz's runtime MCP tool poisoning. Workflow templates are executable content. They are shared like configuration.

The SSRF guard exists. Four nodes never called it.

Four records in the batch are the same bug wearing different hats, and together they make an unusually clean case study in partial mitigation.

Heym has a working SSRF egress guard in app/services/ssrf_guard.py. CVE-2026-100858 (6.8 v3.1 / 7.6 v4.0, fixed in 0.0.109) says the Slack, Discord, and Crawler nodes issued HTTP requests to URLs taken from user-created credentials (webhook_url, flaresolverr_url) with an unguarded HTTP client — "bypassing the SSRF egress guard that already protects the HTTP, WebSocket, and MCP nodes." The credential API validated only that the URL was non-empty. Any registered user could point a credential at loopback, RFC1918, link-local, or cloud-metadata addresses and read the response back as workflow output. GitHub's advisory rates it High (7.4) against versions <= 0.0.107.

CVE-2026-100861 and CVE-2026-100863 (both 5.0) are the same omission in integration services with credential-supplied base URLs and in the LLM image-edit input loader, where _load_image_bytes fetched caller-controlled URLs with a bare httpx.get behind nothing but a scheme check. Because the workflow DSL supports "imageInput": "$userInput.body.imageUrl", a plain webhook caller — not an authenticated editor — chooses the fetch target whenever a workflow author uses that expression. And this is a repeat: CVE-2026-84207, published 1 September, was the identical gap in the WebSocket Send and WebSocket Trigger nodes, fixed in 0.0.98.

That is five separate SSRF CVEs across four months in one codebase that has a functioning egress guard. The guard is not the control; calling the guard from every outbound path is the control, and there is no structural enforcement that new nodes do so. It is the same failure mode as n8n-mcp's IPv4-mapped-IPv6 egress bypass — an allowlist that is only as good as its least-integrated caller.

Credentials that leave by the front door

CVE-2026-100859 (6.5 v3.1 / 7.1 v4.0, fixed in 0.0.106) is the one to check your logs for. The POST /api/credentials/test endpoint let a collaborator with shared credential access override the destination URL in the config parameter, causing the server to send the decrypted secret to an attacker-chosen endpoint. Shared-credential access in most teams is a routine grant; it is not supposed to mean "can read the plaintext." Here it did, with a single API call and no exploit chain.

CVE-2026-100860 (5.5, fixed in 0.0.105) is an authorization fail-open in the Redis node. When _get_accessible_credential returned None — because the credential did not exist or because the caller was not authorized to use it — the node treated the lookup failure as an empty config and fell back to defaults, connecting to localhost:6379 with no password and running the requested operation there. An authorization denial became a connection to the platform's own backing store. That is the same anti-pattern as DBHub's read-only mode being dead code: a check whose result nobody consumed.

CVE-2026-100862 (4.9 v3.1 / 6.9 v4.0, fixed in 0.0.91) inventories what Heym stored in cleartext before that release: webhook header-auth values (returned by GET /api/workflows/{id} and written unsanitized into execution history), MCP API keys (plaintext column, returned in config and list responses, and accepted via a ?key= query string so they leak into logs, proxies, and Referer headers), portal session tokens validated by plaintext equality with a 168-hour TTL, full workflow execution JWTs re-listed by the execution-tokens endpoint, Discord interaction tokens, and global variables. The MCP key in a query string is the detail with the longest tail — that secret is now in your reverse-proxy access logs, and rotating it is the only fix that matters.

What to do

Upgrade to 0.0.109 or later; 0.0.117 is current. That single step clears all eight records. There is no partial-fix decision tree here — the remediation floors are 0.0.53, 0.0.91, 0.0.98, 0.0.105, 0.0.106, and 0.0.109, and the newest one dominates.
Rotate every secret the platform has held, and treat MCP API keys as burned. If you ran anything below 0.0.91, MCP keys travelled in URLs. Grep your proxy and application logs for ?key= before you assume otherwise, then rotate regardless.
Review shared-credential grants and execution history. CVE-2026-100859 turns collaborator access into secret exfiltration; CVE-2026-100862 means execution history may itself contain cleartext auth values. Both argue for purging old history, not just patching.
Audit imported workflow templates against the 0.0.53 condition-evaluator bug. If your instance predates that release and ever imported a third-party template, the RCE path did not require an attacker with an account.
Egress-filter the backend, not just the nodes. Five SSRF CVEs in four months say the application-layer guard will keep being missed by the next integration. Block loopback, RFC1918, link-local, and the cloud metadata endpoint at the network boundary and enforce IMDSv2.
Stop letting CVE publication set your upgrade cadence. This batch is a three-month backlog arriving in one morning — the same advisory-to-CVE lag documented in OpenClaw's 72-CVE day. On fast-moving agent platforms, track the vendor's security advisories and release notes directly.

Sources: