LangChain, Langflow, LiteLLM: When AI's Foundation Code Becomes the Attack Surface
The week of March 24, 2026 will be remembered as the moment the AI infrastructure security crisis stopped being theoretical.
In the span of four days, three separate attacks hit the foundational frameworks that power enterprise AI deployments: LangChain and LangGraph disclosed three high-severity vulnerabilities affecting 60 million weekly downloads. CISA added a critical Langflow remote code execution flaw to its Known Exploited Vulnerabilities catalog after attackers weaponized it within 20 hours of disclosure. And a threat group called TeamPCP compromised LiteLLM's PyPI publishing pipeline through a poisoned security scanner, deploying credential-stealing malware to a package downloaded 3.4 million times per day.
These are not isolated incidents. They reveal a systemic pattern that should concern every organization building with AI: the frameworks connecting large language models to enterprise data are riddled with the oldest vulnerability classes in the book, and attackers know it.
The Attack Cluster: What Happened
LangChain and LangGraph: Three Vulnerabilities, 60 Million Weekly Downloads
On March 27, security researchers at Cyera disclosed three vulnerabilities across LangChain and LangGraph, the most widely used open-source frameworks for building LLM-powered applications. Combined, LangChain, LangChain-Core, and LangGraph account for more than 60 million PyPI downloads per week. The frameworks sit at the center of a massive dependency web, meaning vulnerabilities in their core ripple outward through every downstream library, wrapper, and integration.
The three flaws each expose a different class of enterprise data.
CVE-2026-34070 (CVSS 7.5) is a path traversal vulnerability in LangChain's prompt-loading module that allows an attacker to access arbitrary files on the filesystem without any validation. Docker configurations, application secrets, internal documentation: anything the LangChain process can read becomes accessible.
CVE-2025-68664 (CVSS 9.3), codenamed "LangGrinch" by researcher Yarden Porat at Cyata, is a serialization injection flaw in langchain-core's dumps() and dumpd() functions. The vulnerability exists because these functions fail to escape user-controlled dictionaries containing LangChain's internal lc marker key. When attacker-shaped data includes this key structure, the framework treats it as a legitimate LangChain object during deserialization rather than untrusted input. The result: attackers can extract secrets from environment variables, instantiate classes within pre-approved trusted namespaces, and potentially achieve arbitrary code execution. Until the patch, the secrets_from_env parameter defaulted to True, meaning secret loading from the environment was automatic.
CVE-2025-67644 (CVSS 7.3) is an SQL injection vulnerability in LangGraph's SQLite checkpoint implementation. An attacker can manipulate SQL queries through metadata filter keys and run arbitrary queries against the checkpoint database, accessing conversation histories associated with sensitive workflows.
The patches are available. CVE-2026-34070 requires langchain-core version 1.2.22 or later. CVE-2025-68664 requires versions 0.3.81 or 1.2.5 and above. CVE-2025-67644 requires langgraph-checkpoint-sqlite version 3.0.1. Organizations should update immediately and audit any workflows that pass untrusted data through LangChain's serialization layer.
Langflow CVE-2026-33017: Weaponized in 20 Hours
The Langflow vulnerability is arguably the most alarming of the three incidents, not because of its technical complexity but because of the speed at which it went from advisory to active exploitation.
On March 17, a critical security flaw was disclosed in Langflow, the open-source visual framework for building AI agent workflows with over 145,000 GitHub stars. Tracked as CVE-2026-33017 (CVSS 9.3), the vulnerability allows unauthenticated remote code execution through the /api/v1/build_public_tmp/{flow_id}/flow endpoint. This endpoint is designed to let unauthenticated users build public flows, but when an optional data parameter is supplied, it accepts attacker-controlled flow data containing arbitrary Python code in node definitions. That code is passed directly to exec() with zero sandboxing.
A single HTTP POST request. No authentication required. Full code execution on the server.
Sysdig's Threat Research Team observed the first exploitation attempts within 20 hours of the advisory's publication. No public proof-of-concept code existed at the time. Attackers built working exploits directly from the advisory description. Within 21 hours, Python-based exploitation scripts appeared in the wild. Within 24 hours, data harvesting targeting .env and .db files was underway.
CISA added CVE-2026-33017 to its Known Exploited Vulnerabilities catalog on March 25, giving federal agencies until April 8 to patch or stop using the product. This is the second critical Langflow RCE in the KEV catalog. The first, CVE-2025-3248, targeted a different endpoint but exploited the same underlying exec() call.
What makes this particularly dangerous is what Langflow instances typically have access to. These are not isolated development tools. They are configured with API keys for OpenAI, Anthropic, AWS, and database connections. Compromising a single Langflow instance can provide lateral access to cloud accounts, data stores, and the entire AI supply chain that flows through it.
The researcher who discovered CVE-2026-33017, Aviral Srivastava, found it while examining how Langflow maintainers fixed the previous vulnerability. The same vulnerability class, in a different endpoint, exploiting the same dangerous function. This is a pattern of systemic architectural weakness, not a one-off bug.
Organizations running Langflow should upgrade to version 1.9.0 or later immediately. If upgrading is not possible, disable or restrict the vulnerable endpoint. Do not expose Langflow directly to the internet. Rotate all API keys, database credentials, and cloud secrets if suspicious activity is detected.
LiteLLM Supply Chain Attack: A Security Scanner Became the Weapon
The LiteLLM compromise is the most sophisticated of the three incidents and demonstrates how AI infrastructure's position in the software supply chain creates outsized blast radius from a single point of failure.
On March 24, two malicious versions of the LiteLLM Python package (1.82.7 and 1.82.8) appeared on PyPI. LiteLLM is a unified API wrapper that lets developers route requests across LLM providers including OpenAI, Anthropic, Google, and Azure. It is downloaded approximately 3.4 million times per day.
The attack was orchestrated by a threat group known as TeamPCP, and its execution chain reveals just how fragile the trust model in open-source AI infrastructure has become.
It started with Trivy, a widely used open-source vulnerability scanner maintained by Aqua Security. On March 19, TeamPCP rewrote Git tags in the trivy-action GitHub Action repository to point to a malicious release carrying credential-harvesting payloads. On March 23, the same infrastructure was used to attack Checkmarx KICS, another security tool. On March 24, the chain reached LiteLLM.
LiteLLM's CI/CD pipeline ran Trivy as part of its build process, pulling it from apt without a pinned version. The compromised Trivy action exfiltrated the PYPI_PUBLISH token from the GitHub Actions runner environment. With that credential, TeamPCP published the malicious LiteLLM versions directly to PyPI, bypassing the normal release process entirely. No corresponding tag or release existed on the LiteLLM GitHub repository. The attack was invisible to anyone reviewing the source code.
The malicious packages contained a .pth file, a little-known Python mechanism that auto-executes code every time the Python interpreter starts. No explicit import required. The payload was a multi-stage credential stealer designed to harvest AWS, GCP, and Azure tokens, SSH keys, Kubernetes configurations, Git credentials, API keys, shell history, and crypto wallets. Stolen data was exfiltrated to models.litellm[.]cloud, a domain not affiliated with the legitimate LiteLLM project.
The compromised versions were live for approximately three hours before PyPI quarantined the package. During that window, an estimated 40,000 downloads occurred.
When community members began reporting the compromise in GitHub issue #24512, the attackers responded with what can only be described as information warfare. Using the compromised maintainer account, they posted 88 bot comments from 73 unique accounts in a 102-second window, using previously compromised developer accounts to flood the discussion. They closed the issue as "not planned" and made commits to unrelated repositories. The community had to open a parallel tracking issue and move the discussion to Hacker News, where the thread reached 324 points.
FutureSearch researcher Callum McMahon discovered the compromise when his 48GB Mac ground to a halt after a Cursor MCP plugin pulled in LiteLLM as a transitive dependency. A flaw in the malware's implementation caused the .pth launcher to recursively fork, creating an exponential fork bomb that crashed his machine. Without that accidental failure mode, the malware would have operated silently.
LiteLLM has since released version 1.83.0 through a rebuilt CI/CD pipeline with isolated environments and stronger security gates. The incident was assigned CVE-2026-33634 with a CVSS score of 9.4.
Why This Matters: The AI Infrastructure Security Gap
These three incidents share a common thread that goes beyond individual vulnerability classes. They expose the fundamental security gap in how organizations are deploying AI systems.
Classic Vulnerabilities in New Plumbing
Every vulnerability in this cluster is a well-understood attack pattern. Path traversal. Deserialization injection. SQL injection. Unauthenticated code execution via exec(). Supply chain credential theft through CI/CD compromise. None of these are novel. Security teams have been defending against these classes of attack for years.
The difference is where they are appearing. AI frameworks like LangChain, Langflow, and LiteLLM have become critical infrastructure inside production systems. They sit between applications and LLM providers, between users and databases, between AI agents and the enterprise systems they interact with. Serialization formats, orchestration pipelines, tool execution, caches, and tracing are no longer plumbing. They are part of the security boundary.
But they are not being treated that way. AI development teams often operate outside the security review processes that govern traditional application development. Frameworks are adopted for speed and flexibility, not for their security posture. And the security tools meant to catch these issues, like Trivy, can themselves become attack vectors.
The Machine Identity Problem
When I write about machine identity management and the security gap created by AI agents operating within enterprise systems, the response is often that the problem is theoretical. This week's attacks demonstrate it is anything but.
LiteLLM sits at the intersection of multiple cloud providers, storing API keys for each. Langflow instances hold credentials for databases, AI providers, and internal services. LangChain orchestration loops handle serialized data that crosses trust boundaries with every function call. These are machine identities, service accounts, API tokens, and automated credentials operating at scale with minimal human oversight.
The blast radius calculations tell the story. A single compromised LiteLLM instance does not just expose LiteLLM's own credentials. It exposes every API key, every cloud token, every database password that flows through it. A compromised Langflow instance provides lateral access to every connected service. A LangChain deserialization vulnerability lets attackers extract secrets from the runtime environment itself.
This is the machine identity crisis playing out in real time. Enterprise IAM systems were built for human users with human authentication patterns. The AI frameworks being deployed today create machine-to-machine trust relationships that those systems were never designed to govern.
The Speed Problem
CVE-2026-33017 went from advisory to weaponized exploitation in 20 hours. No public proof-of-concept required. The advisory description contained enough detail for attackers to build working exploits.
The LiteLLM supply chain attack was live for approximately three hours before quarantine. In that window, 40,000 downloads occurred.
The traditional vulnerability management cadence, where security teams scan weekly, prioritize monthly, and patch quarterly, is fundamentally incompatible with these timelines. When the patch window collapses to hours, runtime detection and automated response become the primary line of defense.
What Organizations Should Do
Immediate
Audit your AI framework dependencies immediately. Check every project for LangChain, LangGraph, Langflow, and LiteLLM. Update to patched versions. For LiteLLM specifically, check whether versions 1.82.7 or 1.82.8 were ever installed in any environment. If they were, treat the environment as compromised and rotate all credentials.
Inventory your AI framework credentials. Map every API key, cloud token, database password, and service account that flows through your AI infrastructure. Most organizations cannot answer the question "what credentials does our LangChain deployment have access to?" until it is too late.
Pin your dependencies. The LiteLLM attack succeeded because the CI/CD pipeline pulled Trivy without a pinned version. Every dependency in your AI build pipeline should be pinned to a specific version with hash verification. This applies to runtime dependencies, CI/CD tools, and GitHub Actions alike.
Ongoing
Implement zero trust principlesfor AI infrastructure. AI frameworks should not have broad access to cloud accounts, databases, and internal services by default. Apply least-privilege access, segment AI workloads from production infrastructure, and monitor outbound traffic from AI systems for anomalous connections.
Establish a software bill of materials (SBOM) for your AI stack. The dependency chains in AI frameworks are deep and interconnected. LangChain does not exist in isolation. Hundreds of libraries wrap, extend, and depend on it. When a vulnerability exists in LangChain's core, it propagates through every downstream integration.
Review your authentication architecturefor machine-to-machine trust. Every AI agent, every LLM orchestration pipeline, every API gateway should authenticate with short-lived, scoped credentials. Static API keys scattered across environment variables are not authentication. They are time bombs.
Future
Build AI agent identity governance into your security program. The frameworks under attack this week are the plumbing of agentic AI. As organizations deploy more autonomous AI agents that interact with production systems, the identity and access management layer for those agents becomes critical. This means dedicated service identities for AI agents, runtime behavioral monitoring, and automated credential rotation.
Pressure your AI framework vendors on security. Langflow has now had two critical RCE vulnerabilities in CISA's KEV catalog within a year, both exploiting the same underlying exec() call. LangChain's core serialization layer had a CVSS 9.3 flaw. These are not edge cases. They are design-level security weaknesses that require architectural fixes, not just patches.
Integrate AI infrastructure into your existing vulnerability management program. AI frameworks cannot continue to operate outside the security review processes that govern the rest of your technology stack. They handle sensitive data, hold privileged credentials, and interact with production systems. They deserve the same scrutiny as your databases, your APIs, and your authentication infrastructure.
The Bottom Line
The week of March 24, 2026 delivered a clear message: AI infrastructure is under active attack, and the vulnerabilities being exploited are not sophisticated zero-days. They are path traversals, deserialization flaws, SQL injection, and supply chain credential theft. The oldest tricks in the cybersecurity playbook, hiding in the newest and fastest-growing layer of the enterprise technology stack.
The organizations that weather this transition will be the ones that stop treating AI frameworks as development tools and start treating them as critical infrastructure. That means applying the same identity governance, access controls, and security monitoring that we apply to databases, APIs, and authentication systems.
The organizations that do not will learn the lesson the hard way. And at 20 hours from advisory to exploitation, the learning curve is steep.
Q: What happened with LangChain vulnerabilities in March 2026?
A: In March 2026, security researchers at Cyera disclosed three vulnerabilities in LangChain and LangGraph: a path traversal flaw (CVE-2026-34070), a critical serialization injection called "LangGrinch" (CVE-2025-68664, CVSS 9.3), and an SQL injection in LangGraph's SQLite checkpoints (CVE-2025-67644). These affect frameworks with over 60 million combined weekly downloads.
Q: How was Langflow CVE-2026-33017 exploited?
A: CVE-2026-33017 is a critical unauthenticated remote code execution vulnerability in Langflow's public flow build endpoint. Attackers weaponized it within 20 hours of the advisory publication, building working exploits directly from the advisory description without any public proof-of-concept code. CISA added it to the Known Exploited Vulnerabilities catalog on March 25, 2026.
Q: What was the LiteLLM supply chain attack?
A: On March 24, 2026, threat group TeamPCP published malicious versions of the LiteLLM Python package (1.82.7 and 1.82.8) on PyPI after stealing publishing credentials through a compromised Trivy security scanner in LiteLLM's CI/CD pipeline. The malicious packages contained credential-stealing malware targeting cloud tokens, SSH keys, and API keys.
Q: How do I check if my systems were affected by the LiteLLM attack?
A: Run pip show litellm to check your installed version. Search for the litellm_init.pth file in site-packages. Check system logs for connections to models.litellm[.]cloud. If versions 1.82.7 or 1.82.8 were installed, treat all credentials in the environment as compromised and rotate immediately.
Q: What is machine identity governance for AI agents?
A: Machine identity governance is the practice of managing the identities, credentials, and access permissions of AI agents and automated systems. It includes assigning dedicated service identities, implementing least-privilege access, monitoring runtime behavior, and automating credential rotation for AI frameworks that interact with production systems.
Key Takeaways
- Three major AI framework attacks in one week: LangChain/LangGraph triple vulnerability disclosure, Langflow active exploitation (CVE-2026-33017), and LiteLLM supply chain compromise (CVE-2026-33634)
- LangChain vulnerabilities include path traversal (CVE-2026-34070), serialization injection with CVSS 9.3 (CVE-2025-68664), and SQL injection in LangGraph (CVE-2025-67644), affecting 60M+ weekly downloads
- Langflow's critical RCE was weaponized within 20 hours of advisory publication with no public PoC, representing the second Langflow vulnerability in CISA's KEV catalog within a year
- TeamPCP compromised LiteLLM through a poisoned Trivy security scanner in the CI/CD pipeline, stealing the PyPI publishing token and deploying credential-stealing malware to 40,000+ downloads in three hours
- The malicious LiteLLM packages harvested AWS, GCP, Azure tokens, SSH keys, Kubernetes configs, and API keys from affected environments
- All three attacks exploit well-understood vulnerability classes (path traversal, deserialization, SQLi, supply chain) hiding in AI infrastructure
- AI frameworks like LangChain and LiteLLM sit at the center of massive dependency webs, meaning vulnerabilities propagate through every downstream integration
- Runtime detection and automated credential rotation are essential when the exploitation window collapses to hours
- Organizations must inventory all credentials flowing through AI infrastructure and apply zero trust principles to AI workloads
- AI agent identity governance is no longer optional as frameworks handling privileged credentials come under sustained attack
Related Reading on guptadeepak.com:
- Machine Identity Management: The Complete Enterprise Guide - Why machine identities are the fastest-growing attack surface in enterprise security
- AI Agent Authentication and Security - How agentic AI creates new identity governance challenges
- Zero Trust Security Architecture - Implementing zero trust for modern infrastructure including AI workloads
- Authentication Best Practices for 2026 - From passwords to passkeys to machine credentials
- Password Hashing Comparison - Understanding cryptographic fundamentals that protect credentials at rest
- FIDO2 Implementation Guide - Phishing-resistant authentication for human and machine identities
- Customer Identity Hub - Comprehensive resources on identity management architecture
Need help with AI visibility for your B2B SaaS? GrackerAI helps cybersecurity and B2B SaaS companies get cited by ChatGPT, Perplexity, and Google AI Overviews through Generative Engine Optimization.
Deepak Gupta_is the co-founder and CEO of GrackerAI. He previously founded a CIAM platform that scaled to serve over 1B+ users globally. He writes about AI, cybersecurity, and digital identity at guptadeepak.com._
Discussion in the ATmosphere