Langflow OSS CVE-2026-18894

Exploitation requires a public workflow on the Langflow OSS server that already contains stored Python component code; the attacker does not inject new code but triggers this pre-existing component through a public execution path, which is supposed to be limited to server-trusted component code. The concrete prerequisite is therefore an exposed Langflow instance (versions 1.0.0 through 1.12.4) hosting at least one publicly accessible flow that embeds a Python component. The limiting factor is this deployment shape: instances with no public workflows, or no Python components in public flows, do not present the trigger. The CVSS vector indicates no authentication (PR:N) and no user interaction (UI:N) are required to invoke the public path. The code runs under the flow owner's runtime context within the server process, so impact scope is tied to that account's privileges.

Signals conflict and must be weighed carefully. The input CVSS of 9.8 (AV:N/AC:L/PR:N/UI:N, C:H/I:H/A:H) frames this as a critical remote, unauthenticated, low-complexity RCE, and the vuln.today Decision label is act_now with a patch already available from IBM - both arguing for urgent remediation. Against that, the CISA SSVC framework reports Exploitation: none (no observed exploitation) and Technical Impact: partial (not total), while flagging Automatable: yes. No EPSS score, no CISA KEV listing, and no PoC reference were supplied. The honest read: exploitation status is 'no public exploit identified at time of analysis,' so the act_now urgency rests on the combination of critical technical severity, the Automatable:yes signal, and an available fix - not on evidence of in-the-wild activity. The SSVC 'partial' technical impact is in tension with the CVSS C:H/I:H/A:H triad; resolve in favor of treating this as a genuine priority because the flaw bypasses an intended trust boundary to run Python under the flow owner's context, but note that real-world exposure depends on the precondition below rather than being universal. This is a real priority for anyone running an affected, publicly exposed Langflow instance, not merely a high-CVSS-but-low-real-risk issue - though the absence of exploitation and PoC data means it is not a confirmed emergency in the field.

A remote attacker reaches a publicly exposed Langflow OSS instance (1.0.0-1.12.4) and invokes a public workflow that already contains a stored Python component. Because the public execution path fails to restrict execution to server-trusted component code, the attacker triggers that pre-existing Python to run inside the server process under the flow owner's runtime context, achieving code execution. No public exploit code or PoC reference was provided in the input.