CVE-2026-10128

This vulnerability lets any authenticated Langflow user read arbitrary environment variables from the host system. That's not a theoretical risk — it's a direct path to every secret injected into your deployment: API keys, database credentials, service tokens, cloud auth tokens. If you're running Langflow 1.0.0 through 1.10.3, your entire secret surface is exposed to any user who can log in. The CVSS 6.5 'medium' score is misleading. In a flow-builder, 'authenticated' means the user can construct and execute arbitrary data processing pipelines — that's not a restricted context, that's the maximum-privilege use case. The real severity compounds through Langflow's collaboration model: once a pipeline containing this capability is saved and shared across a team, every collaborator inherits the exposure. A malicious user doesn't need to exploit this themselves — they can embed the env-reader into a shared pipeline and wait for it to run in production schedules. The underlying failure is architectural: Langflow's component model has no capability-based access control. Built-in components inherit implicit trust based on origin rather than declared privilege level. This component likely existed as a debugging utility written years ago when environment variables held configuration, not secrets. By 2024, Kubernetes and cloud platforms made secret injection into environment variables the default deployment pattern — but the component's risk profile was never re-evaluated. Immediate actions: First, confirm which version you're running and upgrade to 1.10.4 or later. Second, audit any saved or shared pipelines for components that access environment variables, filesystem, or network — treat any built-in component touching system resources as potentially over-privileged. Third, rotate any credentials that may have been exposed in environment variables on affected deployments, because this CVE is now public and enumeration of affected instances is trivial. Fourth, review your deployment: if you're injecting secrets as environment variables (the default in most K8s setups), consider whether Langflow's threat model accounts for compromised user accounts — if not, network segmentation and least-privilege IAM roles become your primary defense layer. The deeper question is whether Langflow has implemented proper capability scoping or simply removed this one component. If it's the latter, treat every other built-in component that touches system resources as an unresolved vulnerability until proven otherwise.

Reviewed through automated stages and approved by a human before publication.