Langflow, an open-source framework for building AI workflows, shipped with critical flaws that allowed authentication bypass and remote code execution. Attackers have exploited these vulnerabilities to steal AI and developer credentials. IBM, which owns the project, has patched the issues.
If your team runs Langflow, or any similar AI orchestration tool, this is a must-read. The failure pattern is familiar, and so is the fix.
What Happened
Langflow OSS versions 1.0.0 through 1.12.8 contain vulnerabilities that let an attacker bypass authentication and execute code remotely. One of them, CVE-2026-93680, carries a CVSS score of 9.8. Exploitation has been observed, with attackers harvesting AI service credentials and developer credentials from affected instances. Version 1.13.0 contains the fix.
That's the confirmed picture. We don't have public detail on how many instances were compromised or how long attackers had access, so this teardown sticks to what's established.
Timeline
The disclosed facts support a simple sequence:
- Vulnerable code ships. Versions 1.0.0 through 1.12.8 carry the flaws. That spans every release from the 1.0 line up to the one before the fix.
- Exploitation begins. Attackers use the authentication bypass and code execution paths to steal AI and developer credentials.
- IBM patches. Langflow 1.13.0 addresses the vulnerabilities.
- Your window opens. From the moment the fix is public, anyone running an affected version is exposed to a known, actively exploited flaw with a public patch available.
The fourth step is where your team has control. The first three already happened.
Which Controls Failed or Were Missing
Break this into two layers: what failed at the vendor and project level, and what may have failed in the environments running Langflow.
Project-level failures
- Authentication could be bypassed entirely, meaning access control wasn't enforced on critical paths.
- A path to remote code execution existed in a tool designed to run user-defined workflows. This high-risk design surface needs strict input handling and isolation.
Deployment-level gaps that turn a flaw into a breach
- Exposure. Any Langflow instance reachable from untrusted networks gives an unauthenticated attacker a direct line to the bug.
- Credential placement. The theft of AI and developer credentials suggests those secrets were accessible to the application process. Langflow workflows commonly hold API keys for model providers and connected services. If those keys sit in environment variables or the application's reach, code execution hands them over.
- Patch latency. Every day an instance stays on a version at or below 1.12.8 after the fix is available is a control failure on your side, not the vendor's.
- Inventory. Teams often spin up AI tooling outside normal procurement. If you don't know where Langflow runs, you can't patch it.
What the Relevant Standard Requires
No single standard is written around AI workflow tools, but several map cleanly onto this incident.
CVSS and prioritization. A 9.8 score is critical by any scale. But the score alone shouldn't drive your timeline. Active exploitation does. A critical flaw with confirmed in-the-wild abuse and a public fix belongs at the front of your queue, ahead of higher-scored issues that nobody is attacking. Use CVSS to rank, and exploitation status to set the deadline.
NIST 800-53 Rev 5. Control SI-2 (Flaw Remediation) requires you to identify, report, and correct system flaws, and to install security-relevant updates within defined time periods. RA-5 (Vulnerability Monitoring and Scanning) requires you to scan for and remediate vulnerabilities. CM-8 (System Component Inventory) covers the inventory gap. IA-2 and AC-3 address authentication and access enforcement, the controls the bypass defeated.
PCI DSS v4.0.1. If Langflow touches a cardholder data environment, Requirement 6.3.1 requires identifying and ranking vulnerabilities, and Requirement 6.3.3 requires that critical or high-security patches be installed within one month of release. Requirement 6.3.2 requires an inventory of bespoke and third-party software components, which is where open-source AI tooling often goes missing.
ISO/IEC 27001:2022. Annex A control 8.8 (Management of technical vulnerabilities) requires you to obtain information about vulnerabilities, evaluate your exposure, and take action. Control 8.9 covers configuration management, relevant to how you deploy and expose these tools.
SOC 2 Type II. Under the Common Criteria, CC7.1 covers detection and monitoring of vulnerabilities, and CC7.2 covers monitoring for anomalies. Auditors testing over a period will want evidence that you applied the patch, not just that you have a policy.
NIST Cybersecurity Framework (CSF) v2.0. The Identify function (asset management and risk assessment) and Protect function (platform security) both apply directly.
Lessons and Action Items for Your Team
Find every Langflow instance now. Check cloud accounts, container registries, developer workstations, and shared notebooks. Treat AI tooling as shadow IT until proven otherwise. Add it to your software inventory so it shows up next time.
Upgrade to 1.13.0 or later. Anything running versions 1.0.0 through 1.12.8 is affected. Don't wait for a maintenance window; this is an actively exploited flaw.
Assume credentials were exposed on any instance you can't clear. If an affected instance was internet-reachable, rotate the AI provider keys, developer tokens, and any secrets the application could read. Patching closes the door but doesn't recover what already left.
Pull instances off the public internet. Put Langflow behind a VPN or an authenticating reverse proxy. Don't rely on the application's own login as your only barrier, since that's the control that failed here.
Shrink what a compromise can reach. Run the framework with least-privilege access, in an isolated container or network segment. Use a secrets manager with scoped, short-lived credentials instead of long-lived keys in environment variables.
Set a rule for exploited vulnerabilities. Write down that any flaw with confirmed in-the-wild exploitation gets an accelerated SLA regardless of score. Then wire your vulnerability feeds so open-source AI components are monitored like any other dependency.
Hunt for signs of abuse. Review logs on affected hosts for unexpected process execution, unfamiliar outbound connections, and unusual use of your AI provider keys. Check provider dashboards for usage you can't explain.
The lesson isn't that open source is unsafe. It's that open-source AI frameworks hold high-value secrets and run arbitrary logic, so they deserve the same inventory, exposure control, and patch discipline as your production web stack. The patch exists. The only open question is how fast you apply it.
