IBM Discloses 25 Langflow Vulnerabilities Including a Dependency-Confusion Flaw

Twenty-five flaws in one advisory

IBM has published a security bulletin covering 25 vulnerabilities in Langflow OSS, the open-source workflow platform, with every one of them affecting versions 1.0.0 through 1.12.2. According to a write-up on dev.to, two of the flaws are rated critical, nineteen high and four medium, and fifteen of them could result in code execution.

Most of the batch consists of conventional application bugs — injection, sandbox escapes, weak input filtering — but one entry stands out because the weakness sits in the supply chain rather than in the application's own code.

The dependency-confusion outlier

CVE-2026-93675, scored 8.8 on the CVSS scale, is a dependency-confusion issue. Dependency confusion targets package resolution itself: it abuses the way a resolver decides which source wins when the same package name exists in more than one place. An attacker who publishes a package under a name a build system expects from elsewhere can trick that build into pulling in hostile code.

According to the dev.to write-up, the flaw requires no authentication, though a user must take some action for it to be triggered. That human-in-the-loop requirement keeps it below the critical tier, but the end result is still untrusted code running inside the platform.

Two critical injection bugs

The critical entries are of a different character. CVE-2026-104334 stems from improper control of code generation, while CVE-2026-93674 involves improper neutralization of special elements in an operating-system command. Both can reportedly be exploited with no login and no user interaction, which is what separates them from the dependency-confusion flaw despite the similar destination.

Flaws behind the login

The remaining vulnerabilities mostly affect users who are already authenticated. CVE-2026-97655 gets around an incomplete blocklist in Langflow's code security scanner, CVE-2026-97676 provides a sandbox escape, and CVE-2026-93447 exploits deserialization of cached Redis values — although that last one requires the server secret along with write access to Redis, which narrows the pool of would-be attackers considerably.

No signs of active exploitation

IBM's advisory does not report exploitation in the wild, and no public proof-of-concept has been confirmed, according to the dev.to write-up. The absence of a public exploit does not make the batch low risk, however, given how many of the flaws end in code execution.

What operators should do

Remediation is simple in principle: upgrade to Langflow 1.12.3, which IBM strongly recommends doing promptly. Until the upgrade lands, the dev.to write-up advises keeping Langflow instances off the public internet and restricting who is allowed to create or edit flows. After patching, operators should rotate any API keys and credentials stored in the platform, since secrets reachable from a compromised instance cannot be assumed safe.

Why it matters

A platform that resolves packages at build time inherits the risks of the entire package ecosystem behind it. The dependency-confusion entry in this batch makes the point concrete: even a fully patched application can pull in attacker-controlled code if dependency resolution is left unguarded. For Langflow operators, upgrading is necessary but not sufficient — dependencies should also be pinned to exact versions and drawn from verified sources. More broadly, the batch is a reminder that workflow and agent platforms are attractive targets: they execute code, hold credentials, and often sit more exposed than their operators realize.