Summary
We run the published agent-memory-server image in production (pinned to server/v0.15.2, released 2026-04-10). Container scanning flags a number of CVEs in the Python dependencies frozen in the v0.15.2 uv.lock. Because releases are built with uv sync --frozen, downstream consumers can't pick up dependency fixes without a new tagged release — and overriding packages inside the published venv would replace your tested dependency set, which we (and presumably most consumers) don't want to do.
Most of the fixes are already merged on main (the June 30 Dependabot batch and later bumps in V0/uv.lock), but no release has been tagged since April. Tagging a patch release from the current lock would resolve the majority of these findings for everyone consuming the published images.
Already fixed on main, waiting on a release
| Package |
v0.15.2 lock |
main (V0/uv.lock) |
Resolves |
| starlette |
0.50.0 |
1.3.1 |
CVE-2026-48818, CVE-2026-54283, CVE-2026-48710, CVE-2026-48817, CVE-2026-54282 |
| urllib3 |
2.6.3 |
2.7.0 |
CVE-2026-44431, CVE-2026-44432 |
| cryptography |
46.0.7 |
48.0.1 |
GHSA-537c-gmf6-5ccf |
| pyjwt |
2.12.0 |
2.13.0 |
CVE-2026-48526, CVE-2026-48522/48523/48525 |
| python-multipart |
0.0.22 |
0.0.31 |
CVE-2026-42561, CVE-2026-53539, CVE-2026-40347 and others |
| litellm |
1.80.11 |
1.83.0 |
CVE-2026-35030 (CRITICAL), CVE-2026-35029, GHSA-69x8-hrgq-fjj8 |
| aiohttp |
3.13.3 |
3.14.1 |
CVE-2026-22815 family |
| idna |
3.11 |
3.15 |
CVE-2026-45409 |
Still vulnerable even on main — bumps requested
We understand transformers 4→5 is a major bump and may need validation on your side; the litellm 1.83.x → 1.84 line and lupa 2.7 look lower-risk.
Ask
- Tag a patch release (e.g. v0.15.3) from the current
main lock so the already-merged fixes ship in the published images.
- Consider bumping litellm to ≥ 1.84 (clears the outstanding CRITICAL), lupa to ≥ 2.7, and ecdsa to ≥ 0.19.2 in that release or a follow-up.
- If a release is planned already, a rough timeline would help downstream consumers set remediation SLAs with their compliance tooling.
Thanks — the vendored, frozen-lock release model is genuinely appreciated; the only gap is release cadence when CVE fixes accumulate on main.
Summary
We run the published agent-memory-server image in production (pinned to
server/v0.15.2, released 2026-04-10). Container scanning flags a number of CVEs in the Python dependencies frozen in the v0.15.2uv.lock. Because releases are built withuv sync --frozen, downstream consumers can't pick up dependency fixes without a new tagged release — and overriding packages inside the published venv would replace your tested dependency set, which we (and presumably most consumers) don't want to do.Most of the fixes are already merged on
main(the June 30 Dependabot batch and later bumps inV0/uv.lock), but no release has been tagged since April. Tagging a patch release from the current lock would resolve the majority of these findings for everyone consuming the published images.Already fixed on main, waiting on a release
V0/uv.lock)Still vulnerable even on main — bumps requested
We understand transformers 4→5 is a major bump and may need validation on your side; the litellm 1.83.x → 1.84 line and lupa 2.7 look lower-risk.
Ask
mainlock so the already-merged fixes ship in the published images.Thanks — the vendored, frozen-lock release model is genuinely appreciated; the only gap is release cadence when CVE fixes accumulate on main.