VULN_88805 Upgrading langchain-core to >=1.3.3

[shuningc]

Summary

• Upgrades the LangChain ecosystem to address 5 CVEs across 6 JIRA tickets (VULN-88805, VULN-88806, VULN-92528, VULN-88796, VULN-92530, VULN-92532)
• Tightens pyproject.toml constraints to exact CVE fix thresholds; langchain-core, langchain, and langsmith are now explicitly pinned with safe lower bounds
• langgraph, langgraph-checkpoint, and langgraph-sdk are upgraded transitively via the langchain dependency chain

Package versions

┌──────────────────────┬────────┬────────┐
│ Package │ Before │ After │
├──────────────────────┼────────┼────────┤
│ langchain-core │ 1.2.7 │ 1.5.0 │
├──────────────────────┼────────┼────────┤
│ langchain │ 1.2.4 │ 1.3.14 │
├──────────────────────┼────────┼────────┤
│ langsmith │ 0.4.14 │ 0.10.9 │
├──────────────────────┼────────┼────────┤
│ langgraph │ 1.0.6 │ 1.2.9 │
├──────────────────────┼────────┼────────┤
│ langgraph-checkpoint │ 4.0.0 │ 4.1.1 │
├──────────────────────┼────────┼────────┤
│ langgraph-sdk │ 0.3.3 │ 0.4.2 │
└──────────────────────┴────────┴────────┘

Security vulnerabilities addressed

VULN-88805 — langchain-core < 1.3.3: Overly broad object deserialization via load() with allowed_objects="all" allows attacker-supplied constructor dicts to instantiate trusted classes
with untrusted arguments.

VULN-88806 — langsmith < 0.8.0: pull_prompt fetches public Hub prompts without distinguishing external vs org-owned content, allowing untrusted serialized objects to affect runtime
behavior.

VULN-92528 — langchain < 1.3.9: Path traversal in file-search middleware, prompt/chain loaders, and path-prefix authorization — glob patterns and symlinks can escape the configured root
directory when input originates from untrusted sources including LLM output.

VULN-88796 — langgraph: Transitive upgrade driven by langchain >= 1.3.9 requirement.

VULN-92530 — langgraph-checkpoint < 4.1.1: JsonPlusSerializer can reconstruct arbitrary Python objects from checkpoint payloads if the backing store is compromised, potentially leading
to code execution at checkpoint load time.

VULN-92532 — langgraph-sdk < 0.3.15: Unsanitized caller-supplied identifiers in HTTP request paths allow path traversal to unintended resources when identifier values originate from
untrusted sources.

Test plan

• Full test suite passes: 1931 passed, 10 skipped, 0 failures
• No breaking changes — all consumed APIs (AgentFinish, BaseCallbackHandler, Document, BaseMessage, LLMResult) are stable across the 1.x series
• pyproject.toml minimum constraints match exact CVE fix thresholds

[fercor-cisco]

🤖 This review was generated by the Astra agent (claude-opus-4-8). It may contain mistakes.

Verdict: needs_discussion — Lock satisfies all six CVE tickets, but the new langsmith floor isn't wired into any extra, so the VULN-88806 fix isn't enforced for consumers of the published package.

General Comments

• 🟠 major (security): The PR body states langsmith is "now explicitly pinned with safe lower bounds," but for consumers of the published package this pin is ineffective. langsmith >=0.8.0 is declared as optional = true in [tool.poetry.dependencies], yet it is not listed in any extra under [project.optional-dependencies] (langchain or all). Poetry only installs an optional dependency when an extra references it, so pip install splunk-ao[langchain] never applies the >=0.8.0 floor — langsmith is only pulled transitively via langchain-core (floor >=0.3.45), leaving a fresh resolve free to select a pre-0.8.0 (VULN-88806-vulnerable) langsmith. The repo's own poetry.lock pins 0.10.9 so FOSSA on this repo is satisfied, but the intended constraint for downstream consumers is not enforced. Fix: add langsmith (>=0.8.0) to both the langchain and all extras in [project.optional-dependencies].

Follow-ups

Suggested follow-up work that could be tracked as Shortcut stories:

• pyproject.toml:38-39: The langgraph family (langgraph, langgraph-checkpoint, langgraph-sdk, langgraph-prebuilt) is only pulled transitively via langchain and is not directly constrained here. The transitive floors are not all above the CVE remediation thresholds — e.g. langgraph 1.2.9 requires langgraph-checkpoint >=4.1.0, which permits the still-vulnerable 4.1.0 (VULN-92530 fixed in 4.1.1). The current poetry.lock pins 4.1.1 so this is not an active issue, but consider adding explicit direct floors (langgraph-checkpoint >=4.1.1, langgraph-sdk >=0.3.15) as defense-in-depth so future lock regenerations can't drift below the fix versions.

[fercor-cisco]

🟠 major (security): langsmith is marked optional = true but is not referenced by any extra in [project.optional-dependencies] (lines 23 and 27). As a result this >=0.8.0 floor is never installed for consumers of splunk-ao[langchain]/splunk-ao[all]; langsmith is only resolved transitively through langchain-core (floor >=0.3.45), so the VULN-88806 fix isn't guaranteed for downstream installs. Add langsmith (>=0.8.0) to the langchain and all extra lists so the constraint actually applies.

