IBM Langflow CVE-2026-9103

Exploitation requires that the AUTO_LOGIN configuration setting be enabled - this is the default, so out-of-the-box deployments are vulnerable - and that the attacker have network reachability to the Langflow API's /api/v1/login/auto_login endpoint. No credentials, user interaction, or non-default tuning is otherwise needed (CVSS AV:N/AC:L/PR:N/UI:N). The primary limiting factor is configuration: operators who explicitly set AUTO_LOGIN to false and provision real authentication are not exposed. Network exposure is the second limiter - instances bound to localhost or placed behind an authenticating proxy/VPN are not reachable by external attackers. The permissive-CORS token-leak variant additionally requires a victim to visit an attacker-controlled origin in a browser holding a valid session.

This is a genuine high-priority issue rather than an inflated CVSS number. The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H = 9.8) is fully consistent with the description: network-reachable, no authentication, no user interaction, and a single request yields superuser access - a textbook SSVC 'automatable' condition with total technical impact. The one meaningful caveat is that exploitation depends on AUTO_LOGIN being enabled; although it is enabled by default, hardened multi-user deployments that explicitly disable it are not exposed, so real-world exposure tracks how many operators left the default in place. No EPSS score, KEV entry, or POC was provided in the input, so likelihood of mass exploitation cannot be quantified from the data - the absence of a KEV listing means active exploitation is not confirmed, and POC status is unknown. Given how trivial the primitive is (an unauthenticated GET/POST returning an admin token), defenders should treat it as readily weaponizable regardless of current EPSS silence.

An attacker who can reach a default-configured Langflow instance sends a single request to /api/v1/login/auto_login and receives a long-lived superuser bearer token without any credentials. Using that token they authenticate to the admin API and gain full control - reading and modifying flows, secrets, and connected model/API keys, or executing further actions. Alternatively, they lure an internal user to a malicious web page that, thanks to permissive CORS, reads the token cross-origin.