CVE-2026-93674: IBM Langflow OSS 1.0.0 through 1.12.2 is vulnerable to remote unauthenticated code execution via OS command injection.

Langflow OSS through 1.12.2 exposes POST /api/v1/validate/code, a "validation-only" endpoint whose backend (lfx.custom.validate.validate_code) calls importlib.import_module() on every import statement found in attacker-supplied code. Importing a module executes its top-level code, so the endpoint runs arbitrary Python inside the Langflow server process during what is documented as a non-executing validation step. Combined with (a) the default single-user configuration (LANGFLOW_AUTO_LOGIN=true, which lets any network client mint a superuser token from GET /api/v1/auto_login with no credentials) and (b) a second remote code-evaluation sink (POST /api/v1/custom_component, which exec()s the attacker-supplied component class body and can plant a malicious module into the server-writable site-packages), a remote unauthenticated attacker obtains arbitrary OS command execution as the Langflow service user. The vulnerability is fixed in Langflow 1.12.3 by commit 461506ac2f38f70a994b5140572b876448c11e4c ("fix(security): close pathlib/io/codecs scanner bypass and stop validate_code from executing imports", H1-3992099 / LE-2683), which replaces import_module() with importlib.util.find_spec() — locate-only, never executing module code.

• Package/component: langflow / langflow-base / lfx (PyPI), specifically lfx.custom.validate.validate_code behind the FastAPI route POST /api/v1/validate/code.
• Affected versions: 1.0.0 through 1.12.2 (IBM bulletin / NVD CPE range; the vulnerable importlib.import_module() loop is present in v1.12.2 and removed in v1.12.3).
• Risk level: Critical (CVSS 9.8, AV:N/AC:L/PR:N/UI:N). Full remote, unauthenticated OS command execution with the privileges of the Langflow service account (in the official container: uid=1000(user) gid=0(root)), i.e. complete compromise of flows, stored credentials/global variables, and any data readable by the service.

Impact Parity

• Disclosed/claimed maximum impact: remote (unauthenticated) arbitrary code / OS command execution (code_execution).
• Reproduced impact from this run: remote unauthenticated OS command execution through the real HTTP API of the digest-pinned official langflowai/langflow:1.12.2 image: the planted module ran id via subprocess.check_output(..., shell=True) inside the server process; the output (uid=1000(user) gid=0(root) groups=0(root)) was exfiltrated in-band in the HTTP 500 detail field of the very POST /api/v1/validate/code response, and a unique per-attempt marker file was written inside the container filesystem.
• Parity: full.
• Not demonstrated: nothing material — the claimed impact class was reproduced end-to-end. (A persistent shell/pivot was not attempted; it is not required for parity.)

Root Cause

src/lfx/src/lfx/custom/validate.py (v1.12.2), function validate_code(code):

# Evaluate the import statements
for node in tree.body:
    if isinstance(node, ast.Import):
        for alias in node.names:
            try:
                importlib.import_module(alias.name)   # <-- EXECUTES module top-level code
            except ModuleNotFoundError as e:
                errors["imports"]["errors"].append(str(e))

importlib.import_module() is not a lookup — it loads and executes the module. Because the endpoint is reachable by any network client under the default LANGFLOW_AUTO_LOGIN=true configuration (the auto-login route issues a superuser JWT without credentials), an attacker who can place a Python file on any sys.path entry writable by the service account gets it executed by simply sending {"code": "import <module>"}. The official container runs as uid=1000 and owns /app/.venv/lib/python3.14/site-packages, which is on sys.path, so the built-in custom-component code-evaluation feature (POST /api/v1/custom_component → build_custom_component_template() → exec() of the class body) provides the file-write primitive fully remotely:

class Planter(CustomComponent):
    _w = pathlib.Path("/app/.venv/lib/python3.14/site-packages/<mod>.py").write_text(payload)

The planted module both writes a unique marker file and raises RuntimeError("PLANTED_EXEC:<token>:" + subprocess.check_output("id", shell=True)). validate_code only catches ModuleNotFoundError, so the RuntimeError propagates to the route handler, which returns HTTP 500 with detail=str(e) — exfiltrating the command output directly in the HTTP response.

In 1.12.3 the same request path performs importlib.util.find_spec(alias.name.split(".")[0]) and never executes module code; the identical attacker procedure therefore produces HTTP 200, empty errors, and no marker file.

