Vulnerability Intelligence

Dependency Vulnerabilities in Popular LLM Frameworks

How to determine whether a vulnerability in an LLM framework or dependency actually affects your deployed AI application.

By PermsAI Editorial Team

Dependency vulnerabilities in an LLM application are rarely a single-package problem. A scanner may report a vulnerable parser, serializer, HTTP client, or optional integration several layers below the framework you recognize. The practical question is not “does a CVE mention LangChain or LlamaIndex?” It is: does the exact component and version exist in the deployed artifact, can the affected code path be reached with an attacker-controlled input, and is there evidence that a fix is operating in production?

This page is a current-reference method for fast-moving LLM software stacks. It is reviewed 2026-09-13; review the current snapshot monthly and after major advisories. The examples are a small verified sample, not a ranking of popular frameworks or a complete CVE list.

Start with a dependency identity record

Record the ecosystem first: PyPI, npm, a container image, a system package, or a managed service. Then record the exact package name, upstream repository, vendor or project, installed version, lockfile resolution, image digest, and runtime-loaded version. A GitHub repository name may not match the PyPI distribution, npm package, Docker image, or bundled binary. “LangChain” can refer to several Python packages, JavaScript packages, LangGraph components, or a hosted service. “LlamaIndex” is an umbrella project with separately released core and integration packages.

A useful evidence record has these fields:

ecosystem and package identifier;
upstream repository and advisory owner;
direct, transitive, optional, development-only, plugin, vendored, or service dependency;
declared constraint and lockfile version;
version actually installed in the image or environment;
module imported and feature enabled;
reachable input, endpoint, worker, or persistence store;
fixed version, backport, mitigation, owner, and deployment evidence.

Do not close a finding from a loose requirement such as “langchain-core >= 1.0.” Inspect the lockfile and the running image. The AI supply-chain guide covers provenance and SBOM practice; this article concentrates on vulnerability applicability.

LLM DEPENDENCY APPLICABILITY CHAIN

Application → Framework → Integration or plugin → Dependency → Exact deployed version → Reachable vulnerable path → Fix or mitigation → Deployment verification

At every arrow preserve the evidence. A framework upgrade may leave an old optional plugin in the lockfile. A dependency override may fix a package in one image but not a worker image. A container rebuild may update the image while a long-lived host process still imports the old wheel. Conversely, a vulnerable package that is installed but never imported may require a different risk state than an exposed parser or loader. Reachability is evidence to investigate, not a reason to dismiss a report without testing.

Direct, transitive, and optional dependencies

Consider a normal path: an AI application calls an LLM framework, the framework loads an integration, that integration invokes an HTTP, parser, or serialization library, and the lower component contains the weakness. The advisory may therefore apply to a transitive package rather than the top-level framework. Remediation can be a framework release, an exact subpackage upgrade, a lockfile override, removal of an integration, or a base-image rebuild.

Keep blame precise. A community connector that imports a vulnerable parser is not proof that the core framework is vulnerable. A development-only test dependency is not automatically reachable from a production API. An optional vector-store adapter may be dangerous only when the adapter is installed and selected. A vendor-hosted model endpoint is a service dependency with a different owner and patch process. Capture the relationship in the finding instead of using a sensational framework headline.

Reachability and configuration

Ask five concrete questions: Is the affected module imported? Is the feature enabled? Can untrusted input reach it? Is the affected parser, loader, checkpoint, or tool actually used? Is the endpoint exposed to a principal who can supply that input? Add configuration and persistence questions: does a job load user-controlled files, resume attacker-writable checkpoints, parse nested documents, or call a network-facing integration?

A package can be present but unreachable, reachable only by an administrator, or reachable through a background worker with broad credentials. Those states change urgency but do not erase the need to patch. Record a test or code reference that demonstrates the path, and retest after upgrades because dependency wiring can change.

Version ranges and lockfile evidence

Extract affected and fixed ranges exactly as the upstream advisory states them. Preserve separate branches, backports, pre-releases, withdrawn versions, and the advisory’s last-updated date. Do not casually translate a Python range into npm semver or assume a compatible major version has the same patch. Compare requirements.txt, pyproject constraints, poetry.lock, uv.lock, package-lock, pnpm-lock, yarn.lock, or the ecosystem equivalent with the installed package metadata.

The deployed version is the decisive operational fact. For containers, retain the image digest, build record, SBOM when available, and package listing from the running image. For managed services, capture the provider’s affected-service statement, region or plan scope, and dated remediation notice. The GPU vulnerability-management guide shows why host, runtime, and image inventories must be separated.

Advisory reconciliation method

OSV, a GitHub Security Advisory, NVD, and a vendor bulletin can disagree because they were published at different times or model different ecosystems. Treat each as a source with provenance rather than merging fields into one invented range.

