Three confirmed-exploited vulnerabilities across two AI-focused development platforms — Langflow's agent-workflow builder and Marimo's reactive Python notebook — share a root cause that has nothing to do with machine learning itself: each platform ships a feature designed to execute arbitrary code by design, and each one shipped that feature with a gap in the authentication supposed to gate it.
| CVE | CVSS | Component | Added to KEV |
|---|---|---|---|
| CVE-2026-33017 | 9.8 | Langflow build_public_tmp endpoint | 25 Mar 2026 |
| CVE-2026-39987 | 9.8 | Marimo terminal WebSocket endpoint | 23 Apr 2026 |
| CVE-2025-34291 | 8.8 | Langflow CORS + refresh-token cookie | 21 May 2026 |
Why "code execution is the product" makes authentication the only real control
Langflow and Marimo both exist to run user-authored code — that's the entire value proposition of an agent-workflow builder and a reactive notebook, respectively. Neither can sandbox that execution away without breaking its core function, which means authentication and authorization aren't one control among several; they're effectively the only thing standing between a legitimate user's workflow and an attacker's arbitrary command. When that single control has a gap, the result is close to worst-case by construction, and both CVE-2026-33017 and CVE-2026-39987 land at the maximum practical severity score for exactly this reason.
CVE-2026-33017 is precise about the mechanism: Langflow's POST /api/v1/build_public_tmp/{flow_id}/flow endpoint is intentionally unauthenticated, because it exists to let public flows run without a login. But when an optional data parameter is supplied, NVD's description states the endpoint "uses attacker-controlled flow data (containing arbitrary Python code in node definitions) instead of the stored flow data from the database" and passes it to exec() "with zero sandboxing" — an unauthenticated attacker doesn't need to compromise anything; they simply supply their own malicious flow definition to a URL that was never meant to require a credential in the first place, and it runs. Notably, NVD explicitly distinguishes this from CVE-2025-3248, an earlier Langflow RCE that Langflow's own team had already fixed by adding authentication to a different endpoint — meaning the same organization patched one hole in this same class of bug and left an adjacent one open in a companion endpoint designed with the opposite authentication assumption.
CVE-2026-39987 in Marimo follows the identical structural pattern in a different product: the /terminal/ws WebSocket endpoint provides full PTY shell access, and per NVD, unlike other WebSocket endpoints that "correctly call validate_auth()," this one "only checks the running mode and platform support before accepting connections, completely skipping authentication verification." Two unrelated vendors, in two unrelated products, both shipped one authenticated code-execution endpoint alongside one unauthenticated twin that inherited none of the protecting logic.
Why the CORS chain is a different failure mode worth tracking separately
CVE-2025-34291 doesn't skip authentication — it defeats it through browser trust boundaries instead. Langflow's CORS configuration allowed any origin (allow_origins='*') while also allowing credentials, combined with a refresh-token cookie set to SameSite=None. NVD's description lays out the resulting chain plainly: "a malicious webpage to perform cross-origin requests that include credentials and successfully call the refresh endpoint," obtaining a victim's fresh access and refresh tokens, which then unlock the platform's own built-in code-execution functionality. This is a browser-security misconfiguration, not a missing-auth-check bug, and it demonstrates that Langflow's exploited-in-the-wild history in this period includes two structurally distinct classes of failure against the same underlying asset — code execution — within a matter of months.
What to check this week
Upgrade Langflow past 1.9.0 and past 1.6.9 to close both CVE-2026-33017 and CVE-2025-34291 respectively — these are two separate fixes in two separate releases, so confirm your deployed version clears both thresholds rather than assuming one patch covers both.
Upgrade Marimo to 0.23.0 or later, and in the interim, restrict network access to any Marimo instance's WebSocket endpoints to trusted hosts only.
Audit CORS configuration on any self-hosted AI development or notebook platform for the specific combination of wildcard origins plus credentialed requests — this pairing is what turns an ordinary CORS misconfiguration into an account-takeover chain.
Treat any endpoint explicitly designed to be unauthenticated as a priority code-review target, since both Langflow's public-flow endpoint and Marimo's terminal endpoint were built to skip authentication for a legitimate reason and then failed to properly scope what that skip allowed.
A closing note on the pace of AI tooling exploitation
Both Marimo's and Langflow's most recent CVEs moved from disclosure to confirmed exploitation extremely quickly — one referenced source describes Marimo's RCE going from disclosure to exploitation in under 10 hours — reflecting how fast attackers now scan for and weaponize bugs in the rapidly growing population of self-hosted AI development platforms.
A final consideration on self-hosted AI tooling exposure
Organizations standing up Langflow, Marimo, or similar AI agent and notebook platforms internally should default to network-level isolation for these tools rather than direct internet exposure, given that both platforms' core value proposition — arbitrary code execution on demand — makes any authentication gap catastrophic almost by definition.
How Safeguard helps
Safeguard's continuous inventory extends to the growing category of self-hosted AI development and orchestration platforms, flagging code-execution-capable tools like Langflow and Marimo for the same network-exposure scrutiny applied to any other high-privilege internal system.