• Fix commit: 461506ac2f38f70a994b5140572b876448c11e4c (fix(security): close pathlib/io/codecs scanner bypass and stop validate_code from executing imports, PR #15201, H1-3992099 / LE-2683).
• Fixed release: Langflow OSS 1.12.3 (git tag v1.12.3 = fec71dca901949c09ed4d63315804337cd2eb13d).

Note on CVE mapping: the IBM bulletin for 1.12.3 lists 25 CVEs without per-CVE commit mapping. CVE-2026-93674 is the 9.8 PR:N CWE-94 ("code injection / OS command") entry; the validate_code import-execution sink fixed by 461506ac2f is the matching unauthenticated remote code-execution fix in the 1.12.3 security train. The public third-party PoC (rmhowe425/POC-CVE-2026-93674) targets the MCP stdio endpoint (/api/v2/mcp/servers), which corresponds to the earlier GHSA-w794-rj3p-xv45 / CVE-2026-105697 fix (1.10.3) — that allowlist is already present in 1.12.2, so the MCP path is not the 1.12.2→1.12.3 divergence; the validate/code path is.

Reproduction Steps

1. bundle/repro/reproduction_steps.sh (self-contained; requires docker, curl, jq).
2. The script:
   • Pulls/pins the official images by digest: vulnerable langflowai/langflow@sha256:79c02794adebe82d756b7152ce4feebe4a5426e1faf3fe5b5d0dd08f304510c4 (v1.12.2) and fixed langflowai/langflow@sha256:34055a07d446de51760e28dab6332e22624e5f48dca611567779992fc32c5ec0 (v1.12.3).
   • Starts two fresh vulnerable containers and two fresh fixed containers (LANGFLOW_AUTO_LOGIN=true, the OSS package default), waiting for /health.
   • Per attempt: (1) GET /api/v1/auto_login with no credentials → superuser JWT; (2) POST /api/v1/custom_component plants pruva_planted_<run>_<n>.py into site-packages via class-body exec(); (3) POST /api/v1/validate/code {"code":"import <module>"} triggers the vulnerable import execution; the marker file is read back out of the container.
   • Vulnerable pass criteria: HTTP 500 + PLANTED_EXEC:<token>:uid=1000(user)... in the response body + marker file containing the unique token inside the container. Fixed pass criteria: HTTP 200, empty errors, no marker.
3. Expected evidence: 2/2 vulnerable attempts execute attacker code; 2/2 fixed attempts do not (identical procedure, plant still succeeds on fixed — proving the divergence is exactly the validate/code import execution).

Evidence

• Driver log: bundle/logs/reproduction_steps.log
• Image identity: bundle/logs/repro/image_identity.txt
• Per-attempt artifacts ({vuln,fixed}_attempt_{1,2}_* under bundle/logs/repro/attempts/): auto-login token responses, plant requests/responses, trigger requests/responses, planted module content, marker files, container logs. All SHA-256-bound in bundle/repro/runtime_manifest.json.
• Key excerpt (vulnerable, both attempts): POST /api/v1/validate/code → HTTP=500, body {"detail":"PLANTED_EXEC:PRUVA-CVE-2026-93674-<run>-VULN-<n>:uid=1000(user) gid=0(root) groups=0(root)"}, and marker.txt = PRUVA-CVE-2026-93674-<run>-VULN-<n> uid=1000(user) gid=0(root) groups=0(root).
• Key excerpt (fixed, both attempts): identical requests → HTTP=200, body {"imports":{"errors":[]},"function":{"errors":[]}}, empty marker file.
• Environment: Docker on Linux x86_64; images digest-pinned as above; Python 3.14 inside the container; LANGFLOW_AUTO_LOGIN=true (package-level default; the image sets it to false, which only changes the bootstrap to credential-based login — the validate/code sink itself is identical).

Recommendations / Next Steps

• Upgrade to Langflow OSS 1.12.3 or later (IBM/vendor guidance; the fix replaces import_module() with find_spec() in validate_code).
• Until upgraded: do not expose Langflow to untrusted networks; set LANGFLOW_AUTO_LOGIN=false and strong superuser credentials (raises the bar to authenticated, but the sink still executes for any authenticated user on ≤1.12.2); restrict file-system write access of the service account to site-packages.
• Defense-in-depth: treat every "validation" endpoint as non-executing (audit for other import_module/exec uses on request paths), and consider read-only root filesystems / non-root containers.
• Testing: regression test that POST /api/v1/validate/code with an import of a planted module never executes it (covered upstream by the lfx-side tests added in the fix commit).

Additional Notes

• Idempotency: the script is fully idempotent — each attempt uses a fresh, uniquely-named container and a unique module/marker name, and a trap removes all containers on exit. Re-running produces fresh unique tokens/markers.
• Repeatability: the exploit ran twice per side (two fresh vulnerable processes, two fresh fixed processes) with identical outcomes.
• Why two stages: the CVE sink (validate_code import execution) requires an importable attacker module. The plant uses Langflow's built-in custom-component code-evaluation feature, which behaves identically on 1.12.2 and 1.12.3 — the vulnerable/fixed divergence is isolated entirely to the validate_code step, which is what the 1.12.3 fix changed.
• Limitations: none affecting the verdict. The reproduction uses the official vendor images at the exact vulnerable/fixed digests; no sanitizers, mocks, or instrumentation were used.