Evidence source	Package identity	Affected range	Fixed range	Last updated	Confidence/use
Upstream security advisory	Maintainer’s exact distribution and repository	Maintainer-tested range	Maintainer release or commit	Advisory timestamp	Primary for product behavior and remediation
GitHub Security Advisory	Ecosystem package and GHSA/CVE aliases	Reviewed range	Reviewed patched release	GHSA update date	Strong corroboration and dependency tooling
OSV	Normalized package URL and aliases	Ecosystem events	Fixed event	OSV modified date	Machine-readable cross-feed, verify upstream
NVD/CVE record	CVE and CNA product scope	Enrichment or CNA range	CNA/vendor reference	NVD update date	Useful context; not a substitute for maintainer details
Vendor/project release note	Product release and supported branches	Branch-specific statement	Release, backport, or mitigation	Release date	Confirms patch delivery and support policy

If records disagree, state the disagreement and carry an UNKNOWN or NEEDS VALIDATION state until the project owner or deployed evidence resolves it. Check whether a record is modified, rejected, withdrawn, superseded, or disputed before treating its score or range as current. The AI security-advisory reading method provides a worksheet for this step.

CURRENT VERIFIED EXAMPLE SNAPSHOT — reviewed 2026-09-13

These examples were individually checked against an upstream or ecosystem primary record and its aliases. They show why applicability depends on local usage.

Framework/ecosystem	Affected component	Advisory	Affected versions	Fixed version	Why local usage matters	Primary source
LangChain Python	langchain-core	GHSA-pjwx-r37v-7724 / CVE-2026-44843	1.0.0 through 1.3.2, and 0.3.84 or earlier	1.3.3 and 0.3.85	Exposure requires untrusted structured input reaching older run-data paths that deserialize nested LangChain objects; a plain chain that never loads those values has a different path	Upstream GitHub advisory
LangGraph Python	langgraph	GHSA-g48c-2wqr-h844 / CVE-2026-28277	1.0.9 or earlier	1.0.10	The upstream record describes attacker write access to persisted checkpoint bytes plus a load/resume path; it is not an unauthenticated remote issue in a correctly protected store	Upstream GitHub advisory
LlamaIndex Python	llama-index-core JSONReader	PYSEC-2026-1561 / CVE-2025-5302 / GHSA-7753-xrfw-ch36	Through 0.12.37	0.12.38	Deeply nested JSON can trigger uncontrolled recursion when the JSONReader is used; an application that never accepts such files or uses another reader has different exposure	OSV record

The LlamaIndex project security page currently states that it has no published repository advisories, while the Python advisory database and OSV carry the JSONReader record. That is a useful disagreement to preserve: OSV is evidence to investigate, not permission to attribute every downstream issue to the umbrella project. Verify the package, reader, version, and upstream fix commit before assigning ownership.

Plugins, images, and managed services

Map integrations separately from core. A community retriever, model-loader plugin, tracing SDK, or database adapter may have its own advisory and release cadence. A plugin can also pin a vulnerable transitive package after the framework has fixed its own code. Remove an unused integration when an upgrade is blocked, but record the residual impact and test that no worker still imports it.

Container builds need two inventories: the source lockfile and the image that actually runs. A patched repository does not prove that an old image digest was replaced. Conversely, a rebuilt image may not update a host runtime, GPU driver, or managed control plane. For hosted frameworks, ask which layer the provider owns, what version or region is affected, and what customer-visible evidence proves remediation. Do not claim “patched” from a vendor status page without tying it to your deployment.

Patch, mitigate, verify

Choose the narrowest effective fix: upgrade the framework, upgrade the exact subpackage, apply a temporary dependency pin, remove an optional integration, rebuild the base image, disable the affected feature, or apply a vendor mitigation. Label MITIGATED separately from FIXED. A firewall or input filter can reduce reachability while a vulnerable loader remains installed.

Verification should include the new lockfile, image digest, package metadata, runtime import, configuration, and a security regression test for the affected path. Re-test after worker rollout, autoscaling, cache refresh, and rollback. Keep the advisory identifier, source date, owner, change record, and residual assumptions in the ticket.

Continuous monitoring and review cadence

No feed is complete. Combine OSV and GitHub advisories with upstream security pages, vendor bulletins, dependency scanners, SBOM monitoring, CISA or NVD context, and release notifications. Normalize aliases but retain each source’s original range and timestamp. Alert when a new package enters the graph, a lockfile changes, an image digest changes, or an advisory is modified or withdrawn.

Review this current-reference page monthly and after major advisories. On each review, re-check the snapshot’s primary records, fixed releases, upstream caveats, and whether the examples still represent supported versions. Replace an example when the source is superseded rather than silently carrying stale ranges.

Practical triage checklist

Identify ecosystem, package, repository, owner, and exact deployed version.
Classify the dependency as direct, transitive, optional, development-only, plugin, vendored, or service.
Compare manifest, lockfile, image digest, SBOM, and runtime-loaded version.
Read the upstream advisory before NVD enrichment; preserve affected and fixed ranges exactly.
Confirm feature activation, attacker-controlled input, endpoint exposure, and persistence prerequisites.
Check modified, withdrawn, rejected, disputed, and superseded record states.
Choose upgrade, override, removal, rebuild, disablement, or mitigation and name the owner.
Verify the fix in every worker, image, environment, and managed-service boundary.
Record evidence, retest after rollout, and schedule monthly and major-advisory review.

Sources

Reviewed: 2026-09-13. Recheck current-reference examples monthly and after major advisories.