CVEs survive pip-audit fix across reboots // uv.lock pins vulnerable versions of packages

[Jagermaster2469]

Bug Description

The Hermes Agent venv ships with a uv.lock file that explicitly pins three packages at versions with known security vulnerabilities. Any pip-based fix (pip-audit --fix or pip install --upgrade) is transient — the next time
uv sync runs (which happens on gateway restart, system reboot, or Hermes self-repair), the packages are downgraded back to the vulnerable pinned versions. This was verified across a full system reboot — packages reverted on gateway restart.

Steps to Reproduce

1. Install Hermes Agent v0.18.2 via git on a clean system
2. Run pip-audit inside the venv:
   .hermes/hermes-agent/venv/bin/pip-audit
3. Observe 8 vulnerabilities in 3 packages
4. Fix them: pip-audit --fix (or pip install --upgrade cryptography starlette python-multipart)
5. Verify zero vulns: pip-audit → clean
6. Reboot the system (or restart hermes-gateway which triggers uv sync)
7. Run pip-audit again → 8 vulnerabilities are back
8. Check uv.lock to confirm pinned versions:
   grep -A1 'name = "cryptography"' .hermes/hermes-agent/uv.lock | grep version
   → version = "46.0.7"

Expected Behavior

- uv.lock should pin secure versions of all dependencies 
- pip-audit should report zero known vulnerabilities in a fresh install
- Version pins in pyproject.toml should use compatible-release ranges instead of exact pins when possible, so security fixes can land without manual lock file updates

Actual Behavior

uv.lock hard-pins:
cryptography ==46.0.7
starlette ==1.0.1
python-multipart ==0.0.27

Pip-audit output after fresh sync:
Found 8 known vulnerabilities in 3 packages
Name              Version ID                  Fix Versions
cryptography      46.0.7  GHSA-537c-gmf6-5ccf  48.0.1
starlette                 1.0.1   PYSEC-2026-249         1.3.1
starlette                 1.0.1   PYSEC-2026-248         1.3.0
starlette                 1.0.1   CVE-2026-48818         1.1.0
starlette                 1.0.1   CVE-2026-48817         1.1.0
python-multipart  0.0.27  CVE-2026-53540      0.0.31
python-multipart  0.0.27  CVE-2026-53539      0.0.30
python-multipart  0.0.27  CVE-2026-53538      0.0.30

After pip install --upgrade cryptography starlette python-multipart:
ERROR: pip's dependency resolver: hermes-agent 0.18.2 requires cryptography==46.0.7,
but you have cryptography 49.0.0 which is incompatible.

Packages install at secure versions but conflict with declared dependency.
Next uv sync reverts to vulnerable versions.

Affected Component

Configuration (config.yaml, .env, hermes setup)

Messaging Platform (if gateway-related)

N/A (CLI only)

Debug Report

Vulnerable pins confirmed in uv.lock:
      cryptography ==46.0.7
      starlette ==1.0.1  
      python-multipart ==0.0.27

Operating System

Debian GNU/Linux 13 (trixie), aarch64

Python Version

Python 3.11.15 (Hermes venv) / Python 3.13.5 (system)

Hermes Version

Hermes Agent v0.18.2 (2026.7.7.2)

Additional Logs / Traceback (optional)

Root Cause Analysis (optional)

The fix requires:
- Bumping the locked versions in uv.lock (uv lock --upgrade-package cryptography --upgrade-package starlette --upgrade-package python-multipart)
- Relaxing exact pins in pyproject.toml to allow compatible security updates (e.g., cryptography>=46.0.7 instead of ==46.0.7)
- Adding pip-audit or a similar CVE scanner to CI to catch regressions

Proposed Fix (optional)

1. Run uv lock --upgrade-package cryptography --upgrade-package starlette --upgrade-package python-multipart to bump uv.lock
2. Relax exact pins in pyproject.toml where possible:
   - cryptography>=46.0.7 instead of ==46.0.7
   - starlette>=1.0.1 instead of ==1.0.1
   - python-multipart>=0.0.27 instead of ==0.0.27
