Database/AI/ML frameworks & serving
Langflow: incomplete filtering of Docker volume and device arguments exposes host files from a flow
Impact
Langflow's filtering of arguments passed to Docker-based MCP servers misses dangerous volume-mount and device-mapping options, so an authenticated user who can build or edit a flow can mount arbitrary host paths - or map host devices - into the container it launches and then read or modify them. On a GPU node that reaches the kubelet and container runtime sockets, service-account tokens, model and dataset volumes, and the accelerator device nodes themselves, which is a path out of the Langflow tenant and onto the node. Anywhere Langflow is offered to more than one team, its own login is the only thing standing between a user and host filesystem access. Affects 1.0.0 through 1.10.3.
Who can reach it
An authenticated Langflow user with permission to create or modify flows that configure a Docker-based MCP server. No host access is needed beforehand; the Langflow service account's Docker access is what gets abused.
What to do
Apply the fix referenced in IBM's bulletin for Langflow OSS - the record states the issue spans 1.0.0 through 1.10.3 but names no fixed version, so take the version from the IBM page rather than assuming one - and restart the Langflow service. As a mitigation, deny Langflow access to the Docker socket, run it without privileges to create containers, and restrict flow-authoring permissions to trusted users.
References
Related entries
- OpenShift AI training-operator: namespace edit/admin users escalate to host filesystem access via crafted training jobsCVE-2026-18982 · Red Hat OpenShift AI training-operator (ClusterRole aggregation + PodTemplateSpec passthrough)High
- vLLM (HF `auto_map`): Loads Hugging Face dynamic modules during model resolutionCVE-2026-22807 · vLLM (HF `auto_map`)High
- PyTorch (`weights_only` unpickler): Bypass of the `weights_only` allowlistCVE-2026-24747 · PyTorch (`weights_only` unpickler)High
- vLLM (hardcoded `trust_remote_code`, second instance): Same class, two more model files, through 0.18.0CVE-2026-27893 · vLLM (hardcoded `trust_remote_code`, second instance)High
- JupyterHub OAuthenticator: Authenticated user bypasses the intended identity checkCVE-2026-33175 · JupyterHub OAuthenticatorHigh
- LiteLLM (`/config/update`): Endpoint does not enforce admin authorizationCVE-2026-35029 · LiteLLM (`/config/update`)High
This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.