Request: tag a patch release with a refreshed uv.lock — CVE fixes are merged on main but unreleased since v0.15.2

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

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

1. Tag a patch release (e.g. v0.15.3) from the current main lock so the already-merged fixes ship in the published images.
2. 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.
3. 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.

Start with the current main branch and V0/uv.lock, then review how releases run uv sync --frozen and publish the image. Verify the requested dependency levels and their compatibility, especially the transformers major upgrade, and confirm that the tagged patch release contains the refreshed lock and resolves the listed findings.