fix: update security dependencies#13053
Conversation
- Update brace-expansion to ^5.0.5 in docs - Update picomatch to ^4.0.4 in docs - Update ip-address to ^10.1.1 in frontend - Update GitPython to >=3.1.48 in backend - Add protobuf constraint >=6.33.6,<7.0.0 in backend
WalkthroughThe PR updates Python and npm dependency versions across the Langflow monorepo to standardize pytest to version 9.0.3, add protobuf as a core base dependency, update optional extras (qdrant, gitpython, mem0), pin transitive npm packages, and relax the locust version constraint. ChangesDependency Version Consolidation
🎯 2 (Simple) | ⏱️ ~8 minutes 🚥 Pre-merge checks | ✅ 9✅ Passed checks (9 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Tip 💬 Introducing Slack Agent: The best way for teams to turn conversations into code.Slack Agent is built on CodeRabbit's deep understanding of your code, so your team can collaborate across the entire SDLC without losing context.
Built for teams:
One agent for your entire SDLC. Right inside Slack. Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## release-1.9.3 #13053 +/- ##
================================================
Coverage ? 52.91%
================================================
Files ? 2032
Lines ? 184085
Branches ? 26233
================================================
Hits ? 97411
Misses ? 85563
Partials ? 1111
Flags with carried forward coverage won't be shown. Click here to find out more. 🚀 New features to boost your workflow:
|
This comment has been minimized.
This comment has been minimized.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@pyproject.toml`:
- Line 51: The locust dependency constraint was loosened to "locust>=2.9.0",
which is too permissive; update the pyproject.toml dependency entry for "locust"
to restore a sensible minimum and add an upper bound to prevent major-version
jumps (e.g., change the spec for the "locust" package from "locust>=2.9.0" to
"locust>=2.40.5,<3.0.0") so environments remain consistent while still allowing
patch/minor updates.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: 7e32b75e-61d0-47d1-bcd6-280e9365abf7
⛔ Files ignored due to path filters (3)
docs/package-lock.jsonis excluded by!**/package-lock.jsonsrc/frontend/package-lock.jsonis excluded by!**/package-lock.jsonuv.lockis excluded by!**/*.lock
📒 Files selected for processing (6)
docs/package.jsonpyproject.tomlsrc/backend/base/pyproject.tomlsrc/frontend/package.jsonsrc/lfx/pyproject.tomlsrc/sdk/pyproject.toml
| "codeflash>=0.8.4", | ||
| "hypothesis>=6.123.17", | ||
| "locust~=2.40.5", | ||
| "locust>=2.9.0", |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
What Python versions and dependency compatibility are supported by Locust 2.9.0 vs Locust 2.40.x, and are there known security fixes only present in newer 2.x releases?
💡 Result:
Locust 2.9.0 supports Python 3.7 and later (dropped Python 3.6 support in that release).[1][2] Locust 2.40.x requires Python >=3.10.[3][4] Newer 2.x versions like 2.43.x require Python >=3.10 and add support for Python 3.13/3.14 while dropping older versions like 3.9.[1][5][6] Dependencies have evolved for compatibility with newer Python versions and libraries. For example, Locust 2.9.0 avoided incompatible pyzmq 23 and removed explicit jinja2 pinning.[1] Newer versions specify requests >=2.32.2, gevent >=24.10.1,<26.0.0, pyzmq >=25.0.0, and pytest >=8.3.3,<10.[7][4] Earlier versions like 2.29.0 required Python >=3.9 with requests >=2.26.0.[8][7] No Locust-specific security vulnerabilities or CVEs are reported for any 2.x versions; known issues (e.g., XSS in web UI) were fixed early and affect only pre-2.x.[9][10][11] Newer releases include dependency updates that address security in transitive dependencies (e.g., cryptography bumps, requests SSL fixes).[12][13]
Citations:
- 1: https://docs.locust.io/en/stable/changelog.html
- 2: https://docs.locust.io/en/2.29.1/changelog.html
- 3: https://pypi.org/project/locust/2.40.0/
- 4: https://github.com/locustio/locust/blob/master/pyproject.toml
- 5: https://pypi.org/project/locust/
- 6: https://docs.locust.io/en/2.42.4/changelog.html
- 7: https://pypi.org/project/locust/2.29.2.dev10/
- 8: https://pypi.org/project/locust/2.29.0/
- 9: https://docs.locust.io/en/2.31.2/changelog.html
- 10: https://security.snyk.io/package/pip/locust
- 11: https://www.openhub.net/p/locust/security
- 12: https://github.com/locustio/locust/blob/903ec854/CHANGELOG.md
- 13: https://github.com/locustio/locust/releases
🏁 Script executed:
cd . && head -60 pyproject.toml | tail -20Repository: langflow-ai/langflow
Length of output: 700
🏁 Script executed:
cat pyproject.toml | head -80 | tail -40Repository: langflow-ai/langflow
Length of output: 1211
🏁 Script executed:
grep -n "python" pyproject.toml | head -20Repository: langflow-ai/langflow
Length of output: 670
🏁 Script executed:
git log --oneline --all -S "locust" -- pyproject.toml | head -10Repository: langflow-ai/langflow
Length of output: 282
🏁 Script executed:
git show --stat $(git log --oneline -1 --all -S "locust>=2.9.0" -- pyproject.toml | cut -d' ' -f1) -- pyproject.toml 2>/dev/null | head -50Repository: langflow-ai/langflow
Length of output: 620
🏁 Script executed:
rg "locust" --type toml -B 2 -A 2Repository: langflow-ai/langflow
Length of output: 1063
Loosen the locust constraint for consistency with dependency hardening goals.
The change from ~=2.40.5 to >=2.9.0 is overly permissive and allows versions nearly 2 years old, which undermines consistency. While no Locust-specific security vulnerabilities exist in 2.x versions, the looser bound introduces variance in transitive dependencies across environments. Recommend restoring the version floor to 2.40.5 with an upper bound to prevent accidental major-version jumps:
Suggested constraint
- "locust>=2.9.0",
+ "locust>=2.40.5,<3.0.0",🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@pyproject.toml` at line 51, The locust dependency constraint was loosened to
"locust>=2.9.0", which is too permissive; update the pyproject.toml dependency
entry for "locust" to restore a sensible minimum and add an upper bound to
prevent major-version jumps (e.g., change the spec for the "locust" package from
"locust>=2.9.0" to "locust>=2.40.5,<3.0.0") so environments remain consistent
while still allowing patch/minor updates.
Frontend Unit Test Coverage ReportCoverage Summary
Unit Test Results
|
ogabrielluiz
left a comment
ogabrielluiz
left a comment
There was a problem hiding this comment.
thanks for picking these up! left a few inline notes, mostly around constraint shapes. one suggestion (totally non-blocking): since this is framed as a security update, it'd be really helpful for future audits if the description listed the CVE / GHSA / advisory IDs each bump addresses (e.g. brace-expansion → GHSA-v6h2-p8h4-qcjw, picomatch → GHSA-952p-6rrq-rcjv, GitPython 3.1.48, etc.). makes it easier for reviewers to cross-check constraints against threats. happy to dig those up if it'd help.
| "codeflash>=0.8.4", | ||
| "hypothesis>=6.123.17", | ||
| "locust~=2.40.5", | ||
| "locust>=2.9.0", |
There was a problem hiding this comment.
heads up: ~=2.40.5 was >=2.40.5,<2.41, so >=2.9.0 is actually a loosening (it allows about 30 minor versions back). today it resolves to 2.43.4 which is fine, but a future regen could float backward. could we use >=2.43.4,<3.0 (or ~=2.43.4) to keep a real floor? happy to adjust if there's a reason for the wider range i'm missing.
There was a problem hiding this comment.
updated to ~=2.43.4
| "ruff~=0.13.1", | ||
| "httpx>=0.28.1", | ||
| "pytest>=8.2.0", | ||
| "pytest>=9.0.3", |
There was a problem hiding this comment.
pytest 9 is a major bump (dev-only, so production is fine). i grepped the codebase for the APIs pytest 9 removed (pytest_namespace, pytest_collectstart, pytest.warns(None)) and didn't find usage, but it'd be worth a full suite run before merge. --strict was removed in favor of --strict-markers if anything trips on that.
There was a problem hiding this comment.
when you mention full suite run would the tests running before merge on GH not cover it all?
| # Individual vector store providers | ||
| faiss = ["faiss-cpu==1.9.0.post1"] | ||
| qdrant = ["qdrant-client==1.9.2"] | ||
| qdrant = ["qdrant-client>=1.12.0"] |
There was a problem hiding this comment.
the hard pin ==1.9.2 to >=1.12.0 resolves to 1.17.1 (about 8 minor versions of changes). the qdrant component at src/lfx/src/lfx/components/qdrant/qdrant.py still uses the deprecated langchain_community.vectorstores.Qdrant import, so worth a quick smoke-run. could we also add an upper bound (<2.0.0) to match the bounded style used elsewhere in this file (e.g. langgraph-checkpoint>4.0.0,<5.0.0)? that's likely how we ended up stuck on 1.9.2 in the first place: open ranges drift, then suddenly pin themselves.
There was a problem hiding this comment.
I see your point, valid upper bounds would be safer.
| opensearch = ["opensearch-py==2.8.0"] | ||
| atlassian = ["atlassian-python-api==3.41.16"] | ||
| mem0 = ["mem0ai>=0.1.34"] | ||
| mem0 = ["mem0ai>=2.0.2"] |
There was a problem hiding this comment.
this is a major×2 jump (0.1.34 to 2.0.2). the component at src/lfx/src/lfx/components/mem0/mem0_chat_memory.py uses Memory.from_config, MemoryClient.from_config, and add/search/get_all, and those surfaces changed across the 1.x to 2.x boundary. could we add a smoke test (or at least an import + one call) for that component, and bound to <3.0? happy to help wire that up if useful.
There was a problem hiding this comment.
I think bumping it to 2.x does lead to breaking of the UTs but after some plumbing in the code I can get the component to work although I'm still unsure about some of the points so would discuss more on it over slack.
| }, | ||
| "overrides": { | ||
| "brace-expansion": "^5.0.5", | ||
| "picomatch": "^4.0.4", |
There was a problem hiding this comment.
friendly heads-up: this PR's lockfile regen made the 4.18.0 override actually take effect, and npm itself flags that release as "deprecated": "Bad release. Please use lodash@4.17.21 instead." could we flip the override to 4.17.21? otherwise downstream docs builds may hit integrity warnings.
| "glob": "^11.1.0", | ||
| "test-exclude": "^7.0.0", | ||
| "picomatch": "^4.0.4", | ||
| "ip-address": "^10.1.1", |
There was a problem hiding this comment.
nit (non-blocking): every other override in this block is colocated with its specific consumer (e.g. jest-util.picomatch). a one-line comment noting which CVE/advisory ip-address ^10.1.1 is patching would help future maintainers. same suggestion for the other overrides if you want to be thorough.
There was a problem hiding this comment.
I think JSON doesnt support comments, hence skipping it but will add to the description.
|
follow-up: ran live desk tests against a local qdrant docker + OpenAI embeddings/llm, and there are concrete breakages worth flagging (upgrading my earlier inline notes from "worth checking" to "blocks merge"): 1. mem0 2.x explicitly rejects entity kwargs at the top level of
reproduces with 2. line 88 calls
this is really a 3. minor: raw qdrant-client API surface also changed
happy to send a follow-up PR with the mem0 fix + a langchain-qdrant migration if useful, or you can roll them in here. the locust loosening and the docs lodash override are still my other two concerns from the inline thread. otherwise the dep moves themselves resolve cleanly ( |
| opensearch = ["opensearch-py==2.8.0"] | ||
| atlassian = ["atlassian-python-api==3.41.16"] | ||
| mem0 = ["mem0ai>=0.1.34"] | ||
| mem0 = ["mem0ai>=2.0.2"] |
There was a problem hiding this comment.
follow-up to my earlier note here. ran a live test against local qdrant + openai and the retrieve path crashes under mem0ai 2.0.2.
repro:
from mem0 import Memory
config = {
'vector_store': {'provider': 'qdrant', 'config': {'host': 'localhost', 'port': 6333, 'collection_name': 'smoke'}},
'llm': {'provider': 'openai', 'config': {'model': 'gpt-4o-mini'}},
'embedder': {'provider': 'openai', 'config': {'model': 'text-embedding-3-small'}},
}
m = Memory.from_config(config)
m.add('hello', user_id='u') # OK
m.search(query='x', user_id='u') # ValueError
m.get_all(user_id='u') # ValueErrormem0 2.x rejects entity kwargs at the top level. concrete failures in the component:
src/lfx/src/lfx/components/mem0/mem0_chat_memory.py:138, callingmem0_memory.search(query=search_query, user_id=user_id), raises:
ValueError: Top-level entity parameters frozenset({'user_id'}) are not supported in search(). Use filters={'user_id': '...'} instead.src/lfx/src/lfx/components/mem0/mem0_chat_memory.py:141, callingmem0_memory.get_all(user_id=user_id), raises the sameValueErrorfromget_all().add(user_id=..., metadata=...)at line 118 still works in 2.x; only the read paths broke.
three options I considered:
- smallest, what I'd lean toward: pass
filtersat both callsites ({'user_id': user_id}) and bound the dep tomem0ai>=2.0.2,<3.0.0so a future major doesn't silently re-break things. - defer the migration: pin to
mem0ai>=0.1.34,<0.2so this PR stays a pure security bump and the 0.x to 2.x migration ships standalone. - option 1 plus a tiny smoke that runs
add, thensearch, thenget_all, so the next surface change gets caught in CI instead of by users.
There was a problem hiding this comment.
i would say for better testability and cleaner code, we should defer the migration as its own separate JIRA task.
| # Individual vector store providers | ||
| faiss = ["faiss-cpu==1.9.0.post1"] | ||
| qdrant = ["qdrant-client==1.9.2"] | ||
| qdrant = ["qdrant-client>=1.12.0"] |
There was a problem hiding this comment.
similar story on the qdrant side: live test confirms the ingest path crashes under qdrant-client 1.17.1.
repro:
from langchain_community.vectorstores import Qdrant
from langchain_openai import OpenAIEmbeddings
Qdrant.from_documents(
docs, OpenAIEmbeddings(model='text-embedding-3-small'),
location='http://localhost:6333', collection_name='smoke', force_recreate=True,
)
# AssertionError: Unknown arguments: ['init_from']langchain_community.vectorstores.Qdrant.from_texts/from_documents calls client.recreate_collection(..., init_from=...). qdrant-client 1.10+ removed that kwarg, and recreate_collection itself is now deprecated in favor of collection_exists + create_collection. so the wrapper assumes a pre-1.10 client surface that this PR no longer provides.
concrete failure at src/lfx/src/lfx/components/qdrant/qdrant.py:88:
qdrant = Qdrant.from_documents(documents, embedding=self.embedding, **qdrant_kwargs, **server_kwargs)the no-ingest branch (lines 92-93, Qdrant(embeddings=..., client=client, ...)) may still work for query-only usage, but the moment a user passes documents, it raises.
ranked options:
- migrate to
langchain-qdrant. it's the actively maintained replacement; qdrant-client itself prints a deprecation pointer to it. roughly:addfrom langchain_qdrant import QdrantVectorStore QdrantVectorStore.from_documents(documents, embedding=self.embedding, **qdrant_kwargs, **server_kwargs) QdrantVectorStore(embedding=self.embedding, client=client, **qdrant_kwargs)
langchain-qdrant>=0.2to theqdrantextra alongside (or replacing) the langchain_community import. - pin qdrant-client
<1.10. keeps the wrapper working but trades the security intent for component stability. - shim: drop
init_fromfrom kwargs before callingfrom_documents. small diff, brittle, not recommended.
still think a <2.0.0 upper bound on the spec belongs here regardless: that's what kept us stuck at ==1.9.2 in the first place.
There was a problem hiding this comment.
since this is related to memo deferring memo would mean we can defer this too, to be handled together.
So these ones are a part of CIMS scan which just produces a CSV file or (now in SQL table) that gives us the info on the vulnerable version and fixed version. |
- Update lodash from deprecated 4.18.0 to 4.17.21 - Add docs/SECURITY_OVERRIDES.md documenting all CVEs - Revert mem0ai 2.x upgrade due to compatibility issues
This comment has been minimized.
This comment has been minimized.
Jkavia
changed the title
github-actions
Bot
added
bug
- Update langchain-core to >=1.3.3 (fixes CVE-2026-44843) - Update GitPython to >=3.1.50 (partially fixes CVE-2026-44243, CVE-2026-44244, GHSA-mv93-w799-cj2w) - Update pyarrow constraint to >=23.0.1,<24.0.0 (fixes CVE-2026-25087) - Add override-dependencies for transitive packages: - lxml >=6.1.0 (fixes CVE-2026-41066) - mako >=1.3.12 (fixes CVE-2026-44307) - urllib3 >=2.7.0 (fixes CVE-2026-44431, CVE-2026-44432) - python-liquid >=2.2.0 (fixes CVE-2026-45017) Total: 9 CVEs addressed Smoke tests: All imports successful, no breaking changes detected
github-actions
Bot
added
bug
|
Build successful! ✅ |
github-actions
Bot
added
bug
2 participants
Changes
Backend (Python)
Backend (Python) - Transitive Dependencies via Override
Frontend (npm)
Blocked/Unaddressed