Suggested change

	langsmith = { version = ">=0.8.0", optional = true }
	langchain = ["langchain-core", "langchain", "langsmith (>=0.8.0)"]

🤖 Generated by the Astra agent

[shuningc]

Updated in the latest commit

[fercor-cisco]

🤖 This review was generated by the Astra agent (claude-sonnet-5). It may contain mistakes.

Verdict: request_changes — The langsmith floor gap flagged by the earlier reviewer was correctly fixed, but the same class of gap remains for langgraph-checkpoint: the diff shows langgraph 1.2.9's own metadata only requires langgraph-checkpoint >=4.1.0,<5.0.0, and 4.1.0 is explicitly the last vulnerable version per VULN-92530 — so nothing in this package's published dependency metadata actually guarantees the CVE-92530 fix for downstream consumers, only the (non-shipped) lockfile happens to pin the safe 4.1.1.

General Comments

• 🟠 major (security): The langsmith floor gap that fercor-cisco flagged (comment 3632473306) was correctly fixed by adding langsmith (>=0.8.0) to the langchain/all extras — but the exact same class of gap still exists for langgraph-checkpoint (VULN-92530), and the diff itself proves it: in poetry.lock, the upgraded langgraph 1.2.9 declares langgraph-checkpoint = ">=4.1.0,<5.0.0" as its own dependency floor. Per the VULN-92530 ticket text, "In versions 4.1.0 and prior, the JsonPlusSerializer can reconstruct Python objects... This issue has been fixed in version 4.1.1." So langgraph's own declared floor explicitly permits the last vulnerable version.

This matters because poetry.lock is a dev/test artifact for this repo — it is not published with the splunk-ao wheel/sdist, so it does nothing to protect downstream consumers who pip install "splunk-ao[langchain]". The only thing that constrains a consumer's resolver is the metadata declared in [project.optional-dependencies] / [tool.poetry.dependencies], and none of langgraph, langgraph-checkpoint, or langgraph-sdk are declared there at all — they're purely transitive via langchain. Right now the checked-in lockfile happens to resolve to the safe 4.1.1, but that's an accident of when poetry lock was run, not something the declared constraints enforce. A future re-resolution (or a consumer installing without this repo's lockfile at all) could legally land on langgraph-checkpoint==4.1.0 while still satisfying every constraint this PR adds.

Suggested fix: add explicit floors the same way it was done for langsmith, e.g. in [tool.poetry.dependencies]:

langgraph-checkpoint = { version = ">=4.1.1", optional = true }

and include "langgraph-checkpoint (>=4.1.1)" in the langchain and all extras in [project.optional-dependencies]. For full defense-in-depth (and since we can't verify from this diff alone what floor langchain==1.3.9, the actual pyproject.toml floor, requires for langgraph/langgraph-sdk), it would also be worth adding explicit floors for langgraph (>=1.0.10) and langgraph-sdk (>=0.3.15) even though their currently-observed transitive floors (1.2.5 and 0.4.2 respectively) already clear the CVE thresholds.

Follow-ups

Suggested follow-up work that could be tracked as Shortcut stories:

• pyproject.toml:22-27: Consider adding a CI/lint check (e.g. a small script comparing pyproject.toml floors against poetry.lock resolved versions, or against the FOSSA/Jira remediation versions) that fails when a transitively-upgraded package's declared floor drifts below its CVE fix threshold. This class of gap (safe in the lockfile, unenforced in published package metadata) has now recurred twice in this PR alone (langsmith, langgraph-checkpoint) and is easy to miss in future dependency bumps.

[fercor-cisco]

🟠 major (security): Only langchain-core, langchain, and langsmith get explicit safe floors here. langgraph, langgraph-checkpoint, and langgraph-sdk (the subjects of VULN-88796, VULN-92530, VULN-92532) are left purely transitive. As shown in the poetry.lock diff, langgraph 1.2.9's own metadata floors langgraph-checkpoint at ">=4.1.0" — and 4.1.0 is the last version affected by VULN-92530 per the ticket. Since poetry.lock isn't published with the wheel, nothing here actually guarantees a consumer resolves langgraph-checkpoint>=4.1.1.

Suggested change

	langchain-core = { version = ">=1.3.3", optional = true }
	langchain = { version = ">=1.3.9,<2.0.0", optional = true }
	langsmith = { version = ">=0.8.0", optional = true }
	langchain-core = { version = ">=1.3.3", optional = true }
	langchain = { version = ">=1.3.9,<2.0.0", optional = true }
	langsmith = { version = ">=0.8.0", optional = true }
	langgraph = { version = ">=1.0.10", optional = true }
	langgraph-checkpoint = { version = ">=4.1.1", optional = true }
	langgraph-sdk = { version = ">=0.3.15", optional = true }

🤖 Generated by the Astra agent

[fercor-cisco]

I'm disregarding Claude's suggestion.

I don't think the SDK should mandate the versions that client code is using (unless they are incompatible).