Langflow bulk-delete path traversal wipes arbitrary server directories

What is this?

Langflow is a widely deployed open-source platform for building LLM and agent workflows, with a large installed base of internet-exposed instances. The maintainers published a security advisory (GHSA-9whx-c884-c68q) describing a path traversal in the Knowledge Bases API that lets an authenticated user delete arbitrary directories on the server. The flaw affects Langflow 1.8.4 and earlier and is fixed in 1.9.0. It resurfaced in vulnerability-intelligence coverage in July 2026 alongside a broader wave of Langflow and Ollama advisories, which is a good reminder that exposed instances often lag well behind the patched release.

This is a defensive write-up of a disclosed and patched issue. It reproduces no working exploit; the point is the class of bug and how to keep it out of your own code.

How it works

The vulnerability lives in the bulk-delete handler for knowledge bases — the DELETE /api/v1/knowledge_bases endpoint, implemented by the delete_knowledge_bases_bulk function in src/backend/base/langflow/api/v1/knowledge_bases.py.

The root cause is a classic path-traversal pattern (CWE-22). The handler takes a user-supplied list of knowledge-base names and concatenates them directly into a filesystem path, then passes the result to a recursive delete (shutil.rmtree()) — without checking that the resolved path stays inside the intended per-user directory. Other knowledge-base endpoints route through a safe helper (_resolve_kb_path()), but the bulk-delete path bypassed it entirely.

# Vulnerable shape (simplified, illustrative)
for name in kb_names:                 # attacker-controlled
    target = base_dir / name          # no containment check
    shutil.rmtree(target)             # recursive delete outside scope

# A name containing a "../" traversal sequence resolves
# OUTSIDE base_dir, so the delete escapes the user's directory.

Because a name field can carry a ../ traversal sequence, the computed path escapes the sandbox and the recursive delete lands wherever the sequence points — including another tenant’s data or paths elsewhere on the host. No memory corruption, no code execution: just string concatenation feeding a destructive filesystem call.

Why it matters

The scored impact is integrity and availability, not confidentiality — this destroys data rather than reading it. The advisory rates it critical (CVSS 9.6) with a network vector, low attack complexity, and only low privileges required (any authenticated user).

Three consequences stand out. First, cross-tenant blast radius: on a shared multi-user instance, one authenticated account can wipe another tenant’s knowledge-base directories. Second, service disruption and data loss: the delete can remove application files, model caches, configuration, or co-located backups the process can write to, potentially leaving the instance unrecoverable. Third, exposure at scale: Langflow instances are frequently reachable from the internet, and many run behind weak or default authentication, so “authenticated” is a lower bar than it sounds.

The pattern generalizes beyond Langflow. Any API that lets a client name a resource and then maps that name onto the filesystem — for uploads, exports, caches, or deletes — carries the same risk if it trusts the name.

Defenses

The fix and the general lesson are the same: never trust a client-supplied name as a path component, and always confirm the resolved path stays inside its allowed root.

• Upgrade to Langflow 1.9.0 or later. This is the direct remediation. The fix (PR #12243) normalizes the supplied path with Path.resolve() and validates that it starts under the authenticated user’s directory before deleting; a follow-up hardened the check with Path.is_relative_to() to avoid prefix-ambiguity bugs.
• Enforce path containment in your own file APIs. Resolve the candidate path and assert resolved.is_relative_to(base_dir) before any read, write, or delete. Reject names containing separators or traversal sequences outright rather than trying to strip them.
• Run the process with least privilege. A destructive traversal can only reach what the service account can write. Isolate data directories, drop write permissions on application and backup paths, and keep backups off the same filesystem.
• Do not expose the admin/API surface to untrusted networks. Put Langflow behind strong authentication and network segmentation; treat any internet-facing instance as a priority to patch.
• Alert on recursive deletes and traversal signatures. Log knowledge-base delete calls, and monitor for .. sequences or separators in name parameters as a detection signal.

Status

Item	Detail
Affected	Langflow ≤ 1.8.4
Fixed in	Langflow 1.9.0
Weakness	CWE-22 (Path Traversal), integrity/availability impact
Severity	Critical, CVSS 9.6 (AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:H)
Reference	CVE-2026-42048 · GHSA-9whx-c884-c68q
Disclosure	Advisory published Apr 27, 2026; renewed coverage July 2026

The upstream fix requires no proprietary tooling — upgrade to 1.9.0, apply path containment in any file-handling endpoint you own, and scope the service account so a traversal has nothing valuable to destroy.