langchain-core
The agent engineering platform.
View on Github
Activity
- Latest release
- 3d ago
- Total releases
- 304
- Cadence
- ~2 days
- Last 12 months
- 90
Reach
- Stars
- 146.3k
Details
- License
- MIT
- First release
- Nov 20, 2023
| Version | Released | |
|---|---|---|
1.6.3
patch
|
1.6.3
patch
Dependencies (10)
+ 2 more
Changelog
Compare changes
|
|
1.6.2
patch
|
1.6.2
patch
Dependencies (10)
+ 2 more
Changelog
Compare changes
|
|
1.6.1
patch
|
1.6.1
patch
Dependencies (10)
+ 2 more
Changelog
Compare changes
|
|
1.6.0
minor
|
1.6.0
minor
Dependencies (10)
+ 2 more
Changelog
Compare changes
|
|
1.5.6
patch
|
1.5.6
patch
Dependencies (10)
+ 2 more
Changelog
Compare changes
|
|
1.5.5
patch
|
1.5.5
patch
Dependencies (10)
+ 2 more
Changelog
Compare changes
|
|
1.5.4
patch
|
1.5.4
patch
Dependencies (9)
+ 1 more
Changelog
Compare changes
|
|
1.5.3
patch
|
1.5.3
patch
Dependencies (9)
+ 1 more
Changelog
Compare changes
|
|
1.5.2
patch
|
1.5.2
patch
Dependencies (9)
+ 1 more
Changelog
Compare changes
|
|
1.5.1
patch
|
1.5.1
patch
Dependencies (9)
+ 1 more
Changelog
Compare changes
|
|
1.5.0
minor
|
1.5.0
minor
Dependencies (9)
+ 1 more
Changelog
Compare changes
|
|
1.4.9
patch
|
1.4.9
patch
Dependencies (9)
+ 1 more
Changelog
Compare changes
|
|
1.4.8
patch
|
1.4.8
patch
Dependencies (9)
+ 1 more
Changelog
Compare changes
|
|
1.4.7
patch
|
1.4.7
patch
Dependencies (9)
+ 1 more
Changelog
Compare changes
|
|
1.4.6
patch
|
1.4.6
patch
Dependencies (9)
+ 1 more
Changelog
Compare changes
|
|
1.4.5
patch
|
1.4.5
patch
Dependencies (9)
+ 1 more
Changelog
Compare changes
|
|
1.4.4
patch
|
1.4.4
patch
Dependencies (9)
+ 1 more
Changelog
Compare changes
|
|
1.4.3
patch
|
1.4.3
patch
Dependencies (9)
+ 1 more
Changelog
Compare changes
|
|
1.4.2
patch
|
1.4.2
patch
Dependencies (9)
+ 1 more
Changelog
Compare changes
|
|
1.4.1
patch
|
1.4.1
patch
Dependencies (9)
+ 1 more
Changelog
Compare changes
|
|
1.4.0
minor
|
1.4.0
minor
Dependencies (9)
+ 1 more
Changelog
Compare changes
|
|
0.3.86
patch
2 CVEs
CVE-2026-26013
PYSEC-2026-2562
GHSA-2g6r-c272-w58r
Jul 13, 2026
LangChain affected by SSRF via image_url token counting in ChatOpenAI.get_num_tokens_from_messages
3.7
/ 10
Low
Network
High
None
None
Unchanged
None
None
Low
Server-Side Request Forgery (SSRF) in ChatOpenAI Image Token CountingSummaryThe SeverityLow - The vulnerability allows SSRF attacks but has limited impact due to:
ImpactAn attacker who can control image URLs passed to
Note: This vulnerability occurs during token counting, which may happen outside of model invocation (e.g., in logging, metrics, or token budgeting flows). DetailsThe vulnerable code path:
File: PatchesThe vulnerability has been patched in The patch adds:
WorkaroundsIf you cannot upgrade immediately:
Affected versions
0.0.1
0.0.10
0.0.11
0.0.12
0.0.13
0.0.13rc1
0.0.13rc2
0.0.2
0.0.3
0.0.4
0.0.5
0.0.6
+ 241 more Show less
0.0.7
0.0.8
0.0.9
0.1.0
0.1.1
0.1.10
0.1.11
0.1.12
0.1.12rc1
0.1.13
0.1.14
0.1.15
0.1.15rc1
0.1.15rc2
0.1.16
0.1.17
0.1.18
0.1.19
0.1.2
0.1.20
0.1.21
0.1.22
0.1.23
0.1.24
0.1.25
0.1.26
0.1.27
0.1.28
0.1.29
0.1.3
0.1.30
0.1.31
0.1.32
0.1.33
0.1.33rc1
0.1.34
0.1.35
0.1.36
0.1.37
0.1.38
0.1.39
0.1.4
0.1.40
0.1.41
0.1.42
0.1.42rc1
0.1.43
0.1.44
0.1.45
0.1.46
0.1.47
0.1.47rc1
0.1.48
0.1.49
0.1.5
0.1.50
0.1.51
0.1.52
0.1.53
0.1.6
0.1.7
0.1.8
0.1.9
0.2.0
0.2.0rc1
0.2.1
0.2.10
0.2.11
0.2.12
0.2.13
0.2.15
0.2.16
0.2.17
0.2.18
0.2.19
0.2.2
0.2.20
0.2.21
0.2.22
0.2.23
0.2.24
0.2.25
0.2.26
0.2.27
0.2.28
0.2.29
0.2.29rc1
0.2.2rc1
0.2.3
0.2.30
0.2.31
0.2.32
0.2.33
0.2.34
0.2.35
0.2.36
0.2.37
0.2.38
0.2.39
0.2.4
0.2.40
0.2.41
0.2.42
0.2.43
0.2.5
0.2.6
0.2.7
0.2.8
0.2.9
0.3.0
0.3.0.dev0
0.3.0.dev1
0.3.0.dev2
0.3.0.dev3
0.3.0.dev4
0.3.0.dev5
0.3.1
0.3.10
0.3.11
0.3.12
0.3.13
0.3.14
0.3.15
0.3.16
0.3.17
0.3.18
0.3.19
0.3.2
0.3.20
0.3.21
0.3.22
0.3.23
0.3.24
0.3.25
0.3.26
0.3.27
0.3.28
0.3.29
0.3.3
0.3.30
0.3.31
0.3.32
0.3.33
0.3.34
0.3.34rc1
0.3.34rc2
0.3.35
0.3.36
0.3.37
0.3.38
0.3.39
0.3.4
0.3.40
0.3.41
0.3.42
0.3.43
0.3.44
0.3.45
0.3.45rc1
0.3.46
0.3.47
0.3.48
0.3.49
0.3.5
0.3.50
0.3.51
0.3.52
0.3.53
0.3.54
0.3.55
0.3.56
0.3.56rc1
0.3.57
0.3.58
0.3.59
0.3.6
0.3.60
0.3.61
0.3.62
0.3.63
0.3.64
0.3.65
0.3.66
0.3.67
0.3.68
0.3.69
0.3.7
0.3.70
0.3.71
0.3.72
0.3.73
0.3.74
0.3.75
0.3.76
0.3.77
0.3.78
0.3.79
0.3.8
0.3.80
0.3.81
0.3.82
0.3.83
0.3.84
0.3.85
0.3.86
0.3.9
0.4.0.dev0
1.0.0
1.0.0a1
1.0.0a2
1.0.0a3
1.0.0a4
1.0.0a5
1.0.0a6
1.0.0a7
1.0.0a8
1.0.0rc1
1.0.0rc2
1.0.0rc3
1.0.1
1.0.2
1.0.3
1.0.4
1.0.5
1.0.6
1.0.7
1.1.0
1.1.1
1.1.2
1.1.3
1.2.0
1.2.1
1.2.10
1.2.2
1.2.3
1.2.4
1.2.5
1.2.6
1.2.7
1.2.8
1.2.9
Fixed in
1.2.11
References
Updated Jul 13, 2026 · Source: OSV.dev
CVE-2026-34070
PYSEC-2026-2193
GHSA-qh6h-p6c9-ff54
Mar 31, 2026
7.5
/ 10
High
Network
Low
None
None
Unchanged
High
None
None
LangChain is a framework for building agents and LLM-powered applications. Prior to version 1.2.22, multiple functions in langchain_core.prompts.loading read files from paths embedded in deserialized config dicts without validating against directory traversal or absolute path injection. When an application passes user-influenced prompt configurations to load_prompt() or load_prompt_from_config(), an attacker can read arbitrary files on the host filesystem, constrained only by file-extension checks (.txt for templates, .json/.yaml for examples). This issue has been patched in version 1.2.22. Affected versions
0.0.1
0.0.10
0.0.11
0.0.12
0.0.13
0.0.13rc1
0.0.13rc2
0.0.2
0.0.3
0.0.4
0.0.5
0.0.6
+ 252 more Show less
0.0.7
0.0.8
0.0.9
0.1.0
0.1.1
0.1.10
0.1.11
0.1.12
0.1.12rc1
0.1.13
0.1.14
0.1.15
0.1.15rc1
0.1.15rc2
0.1.16
0.1.17
0.1.18
0.1.19
0.1.2
0.1.20
0.1.21
0.1.22
0.1.23
0.1.24
0.1.25
0.1.26
0.1.27
0.1.28
0.1.29
0.1.3
0.1.30
0.1.31
0.1.32
0.1.33
0.1.33rc1
0.1.34
0.1.35
0.1.36
0.1.37
0.1.38
0.1.39
0.1.4
0.1.40
0.1.41
0.1.42
0.1.42rc1
0.1.43
0.1.44
0.1.45
0.1.46
0.1.47
0.1.47rc1
0.1.48
0.1.49
0.1.5
0.1.50
0.1.51
0.1.52
0.1.53
0.1.6
0.1.7
0.1.8
0.1.9
0.2.0
0.2.0rc1
0.2.1
0.2.10
0.2.11
0.2.12
0.2.13
0.2.15
0.2.16
0.2.17
0.2.18
0.2.19
0.2.2
0.2.20
0.2.21
0.2.22
0.2.23
0.2.24
0.2.25
0.2.26
0.2.27
0.2.28
0.2.29
0.2.29rc1
0.2.2rc1
0.2.3
0.2.30
0.2.31
0.2.32
0.2.33
0.2.34
0.2.35
0.2.36
0.2.37
0.2.38
0.2.39
0.2.4
0.2.40
0.2.41
0.2.42
0.2.43
0.2.5
0.2.6
0.2.7
0.2.8
0.2.9
0.3.0
0.3.0.dev0
0.3.0.dev1
0.3.0.dev2
0.3.0.dev3
0.3.0.dev4
0.3.0.dev5
0.3.1
0.3.10
0.3.11
0.3.12
0.3.13
0.3.14
0.3.15
0.3.16
0.3.17
0.3.18
0.3.19
0.3.2
0.3.20
0.3.21
0.3.22
0.3.23
0.3.24
0.3.25
0.3.26
0.3.27
0.3.28
0.3.29
0.3.3
0.3.30
0.3.31
0.3.32
0.3.33
0.3.34
0.3.34rc1
0.3.34rc2
0.3.35
0.3.36
0.3.37
0.3.38
0.3.39
0.3.4
0.3.40
0.3.41
0.3.42
0.3.43
0.3.44
0.3.45
0.3.45rc1
0.3.46
0.3.47
0.3.48
0.3.49
0.3.5
0.3.50
0.3.51
0.3.52
0.3.53
0.3.54
0.3.55
0.3.56
0.3.56rc1
0.3.57
0.3.58
0.3.59
0.3.6
0.3.60
0.3.61
0.3.62
0.3.63
0.3.64
0.3.65
0.3.66
0.3.67
0.3.68
0.3.69
0.3.7
0.3.70
0.3.71
0.3.72
0.3.73
0.3.74
0.3.75
0.3.76
0.3.77
0.3.78
0.3.79
0.3.8
0.3.80
0.3.81
0.3.82
0.3.83
0.3.84
0.3.85
0.3.86
0.3.9
0.4.0.dev0
1.0.0
1.0.0a1
1.0.0a2
1.0.0a3
1.0.0a4
1.0.0a5
1.0.0a6
1.0.0a7
1.0.0a8
1.0.0rc1
1.0.0rc2
1.0.0rc3
1.0.1
1.0.2
1.0.3
1.0.4
1.0.5
1.0.6
1.0.7
1.1.0
1.1.1
1.1.2
1.1.3
1.2.0
1.2.1
1.2.10
1.2.11
1.2.12
1.2.13
1.2.14
1.2.15
1.2.16
1.2.17
1.2.18
1.2.19
1.2.2
1.2.20
1.2.21
1.2.3
1.2.4
1.2.5
1.2.6
1.2.7
1.2.8
1.2.9
Fixed in
1.2.22
References
Updated Jul 13, 2026 · Source: OSV.dev |
0.3.86
patch
Dependencies (8)
Changelog
Compare changes
|
|
0.3.85
patch
2 CVEs
CVE-2026-26013
PYSEC-2026-2562
GHSA-2g6r-c272-w58r
Jul 13, 2026
LangChain affected by SSRF via image_url token counting in ChatOpenAI.get_num_tokens_from_messages
3.7
/ 10
Low
Network
High
None
None
Unchanged
None
None
Low
Server-Side Request Forgery (SSRF) in ChatOpenAI Image Token CountingSummaryThe SeverityLow - The vulnerability allows SSRF attacks but has limited impact due to:
ImpactAn attacker who can control image URLs passed to
Note: This vulnerability occurs during token counting, which may happen outside of model invocation (e.g., in logging, metrics, or token budgeting flows). DetailsThe vulnerable code path:
File: PatchesThe vulnerability has been patched in The patch adds:
WorkaroundsIf you cannot upgrade immediately:
Affected versions
0.0.1
0.0.10
0.0.11
0.0.12
0.0.13
0.0.13rc1
0.0.13rc2
0.0.2
0.0.3
0.0.4
0.0.5
0.0.6
+ 241 more Show less
0.0.7
0.0.8
0.0.9
0.1.0
0.1.1
0.1.10
0.1.11
0.1.12
0.1.12rc1
0.1.13
0.1.14
0.1.15
0.1.15rc1
0.1.15rc2
0.1.16
0.1.17
0.1.18
0.1.19
0.1.2
0.1.20
0.1.21
0.1.22
0.1.23
0.1.24
0.1.25
0.1.26
0.1.27
0.1.28
0.1.29
0.1.3
0.1.30
0.1.31
0.1.32
0.1.33
0.1.33rc1
0.1.34
0.1.35
0.1.36
0.1.37
0.1.38
0.1.39
0.1.4
0.1.40
0.1.41
0.1.42
0.1.42rc1
0.1.43
0.1.44
0.1.45
0.1.46
0.1.47
0.1.47rc1
0.1.48
0.1.49
0.1.5
0.1.50
0.1.51
0.1.52
0.1.53
0.1.6
0.1.7
0.1.8
0.1.9
0.2.0
0.2.0rc1
0.2.1
0.2.10
0.2.11
0.2.12
0.2.13
0.2.15
0.2.16
0.2.17
0.2.18
0.2.19
0.2.2
0.2.20
0.2.21
0.2.22
0.2.23
0.2.24
0.2.25
0.2.26
0.2.27
0.2.28
0.2.29
0.2.29rc1
0.2.2rc1
0.2.3
0.2.30
0.2.31
0.2.32
0.2.33
0.2.34
0.2.35
0.2.36
0.2.37
0.2.38
0.2.39
0.2.4
0.2.40
0.2.41
0.2.42
0.2.43
0.2.5
0.2.6
0.2.7
0.2.8
0.2.9
0.3.0
0.3.0.dev0
0.3.0.dev1
0.3.0.dev2
0.3.0.dev3
0.3.0.dev4
0.3.0.dev5
0.3.1
0.3.10
0.3.11
0.3.12
0.3.13
0.3.14
0.3.15
0.3.16
0.3.17
0.3.18
0.3.19
0.3.2
0.3.20
0.3.21
0.3.22
0.3.23
0.3.24
0.3.25
0.3.26
0.3.27
0.3.28
0.3.29
0.3.3
0.3.30
0.3.31
0.3.32
0.3.33
0.3.34
0.3.34rc1
0.3.34rc2
0.3.35
0.3.36
0.3.37
0.3.38
0.3.39
0.3.4
0.3.40
0.3.41
0.3.42
0.3.43
0.3.44
0.3.45
0.3.45rc1
0.3.46
0.3.47
0.3.48
0.3.49
0.3.5
0.3.50
0.3.51
0.3.52
0.3.53
0.3.54
0.3.55
0.3.56
0.3.56rc1
0.3.57
0.3.58
0.3.59
0.3.6
0.3.60
0.3.61
0.3.62
0.3.63
0.3.64
0.3.65
0.3.66
0.3.67
0.3.68
0.3.69
0.3.7
0.3.70
0.3.71
0.3.72
0.3.73
0.3.74
0.3.75
0.3.76
0.3.77
0.3.78
0.3.79
0.3.8
0.3.80
0.3.81
0.3.82
0.3.83
0.3.84
0.3.85
0.3.86
0.3.9
0.4.0.dev0
1.0.0
1.0.0a1
1.0.0a2
1.0.0a3
1.0.0a4
1.0.0a5
1.0.0a6
1.0.0a7
1.0.0a8
1.0.0rc1
1.0.0rc2
1.0.0rc3
1.0.1
1.0.2
1.0.3
1.0.4
1.0.5
1.0.6
1.0.7
1.1.0
1.1.1
1.1.2
1.1.3
1.2.0
1.2.1
1.2.10
1.2.2
1.2.3
1.2.4
1.2.5
1.2.6
1.2.7
1.2.8
1.2.9
Fixed in
1.2.11
References
Updated Jul 13, 2026 · Source: OSV.dev
CVE-2026-34070
PYSEC-2026-2193
GHSA-qh6h-p6c9-ff54
Mar 31, 2026
7.5
/ 10
High
Network
Low
None
None
Unchanged
High
None
None
LangChain is a framework for building agents and LLM-powered applications. Prior to version 1.2.22, multiple functions in langchain_core.prompts.loading read files from paths embedded in deserialized config dicts without validating against directory traversal or absolute path injection. When an application passes user-influenced prompt configurations to load_prompt() or load_prompt_from_config(), an attacker can read arbitrary files on the host filesystem, constrained only by file-extension checks (.txt for templates, .json/.yaml for examples). This issue has been patched in version 1.2.22. Affected versions
0.0.1
0.0.10
0.0.11
0.0.12
0.0.13
0.0.13rc1
0.0.13rc2
0.0.2
0.0.3
0.0.4
0.0.5
0.0.6
+ 252 more Show less
0.0.7
0.0.8
0.0.9
0.1.0
0.1.1
0.1.10
0.1.11
0.1.12
0.1.12rc1
0.1.13
0.1.14
0.1.15
0.1.15rc1
0.1.15rc2
0.1.16
0.1.17
0.1.18
0.1.19
0.1.2
0.1.20
0.1.21
0.1.22
0.1.23
0.1.24
0.1.25
0.1.26
0.1.27
0.1.28
0.1.29
0.1.3
0.1.30
0.1.31
0.1.32
0.1.33
0.1.33rc1
0.1.34
0.1.35
0.1.36
0.1.37
0.1.38
0.1.39
0.1.4
0.1.40
0.1.41
0.1.42
0.1.42rc1
0.1.43
0.1.44
0.1.45
0.1.46
0.1.47
0.1.47rc1
0.1.48
0.1.49
0.1.5
0.1.50
0.1.51
0.1.52
0.1.53
0.1.6
0.1.7
0.1.8
0.1.9
0.2.0
0.2.0rc1
0.2.1
0.2.10
0.2.11
0.2.12
0.2.13
0.2.15
0.2.16
0.2.17
0.2.18
0.2.19
0.2.2
0.2.20
0.2.21
0.2.22
0.2.23
0.2.24
0.2.25
0.2.26
0.2.27
0.2.28
0.2.29
0.2.29rc1
0.2.2rc1
0.2.3
0.2.30
0.2.31
0.2.32
0.2.33
0.2.34
0.2.35
0.2.36
0.2.37
0.2.38
0.2.39
0.2.4
0.2.40
0.2.41
0.2.42
0.2.43
0.2.5
0.2.6
0.2.7
0.2.8
0.2.9
0.3.0
0.3.0.dev0
0.3.0.dev1
0.3.0.dev2
0.3.0.dev3
0.3.0.dev4
0.3.0.dev5
0.3.1
0.3.10
0.3.11
0.3.12
0.3.13
0.3.14
0.3.15
0.3.16
0.3.17
0.3.18
0.3.19
0.3.2
0.3.20
0.3.21
0.3.22
0.3.23
0.3.24
0.3.25
0.3.26
0.3.27
0.3.28
0.3.29
0.3.3
0.3.30
0.3.31
0.3.32
0.3.33
0.3.34
0.3.34rc1
0.3.34rc2
0.3.35
0.3.36
0.3.37
0.3.38
0.3.39
0.3.4
0.3.40
0.3.41
0.3.42
0.3.43
0.3.44
0.3.45
0.3.45rc1
0.3.46
0.3.47
0.3.48
0.3.49
0.3.5
0.3.50
0.3.51
0.3.52
0.3.53
0.3.54
0.3.55
0.3.56
0.3.56rc1
0.3.57
0.3.58
0.3.59
0.3.6
0.3.60
0.3.61
0.3.62
0.3.63
0.3.64
0.3.65
0.3.66
0.3.67
0.3.68
0.3.69
0.3.7
0.3.70
0.3.71
0.3.72
0.3.73
0.3.74
0.3.75
0.3.76
0.3.77
0.3.78
0.3.79
0.3.8
0.3.80
0.3.81
0.3.82
0.3.83
0.3.84
0.3.85
0.3.86
0.3.9
0.4.0.dev0
1.0.0
1.0.0a1
1.0.0a2
1.0.0a3
1.0.0a4
1.0.0a5
1.0.0a6
1.0.0a7
1.0.0a8
1.0.0rc1
1.0.0rc2
1.0.0rc3
1.0.1
1.0.2
1.0.3
1.0.4
1.0.5
1.0.6
1.0.7
1.1.0
1.1.1
1.1.2
1.1.3
1.2.0
1.2.1
1.2.10
1.2.11
1.2.12
1.2.13
1.2.14
1.2.15
1.2.16
1.2.17
1.2.18
1.2.19
1.2.2
1.2.20
1.2.21
1.2.3
1.2.4
1.2.5
1.2.6
1.2.7
1.2.8
1.2.9
Fixed in
1.2.22
References
Updated Jul 13, 2026 · Source: OSV.dev |
0.3.85
patch
Dependencies (8)
Changelog
Compare changes
|
|
1.3.3
patch
|
1.3.3
patch
Dependencies (9)
+ 1 more
Changelog
Compare changes
|
|
1.4.0a2
pre
|
1.4.0a2
pre
Dependencies (9)
+ 1 more
Changelog
Compare changes
|
|
1.4.0a1
pre
|
1.4.0a1
pre
Dependencies (9)
+ 1 more
Changelog
Compare changes
|
|
1.3.2
patch
1 CVE
CVE-2026-44843
PYSEC-2026-2564
GHSA-pjwx-r37v-7724
Jul 13, 2026
LangChain vulnerable to unsafe deserialization of attacker-controlled objects through overly broad `load()` allowlists
8.2
/ 10
High
Network
Low
None
None
Unchanged
High
Low
None
LangChain contains older runtime code paths that deserialize run inputs, run outputs, or other application-controlled payloads using overly broad object allowlists. These paths may call Applications are exposed only when all of the following are true:
Known affected runtime surfaces include:
Related unsafe deserialization patterns may also affect applications that explicitly load serialized LangChain prompt or runnable objects from untrusted sources, including shared prompt stores, Hub artifacts with model configuration, or other application-controlled serialization stores. Applications that validate incoming requests against a fixed schema, such as coercing user input to a plain string or message-content field before invoking LangChain, are unlikely to expose this deserialization primitive. This release also fixes a related secret-marker validation bypass in the serialization and deserialization layer ( ImpactAn attacker who can submit untrusted structured input to an affected application, and have that structure preserved in LangChain run data, may be able to inject LangChain serialized constructor payloads such as: If this payload reaches a broad Realistic impacts include:
RemediationLangChain will deprecate the affected APIs as part of this fix:
These are older code paths that are no longer recommended for new applications. They were not previously marked as deprecated, but recent LangChain documentation has primarily directed users toward newer streaming and memory patterns, including the Separately, LangChain will update This release also fixes a related secret-marker validation bypass in the serialization and deserialization layer ( Guidance for
|
1.3.2
patch
Dependencies (9)
+ 1 more
Changelog
Compare changes
|
|
1.3.1
patch
1 CVE
CVE-2026-44843
PYSEC-2026-2564
GHSA-pjwx-r37v-7724
Jul 13, 2026
LangChain vulnerable to unsafe deserialization of attacker-controlled objects through overly broad `load()` allowlists
8.2
/ 10
High
Network
Low
None
None
Unchanged
High
Low
None
LangChain contains older runtime code paths that deserialize run inputs, run outputs, or other application-controlled payloads using overly broad object allowlists. These paths may call Applications are exposed only when all of the following are true:
Known affected runtime surfaces include:
Related unsafe deserialization patterns may also affect applications that explicitly load serialized LangChain prompt or runnable objects from untrusted sources, including shared prompt stores, Hub artifacts with model configuration, or other application-controlled serialization stores. Applications that validate incoming requests against a fixed schema, such as coercing user input to a plain string or message-content field before invoking LangChain, are unlikely to expose this deserialization primitive. This release also fixes a related secret-marker validation bypass in the serialization and deserialization layer ( ImpactAn attacker who can submit untrusted structured input to an affected application, and have that structure preserved in LangChain run data, may be able to inject LangChain serialized constructor payloads such as: If this payload reaches a broad Realistic impacts include:
RemediationLangChain will deprecate the affected APIs as part of this fix:
These are older code paths that are no longer recommended for new applications. They were not previously marked as deprecated, but recent LangChain documentation has primarily directed users toward newer streaming and memory patterns, including the Separately, LangChain will update This release also fixes a related secret-marker validation bypass in the serialization and deserialization layer ( Guidance for
|
1.3.1
patch
Dependencies (8)
Changelog
Compare changes
|
|
1.3.0
minor
1 CVE
CVE-2026-44843
PYSEC-2026-2564
GHSA-pjwx-r37v-7724
Jul 13, 2026
LangChain vulnerable to unsafe deserialization of attacker-controlled objects through overly broad `load()` allowlists
8.2
/ 10
High
Network
Low
None
None
Unchanged
High
Low
None
LangChain contains older runtime code paths that deserialize run inputs, run outputs, or other application-controlled payloads using overly broad object allowlists. These paths may call Applications are exposed only when all of the following are true:
Known affected runtime surfaces include:
Related unsafe deserialization patterns may also affect applications that explicitly load serialized LangChain prompt or runnable objects from untrusted sources, including shared prompt stores, Hub artifacts with model configuration, or other application-controlled serialization stores. Applications that validate incoming requests against a fixed schema, such as coercing user input to a plain string or message-content field before invoking LangChain, are unlikely to expose this deserialization primitive. This release also fixes a related secret-marker validation bypass in the serialization and deserialization layer ( ImpactAn attacker who can submit untrusted structured input to an affected application, and have that structure preserved in LangChain run data, may be able to inject LangChain serialized constructor payloads such as: If this payload reaches a broad Realistic impacts include:
RemediationLangChain will deprecate the affected APIs as part of this fix:
These are older code paths that are no longer recommended for new applications. They were not previously marked as deprecated, but recent LangChain documentation has primarily directed users toward newer streaming and memory patterns, including the Separately, LangChain will update This release also fixes a related secret-marker validation bypass in the serialization and deserialization layer ( Guidance for
|
1.3.0
minor
Dependencies (8)
Changelog
Compare changes
|
|
1.3.0a3
pre
1 CVE
CVE-2026-44843
PYSEC-2026-2564
GHSA-pjwx-r37v-7724
Jul 13, 2026
LangChain vulnerable to unsafe deserialization of attacker-controlled objects through overly broad `load()` allowlists
8.2
/ 10
High
Network
Low
None
None
Unchanged
High
Low
None
LangChain contains older runtime code paths that deserialize run inputs, run outputs, or other application-controlled payloads using overly broad object allowlists. These paths may call Applications are exposed only when all of the following are true:
Known affected runtime surfaces include:
Related unsafe deserialization patterns may also affect applications that explicitly load serialized LangChain prompt or runnable objects from untrusted sources, including shared prompt stores, Hub artifacts with model configuration, or other application-controlled serialization stores. Applications that validate incoming requests against a fixed schema, such as coercing user input to a plain string or message-content field before invoking LangChain, are unlikely to expose this deserialization primitive. This release also fixes a related secret-marker validation bypass in the serialization and deserialization layer ( ImpactAn attacker who can submit untrusted structured input to an affected application, and have that structure preserved in LangChain run data, may be able to inject LangChain serialized constructor payloads such as: If this payload reaches a broad Realistic impacts include:
RemediationLangChain will deprecate the affected APIs as part of this fix:
These are older code paths that are no longer recommended for new applications. They were not previously marked as deprecated, but recent LangChain documentation has primarily directed users toward newer streaming and memory patterns, including the Separately, LangChain will update This release also fixes a related secret-marker validation bypass in the serialization and deserialization layer ( Guidance for
|
1.3.0a3
pre
Dependencies (8)
Changelog
Compare changes
|
|
1.2.31
patch
1 CVE
CVE-2026-44843
PYSEC-2026-2564
GHSA-pjwx-r37v-7724
Jul 13, 2026
LangChain vulnerable to unsafe deserialization of attacker-controlled objects through overly broad `load()` allowlists
8.2
/ 10
High
Network
Low
None
None
Unchanged
High
Low
None
LangChain contains older runtime code paths that deserialize run inputs, run outputs, or other application-controlled payloads using overly broad object allowlists. These paths may call Applications are exposed only when all of the following are true:
Known affected runtime surfaces include:
Related unsafe deserialization patterns may also affect applications that explicitly load serialized LangChain prompt or runnable objects from untrusted sources, including shared prompt stores, Hub artifacts with model configuration, or other application-controlled serialization stores. Applications that validate incoming requests against a fixed schema, such as coercing user input to a plain string or message-content field before invoking LangChain, are unlikely to expose this deserialization primitive. This release also fixes a related secret-marker validation bypass in the serialization and deserialization layer ( ImpactAn attacker who can submit untrusted structured input to an affected application, and have that structure preserved in LangChain run data, may be able to inject LangChain serialized constructor payloads such as: If this payload reaches a broad Realistic impacts include:
RemediationLangChain will deprecate the affected APIs as part of this fix:
These are older code paths that are no longer recommended for new applications. They were not previously marked as deprecated, but recent LangChain documentation has primarily directed users toward newer streaming and memory patterns, including the Separately, LangChain will update This release also fixes a related secret-marker validation bypass in the serialization and deserialization layer ( Guidance for
|
1.2.31
patch
Dependencies (8)
Changelog
Compare changes
|
|
1.2.30
patch
1 CVE
CVE-2026-44843
PYSEC-2026-2564
GHSA-pjwx-r37v-7724
Jul 13, 2026
LangChain vulnerable to unsafe deserialization of attacker-controlled objects through overly broad `load()` allowlists
8.2
/ 10
High
Network
Low
None
None
Unchanged
High
Low
None
LangChain contains older runtime code paths that deserialize run inputs, run outputs, or other application-controlled payloads using overly broad object allowlists. These paths may call Applications are exposed only when all of the following are true:
Known affected runtime surfaces include:
Related unsafe deserialization patterns may also affect applications that explicitly load serialized LangChain prompt or runnable objects from untrusted sources, including shared prompt stores, Hub artifacts with model configuration, or other application-controlled serialization stores. Applications that validate incoming requests against a fixed schema, such as coercing user input to a plain string or message-content field before invoking LangChain, are unlikely to expose this deserialization primitive. This release also fixes a related secret-marker validation bypass in the serialization and deserialization layer ( ImpactAn attacker who can submit untrusted structured input to an affected application, and have that structure preserved in LangChain run data, may be able to inject LangChain serialized constructor payloads such as: If this payload reaches a broad Realistic impacts include:
RemediationLangChain will deprecate the affected APIs as part of this fix:
These are older code paths that are no longer recommended for new applications. They were not previously marked as deprecated, but recent LangChain documentation has primarily directed users toward newer streaming and memory patterns, including the Separately, LangChain will update This release also fixes a related secret-marker validation bypass in the serialization and deserialization layer ( Guidance for
|
1.2.30
patch
Dependencies (8)
Changelog
Compare changes
|
|
1.2.29
patch
1 CVE
CVE-2026-44843
PYSEC-2026-2564
GHSA-pjwx-r37v-7724
Jul 13, 2026
LangChain vulnerable to unsafe deserialization of attacker-controlled objects through overly broad `load()` allowlists
8.2
/ 10
High
Network
Low
None
None
Unchanged
High
Low
None
LangChain contains older runtime code paths that deserialize run inputs, run outputs, or other application-controlled payloads using overly broad object allowlists. These paths may call Applications are exposed only when all of the following are true:
Known affected runtime surfaces include:
Related unsafe deserialization patterns may also affect applications that explicitly load serialized LangChain prompt or runnable objects from untrusted sources, including shared prompt stores, Hub artifacts with model configuration, or other application-controlled serialization stores. Applications that validate incoming requests against a fixed schema, such as coercing user input to a plain string or message-content field before invoking LangChain, are unlikely to expose this deserialization primitive. This release also fixes a related secret-marker validation bypass in the serialization and deserialization layer ( ImpactAn attacker who can submit untrusted structured input to an affected application, and have that structure preserved in LangChain run data, may be able to inject LangChain serialized constructor payloads such as: If this payload reaches a broad Realistic impacts include:
RemediationLangChain will deprecate the affected APIs as part of this fix:
These are older code paths that are no longer recommended for new applications. They were not previously marked as deprecated, but recent LangChain documentation has primarily directed users toward newer streaming and memory patterns, including the Separately, LangChain will update This release also fixes a related secret-marker validation bypass in the serialization and deserialization layer ( Guidance for
|
1.2.29
patch
Dependencies (8)
Changelog
Compare changes
|
|
1.3.0a2
pre
1 CVE
CVE-2026-44843
PYSEC-2026-2564
GHSA-pjwx-r37v-7724
Jul 13, 2026
LangChain vulnerable to unsafe deserialization of attacker-controlled objects through overly broad `load()` allowlists
8.2
/ 10
High
Network
Low
None
None
Unchanged
High
Low
None
LangChain contains older runtime code paths that deserialize run inputs, run outputs, or other application-controlled payloads using overly broad object allowlists. These paths may call Applications are exposed only when all of the following are true:
Known affected runtime surfaces include:
Related unsafe deserialization patterns may also affect applications that explicitly load serialized LangChain prompt or runnable objects from untrusted sources, including shared prompt stores, Hub artifacts with model configuration, or other application-controlled serialization stores. Applications that validate incoming requests against a fixed schema, such as coercing user input to a plain string or message-content field before invoking LangChain, are unlikely to expose this deserialization primitive. This release also fixes a related secret-marker validation bypass in the serialization and deserialization layer ( ImpactAn attacker who can submit untrusted structured input to an affected application, and have that structure preserved in LangChain run data, may be able to inject LangChain serialized constructor payloads such as: If this payload reaches a broad Realistic impacts include:
RemediationLangChain will deprecate the affected APIs as part of this fix:
These are older code paths that are no longer recommended for new applications. They were not previously marked as deprecated, but recent LangChain documentation has primarily directed users toward newer streaming and memory patterns, including the Separately, LangChain will update This release also fixes a related secret-marker validation bypass in the serialization and deserialization layer ( Guidance for
|
1.3.0a2
pre
Dependencies (8)
Changelog
Compare changes
|
|
1.3.0a1
pre
1 CVE
CVE-2026-44843
PYSEC-2026-2564
GHSA-pjwx-r37v-7724
Jul 13, 2026
LangChain vulnerable to unsafe deserialization of attacker-controlled objects through overly broad `load()` allowlists
8.2
/ 10
High
Network
Low
None
None
Unchanged
High
Low
None
LangChain contains older runtime code paths that deserialize run inputs, run outputs, or other application-controlled payloads using overly broad object allowlists. These paths may call Applications are exposed only when all of the following are true:
Known affected runtime surfaces include:
Related unsafe deserialization patterns may also affect applications that explicitly load serialized LangChain prompt or runnable objects from untrusted sources, including shared prompt stores, Hub artifacts with model configuration, or other application-controlled serialization stores. Applications that validate incoming requests against a fixed schema, such as coercing user input to a plain string or message-content field before invoking LangChain, are unlikely to expose this deserialization primitive. This release also fixes a related secret-marker validation bypass in the serialization and deserialization layer ( ImpactAn attacker who can submit untrusted structured input to an affected application, and have that structure preserved in LangChain run data, may be able to inject LangChain serialized constructor payloads such as: If this payload reaches a broad Realistic impacts include:
RemediationLangChain will deprecate the affected APIs as part of this fix:
These are older code paths that are no longer recommended for new applications. They were not previously marked as deprecated, but recent LangChain documentation has primarily directed users toward newer streaming and memory patterns, including the Separately, LangChain will update This release also fixes a related secret-marker validation bypass in the serialization and deserialization layer ( Guidance for
|
1.3.0a1
pre
Dependencies (8)
Changelog
Compare changes
|
|
0.3.84
patch
3 CVEs
CVE-2026-44843
PYSEC-2026-2564
GHSA-pjwx-r37v-7724
Jul 13, 2026
LangChain vulnerable to unsafe deserialization of attacker-controlled objects through overly broad `load()` allowlists
8.2
/ 10
High
Network
Low
None
None
Unchanged
High
Low
None
LangChain contains older runtime code paths that deserialize run inputs, run outputs, or other application-controlled payloads using overly broad object allowlists. These paths may call Applications are exposed only when all of the following are true:
Known affected runtime surfaces include:
Related unsafe deserialization patterns may also affect applications that explicitly load serialized LangChain prompt or runnable objects from untrusted sources, including shared prompt stores, Hub artifacts with model configuration, or other application-controlled serialization stores. Applications that validate incoming requests against a fixed schema, such as coercing user input to a plain string or message-content field before invoking LangChain, are unlikely to expose this deserialization primitive. This release also fixes a related secret-marker validation bypass in the serialization and deserialization layer ( ImpactAn attacker who can submit untrusted structured input to an affected application, and have that structure preserved in LangChain run data, may be able to inject LangChain serialized constructor payloads such as: If this payload reaches a broad Realistic impacts include:
RemediationLangChain will deprecate the affected APIs as part of this fix:
These are older code paths that are no longer recommended for new applications. They were not previously marked as deprecated, but recent LangChain documentation has primarily directed users toward newer streaming and memory patterns, including the Separately, LangChain will update This release also fixes a related secret-marker validation bypass in the serialization and deserialization layer ( Guidance for
|
0.3.84
patch
Dependencies (8)
Changelog
Compare changes
|
|
1.2.28
patch
1 CVE
CVE-2026-44843
PYSEC-2026-2564
GHSA-pjwx-r37v-7724
Jul 13, 2026
LangChain vulnerable to unsafe deserialization of attacker-controlled objects through overly broad `load()` allowlists
8.2
/ 10
High
Network
Low
None
None
Unchanged
High
Low
None
LangChain contains older runtime code paths that deserialize run inputs, run outputs, or other application-controlled payloads using overly broad object allowlists. These paths may call Applications are exposed only when all of the following are true:
Known affected runtime surfaces include:
Related unsafe deserialization patterns may also affect applications that explicitly load serialized LangChain prompt or runnable objects from untrusted sources, including shared prompt stores, Hub artifacts with model configuration, or other application-controlled serialization stores. Applications that validate incoming requests against a fixed schema, such as coercing user input to a plain string or message-content field before invoking LangChain, are unlikely to expose this deserialization primitive. This release also fixes a related secret-marker validation bypass in the serialization and deserialization layer ( ImpactAn attacker who can submit untrusted structured input to an affected application, and have that structure preserved in LangChain run data, may be able to inject LangChain serialized constructor payloads such as: If this payload reaches a broad Realistic impacts include:
RemediationLangChain will deprecate the affected APIs as part of this fix:
These are older code paths that are no longer recommended for new applications. They were not previously marked as deprecated, but recent LangChain documentation has primarily directed users toward newer streaming and memory patterns, including the Separately, LangChain will update This release also fixes a related secret-marker validation bypass in the serialization and deserialization layer ( Guidance for
|
1.2.28
patch
Dependencies (8)
Changelog
Compare changes
|
|
1.2.27
patch
2 CVEs
CVE-2026-44843
PYSEC-2026-2564
GHSA-pjwx-r37v-7724
Jul 13, 2026
LangChain vulnerable to unsafe deserialization of attacker-controlled objects through overly broad `load()` allowlists
8.2
/ 10
High
Network
Low
None
None
Unchanged
High
Low
None
LangChain contains older runtime code paths that deserialize run inputs, run outputs, or other application-controlled payloads using overly broad object allowlists. These paths may call Applications are exposed only when all of the following are true:
Known affected runtime surfaces include:
Related unsafe deserialization patterns may also affect applications that explicitly load serialized LangChain prompt or runnable objects from untrusted sources, including shared prompt stores, Hub artifacts with model configuration, or other application-controlled serialization stores. Applications that validate incoming requests against a fixed schema, such as coercing user input to a plain string or message-content field before invoking LangChain, are unlikely to expose this deserialization primitive. This release also fixes a related secret-marker validation bypass in the serialization and deserialization layer ( ImpactAn attacker who can submit untrusted structured input to an affected application, and have that structure preserved in LangChain run data, may be able to inject LangChain serialized constructor payloads such as: If this payload reaches a broad Realistic impacts include:
RemediationLangChain will deprecate the affected APIs as part of this fix:
These are older code paths that are no longer recommended for new applications. They were not previously marked as deprecated, but recent LangChain documentation has primarily directed users toward newer streaming and memory patterns, including the Separately, LangChain will update This release also fixes a related secret-marker validation bypass in the serialization and deserialization layer ( Guidance for
|
1.2.27
patch
Dependencies (8)
Changelog
Compare changes
|
|
1.2.26
patch
2 CVEs
CVE-2026-44843
PYSEC-2026-2564
GHSA-pjwx-r37v-7724
Jul 13, 2026
LangChain vulnerable to unsafe deserialization of attacker-controlled objects through overly broad `load()` allowlists
8.2
/ 10
High
Network
Low
None
None
Unchanged
High
Low
None
LangChain contains older runtime code paths that deserialize run inputs, run outputs, or other application-controlled payloads using overly broad object allowlists. These paths may call Applications are exposed only when all of the following are true:
Known affected runtime surfaces include:
Related unsafe deserialization patterns may also affect applications that explicitly load serialized LangChain prompt or runnable objects from untrusted sources, including shared prompt stores, Hub artifacts with model configuration, or other application-controlled serialization stores. Applications that validate incoming requests against a fixed schema, such as coercing user input to a plain string or message-content field before invoking LangChain, are unlikely to expose this deserialization primitive. This release also fixes a related secret-marker validation bypass in the serialization and deserialization layer ( ImpactAn attacker who can submit untrusted structured input to an affected application, and have that structure preserved in LangChain run data, may be able to inject LangChain serialized constructor payloads such as: If this payload reaches a broad Realistic impacts include:
RemediationLangChain will deprecate the affected APIs as part of this fix:
These are older code paths that are no longer recommended for new applications. They were not previously marked as deprecated, but recent LangChain documentation has primarily directed users toward newer streaming and memory patterns, including the Separately, LangChain will update This release also fixes a related secret-marker validation bypass in the serialization and deserialization layer ( Guidance for
|
1.2.26
patch
Dependencies (8)
Changelog
Compare changes
|
|
1.2.25
patch
2 CVEs
CVE-2026-44843
PYSEC-2026-2564
GHSA-pjwx-r37v-7724
Jul 13, 2026
LangChain vulnerable to unsafe deserialization of attacker-controlled objects through overly broad `load()` allowlists
8.2
/ 10
High
Network
Low
None
None
Unchanged
High
Low
None
LangChain contains older runtime code paths that deserialize run inputs, run outputs, or other application-controlled payloads using overly broad object allowlists. These paths may call Applications are exposed only when all of the following are true:
Known affected runtime surfaces include:
Related unsafe deserialization patterns may also affect applications that explicitly load serialized LangChain prompt or runnable objects from untrusted sources, including shared prompt stores, Hub artifacts with model configuration, or other application-controlled serialization stores. Applications that validate incoming requests against a fixed schema, such as coercing user input to a plain string or message-content field before invoking LangChain, are unlikely to expose this deserialization primitive. This release also fixes a related secret-marker validation bypass in the serialization and deserialization layer ( ImpactAn attacker who can submit untrusted structured input to an affected application, and have that structure preserved in LangChain run data, may be able to inject LangChain serialized constructor payloads such as: If this payload reaches a broad Realistic impacts include:
RemediationLangChain will deprecate the affected APIs as part of this fix:
These are older code paths that are no longer recommended for new applications. They were not previously marked as deprecated, but recent LangChain documentation has primarily directed users toward newer streaming and memory patterns, including the Separately, LangChain will update This release also fixes a related secret-marker validation bypass in the serialization and deserialization layer ( Guidance for
|
1.2.25
patch
Dependencies (8)
Changelog
Compare changes
|
|
1.2.24
patch
2 CVEs
CVE-2026-44843
PYSEC-2026-2564
GHSA-pjwx-r37v-7724
Jul 13, 2026
LangChain vulnerable to unsafe deserialization of attacker-controlled objects through overly broad `load()` allowlists
8.2
/ 10
High
Network
Low
None
None
Unchanged
High
Low
None
LangChain contains older runtime code paths that deserialize run inputs, run outputs, or other application-controlled payloads using overly broad object allowlists. These paths may call Applications are exposed only when all of the following are true:
Known affected runtime surfaces include:
Related unsafe deserialization patterns may also affect applications that explicitly load serialized LangChain prompt or runnable objects from untrusted sources, including shared prompt stores, Hub artifacts with model configuration, or other application-controlled serialization stores. Applications that validate incoming requests against a fixed schema, such as coercing user input to a plain string or message-content field before invoking LangChain, are unlikely to expose this deserialization primitive. This release also fixes a related secret-marker validation bypass in the serialization and deserialization layer ( ImpactAn attacker who can submit untrusted structured input to an affected application, and have that structure preserved in LangChain run data, may be able to inject LangChain serialized constructor payloads such as: If this payload reaches a broad Realistic impacts include:
RemediationLangChain will deprecate the affected APIs as part of this fix:
These are older code paths that are no longer recommended for new applications. They were not previously marked as deprecated, but recent LangChain documentation has primarily directed users toward newer streaming and memory patterns, including the Separately, LangChain will update This release also fixes a related secret-marker validation bypass in the serialization and deserialization layer ( Guidance for
|
1.2.24
patch
Dependencies (8)
Changelog
Compare changes
|
|
1.2.23
patch
2 CVEs
CVE-2026-44843
PYSEC-2026-2564
GHSA-pjwx-r37v-7724
Jul 13, 2026
LangChain vulnerable to unsafe deserialization of attacker-controlled objects through overly broad `load()` allowlists
8.2
/ 10
High
Network
Low
None
None
Unchanged
High
Low
None
LangChain contains older runtime code paths that deserialize run inputs, run outputs, or other application-controlled payloads using overly broad object allowlists. These paths may call Applications are exposed only when all of the following are true:
Known affected runtime surfaces include:
Related unsafe deserialization patterns may also affect applications that explicitly load serialized LangChain prompt or runnable objects from untrusted sources, including shared prompt stores, Hub artifacts with model configuration, or other application-controlled serialization stores. Applications that validate incoming requests against a fixed schema, such as coercing user input to a plain string or message-content field before invoking LangChain, are unlikely to expose this deserialization primitive. This release also fixes a related secret-marker validation bypass in the serialization and deserialization layer ( ImpactAn attacker who can submit untrusted structured input to an affected application, and have that structure preserved in LangChain run data, may be able to inject LangChain serialized constructor payloads such as: If this payload reaches a broad Realistic impacts include:
RemediationLangChain will deprecate the affected APIs as part of this fix:
These are older code paths that are no longer recommended for new applications. They were not previously marked as deprecated, but recent LangChain documentation has primarily directed users toward newer streaming and memory patterns, including the Separately, LangChain will update This release also fixes a related secret-marker validation bypass in the serialization and deserialization layer ( Guidance for
|
1.2.23
patch
Dependencies (8)
Changelog
Compare changes
|
|
1.2.22
patch
2 CVEs
CVE-2026-44843
PYSEC-2026-2564
GHSA-pjwx-r37v-7724
Jul 13, 2026
LangChain vulnerable to unsafe deserialization of attacker-controlled objects through overly broad `load()` allowlists
8.2
/ 10
High
Network
Low
None
None
Unchanged
High
Low
None
LangChain contains older runtime code paths that deserialize run inputs, run outputs, or other application-controlled payloads using overly broad object allowlists. These paths may call Applications are exposed only when all of the following are true:
Known affected runtime surfaces include:
Related unsafe deserialization patterns may also affect applications that explicitly load serialized LangChain prompt or runnable objects from untrusted sources, including shared prompt stores, Hub artifacts with model configuration, or other application-controlled serialization stores. Applications that validate incoming requests against a fixed schema, such as coercing user input to a plain string or message-content field before invoking LangChain, are unlikely to expose this deserialization primitive. This release also fixes a related secret-marker validation bypass in the serialization and deserialization layer ( ImpactAn attacker who can submit untrusted structured input to an affected application, and have that structure preserved in LangChain run data, may be able to inject LangChain serialized constructor payloads such as: If this payload reaches a broad Realistic impacts include:
RemediationLangChain will deprecate the affected APIs as part of this fix:
These are older code paths that are no longer recommended for new applications. They were not previously marked as deprecated, but recent LangChain documentation has primarily directed users toward newer streaming and memory patterns, including the Separately, LangChain will update This release also fixes a related secret-marker validation bypass in the serialization and deserialization layer ( Guidance for
|
1.2.22
patch
Dependencies (8)
Changelog
Compare changes
|
|
1.2.21
patch
3 CVEs
CVE-2026-44843
PYSEC-2026-2564
GHSA-pjwx-r37v-7724
Jul 13, 2026
LangChain vulnerable to unsafe deserialization of attacker-controlled objects through overly broad `load()` allowlists
8.2
/ 10
High
Network
Low
None
None
Unchanged
High
Low
None
LangChain contains older runtime code paths that deserialize run inputs, run outputs, or other application-controlled payloads using overly broad object allowlists. These paths may call Applications are exposed only when all of the following are true:
Known affected runtime surfaces include:
Related unsafe deserialization patterns may also affect applications that explicitly load serialized LangChain prompt or runnable objects from untrusted sources, including shared prompt stores, Hub artifacts with model configuration, or other application-controlled serialization stores. Applications that validate incoming requests against a fixed schema, such as coercing user input to a plain string or message-content field before invoking LangChain, are unlikely to expose this deserialization primitive. This release also fixes a related secret-marker validation bypass in the serialization and deserialization layer ( ImpactAn attacker who can submit untrusted structured input to an affected application, and have that structure preserved in LangChain run data, may be able to inject LangChain serialized constructor payloads such as: If this payload reaches a broad Realistic impacts include:
RemediationLangChain will deprecate the affected APIs as part of this fix:
These are older code paths that are no longer recommended for new applications. They were not previously marked as deprecated, but recent LangChain documentation has primarily directed users toward newer streaming and memory patterns, including the Separately, LangChain will update This release also fixes a related secret-marker validation bypass in the serialization and deserialization layer ( Guidance for
|
1.2.21
patch
Dependencies (8)
Changelog
Compare changes
|
|
1.2.20
patch
3 CVEs
CVE-2026-44843
PYSEC-2026-2564
GHSA-pjwx-r37v-7724
Jul 13, 2026
LangChain vulnerable to unsafe deserialization of attacker-controlled objects through overly broad `load()` allowlists
8.2
/ 10
High
Network
Low
None
None
Unchanged
High
Low
None
LangChain contains older runtime code paths that deserialize run inputs, run outputs, or other application-controlled payloads using overly broad object allowlists. These paths may call Applications are exposed only when all of the following are true:
Known affected runtime surfaces include:
Related unsafe deserialization patterns may also affect applications that explicitly load serialized LangChain prompt or runnable objects from untrusted sources, including shared prompt stores, Hub artifacts with model configuration, or other application-controlled serialization stores. Applications that validate incoming requests against a fixed schema, such as coercing user input to a plain string or message-content field before invoking LangChain, are unlikely to expose this deserialization primitive. This release also fixes a related secret-marker validation bypass in the serialization and deserialization layer ( ImpactAn attacker who can submit untrusted structured input to an affected application, and have that structure preserved in LangChain run data, may be able to inject LangChain serialized constructor payloads such as: If this payload reaches a broad Realistic impacts include:
RemediationLangChain will deprecate the affected APIs as part of this fix:
These are older code paths that are no longer recommended for new applications. They were not previously marked as deprecated, but recent LangChain documentation has primarily directed users toward newer streaming and memory patterns, including the Separately, LangChain will update This release also fixes a related secret-marker validation bypass in the serialization and deserialization layer ( Guidance for
|
1.2.20
patch
Dependencies (8)
Changelog
Compare changes
|
|
1.2.19
patch
3 CVEs
CVE-2026-44843
PYSEC-2026-2564
GHSA-pjwx-r37v-7724
Jul 13, 2026
LangChain vulnerable to unsafe deserialization of attacker-controlled objects through overly broad `load()` allowlists
8.2
/ 10
High
Network
Low
None
None
Unchanged
High
Low
None
LangChain contains older runtime code paths that deserialize run inputs, run outputs, or other application-controlled payloads using overly broad object allowlists. These paths may call Applications are exposed only when all of the following are true:
Known affected runtime surfaces include:
Related unsafe deserialization patterns may also affect applications that explicitly load serialized LangChain prompt or runnable objects from untrusted sources, including shared prompt stores, Hub artifacts with model configuration, or other application-controlled serialization stores. Applications that validate incoming requests against a fixed schema, such as coercing user input to a plain string or message-content field before invoking LangChain, are unlikely to expose this deserialization primitive. This release also fixes a related secret-marker validation bypass in the serialization and deserialization layer ( ImpactAn attacker who can submit untrusted structured input to an affected application, and have that structure preserved in LangChain run data, may be able to inject LangChain serialized constructor payloads such as: If this payload reaches a broad Realistic impacts include:
RemediationLangChain will deprecate the affected APIs as part of this fix:
These are older code paths that are no longer recommended for new applications. They were not previously marked as deprecated, but recent LangChain documentation has primarily directed users toward newer streaming and memory patterns, including the Separately, LangChain will update This release also fixes a related secret-marker validation bypass in the serialization and deserialization layer ( Guidance for
|
1.2.19
patch
Dependencies (8)
Changelog
Compare changes
|
|
1.2.18
patch
3 CVEs
CVE-2026-44843
PYSEC-2026-2564
GHSA-pjwx-r37v-7724
Jul 13, 2026
LangChain vulnerable to unsafe deserialization of attacker-controlled objects through overly broad `load()` allowlists
8.2
/ 10
High
Network
Low
None
None
Unchanged
High
Low
None
LangChain contains older runtime code paths that deserialize run inputs, run outputs, or other application-controlled payloads using overly broad object allowlists. These paths may call Applications are exposed only when all of the following are true:
Known affected runtime surfaces include:
Related unsafe deserialization patterns may also affect applications that explicitly load serialized LangChain prompt or runnable objects from untrusted sources, including shared prompt stores, Hub artifacts with model configuration, or other application-controlled serialization stores. Applications that validate incoming requests against a fixed schema, such as coercing user input to a plain string or message-content field before invoking LangChain, are unlikely to expose this deserialization primitive. This release also fixes a related secret-marker validation bypass in the serialization and deserialization layer ( ImpactAn attacker who can submit untrusted structured input to an affected application, and have that structure preserved in LangChain run data, may be able to inject LangChain serialized constructor payloads such as: If this payload reaches a broad Realistic impacts include:
RemediationLangChain will deprecate the affected APIs as part of this fix:
These are older code paths that are no longer recommended for new applications. They were not previously marked as deprecated, but recent LangChain documentation has primarily directed users toward newer streaming and memory patterns, including the Separately, LangChain will update This release also fixes a related secret-marker validation bypass in the serialization and deserialization layer ( Guidance for
|
1.2.18
patch
Dependencies (8)
Changelog
Compare changes
|
|
1.2.17
patch
3 CVEs
CVE-2026-44843
PYSEC-2026-2564
GHSA-pjwx-r37v-7724
Jul 13, 2026
LangChain vulnerable to unsafe deserialization of attacker-controlled objects through overly broad `load()` allowlists
8.2
/ 10
High
Network
Low
None
None
Unchanged
High
Low
None
LangChain contains older runtime code paths that deserialize run inputs, run outputs, or other application-controlled payloads using overly broad object allowlists. These paths may call Applications are exposed only when all of the following are true:
Known affected runtime surfaces include:
Related unsafe deserialization patterns may also affect applications that explicitly load serialized LangChain prompt or runnable objects from untrusted sources, including shared prompt stores, Hub artifacts with model configuration, or other application-controlled serialization stores. Applications that validate incoming requests against a fixed schema, such as coercing user input to a plain string or message-content field before invoking LangChain, are unlikely to expose this deserialization primitive. This release also fixes a related secret-marker validation bypass in the serialization and deserialization layer ( ImpactAn attacker who can submit untrusted structured input to an affected application, and have that structure preserved in LangChain run data, may be able to inject LangChain serialized constructor payloads such as: If this payload reaches a broad Realistic impacts include:
RemediationLangChain will deprecate the affected APIs as part of this fix:
These are older code paths that are no longer recommended for new applications. They were not previously marked as deprecated, but recent LangChain documentation has primarily directed users toward newer streaming and memory patterns, including the Separately, LangChain will update This release also fixes a related secret-marker validation bypass in the serialization and deserialization layer ( Guidance for
|
1.2.17
patch
Dependencies (8)
Changelog
Compare changes
|
|
1.2.16
patch
3 CVEs
CVE-2026-44843
PYSEC-2026-2564
GHSA-pjwx-r37v-7724
Jul 13, 2026
LangChain vulnerable to unsafe deserialization of attacker-controlled objects through overly broad `load()` allowlists
8.2
/ 10
High
Network
Low
None
None
Unchanged
High
Low
None
LangChain contains older runtime code paths that deserialize run inputs, run outputs, or other application-controlled payloads using overly broad object allowlists. These paths may call Applications are exposed only when all of the following are true:
Known affected runtime surfaces include:
Related unsafe deserialization patterns may also affect applications that explicitly load serialized LangChain prompt or runnable objects from untrusted sources, including shared prompt stores, Hub artifacts with model configuration, or other application-controlled serialization stores. Applications that validate incoming requests against a fixed schema, such as coercing user input to a plain string or message-content field before invoking LangChain, are unlikely to expose this deserialization primitive. This release also fixes a related secret-marker validation bypass in the serialization and deserialization layer ( ImpactAn attacker who can submit untrusted structured input to an affected application, and have that structure preserved in LangChain run data, may be able to inject LangChain serialized constructor payloads such as: If this payload reaches a broad Realistic impacts include:
RemediationLangChain will deprecate the affected APIs as part of this fix:
These are older code paths that are no longer recommended for new applications. They were not previously marked as deprecated, but recent LangChain documentation has primarily directed users toward newer streaming and memory patterns, including the Separately, LangChain will update This release also fixes a related secret-marker validation bypass in the serialization and deserialization layer ( Guidance for
|
1.2.16
patch
Dependencies (8)
Changelog
Compare changes
|
|
1.2.15
patch
3 CVEs
CVE-2026-44843
PYSEC-2026-2564
GHSA-pjwx-r37v-7724
Jul 13, 2026
LangChain vulnerable to unsafe deserialization of attacker-controlled objects through overly broad `load()` allowlists
8.2
/ 10
High
Network
Low
None
None
Unchanged
High
Low
None
LangChain contains older runtime code paths that deserialize run inputs, run outputs, or other application-controlled payloads using overly broad object allowlists. These paths may call Applications are exposed only when all of the following are true:
Known affected runtime surfaces include:
Related unsafe deserialization patterns may also affect applications that explicitly load serialized LangChain prompt or runnable objects from untrusted sources, including shared prompt stores, Hub artifacts with model configuration, or other application-controlled serialization stores. Applications that validate incoming requests against a fixed schema, such as coercing user input to a plain string or message-content field before invoking LangChain, are unlikely to expose this deserialization primitive. This release also fixes a related secret-marker validation bypass in the serialization and deserialization layer ( ImpactAn attacker who can submit untrusted structured input to an affected application, and have that structure preserved in LangChain run data, may be able to inject LangChain serialized constructor payloads such as: If this payload reaches a broad Realistic impacts include:
RemediationLangChain will deprecate the affected APIs as part of this fix:
These are older code paths that are no longer recommended for new applications. They were not previously marked as deprecated, but recent LangChain documentation has primarily directed users toward newer streaming and memory patterns, including the Separately, LangChain will update This release also fixes a related secret-marker validation bypass in the serialization and deserialization layer ( Guidance for
|
1.2.15
patch
Dependencies (8)
Changelog
Compare changes
|