3. Add pip-audit to CI workflow (e.g., .github/workflows/security.yml) to run on PRs and cron schedule
4. Consider adding a Dependabot or Renovate config to auto-bump security-critical packages

Are you willing to submit a PR for this?

• I'd like to fix this myself and submit a PR

[DeployFaith]

Additional affected dependency: Pillow.

Hermes Agency PR #92's required pip-audit --strict check now reproduces five Pillow findings from a clean Python 3.12 solve:

• hermes-agency==0.7.3 requires hermes-agent>=0.18.0
• resolution selects hermes-agent==0.18.2
• the Hermes Agent package metadata/source declares the exact pin Pillow==12.2.0
• advisories: PYSEC-2026-2253, PYSEC-2026-2254, PYSEC-2026-2255, PYSEC-2026-2256, and PYSEC-2026-2257
• all list 12.3.0 as the fixed version

A downstream Pillow>=12.3.0 constraint is unsatisfiable while the upstream exact pin remains, and Hermes Agency does not directly use Pillow. Please update or relax the upstream Pillow pin and publish a patched Hermes Agent release. This is blocking the otherwise-green downstream PR: DeployFaith/Hermes_Agency#92

[DeployFaith]

Upstream remediation is now open in #63942:

• bumps the core and tool.vision fallback pins from Pillow==12.2.0 to 12.3.0
• regenerates uv.lock
• adds a regression test to keep the pins in lockstep

The dependency packet is intentionally release-version neutral; a new PyPI release containing the merge is required before downstream consumers can resolve the patched wheel.

[spaisllc]

Another instance of the same root cause, not yet listed here: mcp==1.26.0 — three HIGH advisories published in the last ~24h.

Reproduced on a fresh sync of main @ abc22cdf1 (v0.18.2), via hermes security:

Advisory	Summary	Fixed in
GHSA-hvrp-rf83-w775	MCP Python SDK: experimental task handlers allow any client to access and cancel other clients' tasks	1.27.2
GHSA-jpw9-pfvf-9f58	MCP Python SDK: HTTP transports serve session requests without verifying the authenticated principal	1.27.2
GHSA-vj7q-gjh5-988w	MCP Python SDK: WebSocket server transport does not support Host/Origin validation	1.28.1

Same mechanism this issue describes — the version is hard-pinned so it survives any local fix:

# uv.lock
name = "mcp"
version = "1.26.0"

# pyproject.toml — exact pin in three extras
160: dev          = [..., "mcp==1.26.0", ...]
207: mcp          = ["mcp==1.26.0", "starlette==1.0.1"]
216: computer-use = ["mcp==1.26.0", "starlette==1.0.1"]

Suggested floor: mcp>=1.28.1 — 1.27.2 clears the first two, but the WebSocket Host/Origin one needs 1.28.1.

Worth noting the exposure is server-side only (all three are MCP server transport issues), so deployments that don't serve MCP aren't practically affected — but the pin still trips pip-audit/hermes security on every fresh install, which is the reporting problem this issue is about.

---

Also confirming the original three still reproduce unchanged at abc22cdf1 (9 days after this was filed): cryptography==46.0.7, starlette==1.0.1, python-multipart==0.0.27. Pillow appears handled by #63942.

One observation in support of @Jagermaster2469's "compatible-release ranges" ask: several of these exact pins were themselves added to fix earlier CVEs, and the comments say so —

"cryptography==46.0.7",  # CVE-2026-39892, CVE-2026-34073
mcp = ["mcp==1.26.0", "starlette==1.0.1"]  # starlette: CVE-2026-48710

So each bump has to clear the new advisory without regressing the CVE the pin was introduced for (e.g. Starlette #35067 / BadHost), which is presumably why they're stuck. A regression test asserting "pinned version is not in any known-vulnerable range," like the lockstep test in #63942, would surface these at CI time rather than at downstream pip-audit.