chore(deps): raise CVE floors for httplib2 + mcp to clear pip-audit

[Sundeepg98]

What

Clears the 4 time-based pip-audit findings that have kept the e2e security-audit job red, returning that job to a clean pass so it can rejoin the merge gates. Deliberately scoped to only the two CVE-affected packages.

Package	Old	New	Floor pin	CVE(s) cleared
httplib2	0.31.2	0.32.0	>=0.32.0,<1	PYSEC-2026-3444 (unbounded gzip/deflate decompression DoS; fixed 0.32.0)
mcp	1.27.1	1.28.1	>=1.28.1,<2	CVE-2026-52870 + CVE-2026-52869 (fixed 1.27.2), CVE-2026-59950 (WebSocket Host/Origin validation; fixed 1.28.1)

mcp needs 1.28.1, not 1.27.2: CVE-2026-59950 is still present in 1.27.2 and 1.28.0, and is only fixed in 1.28.1 (per GHSA-vj7q-gjh5-988w). 1.28.1 is the minimum that clears all three mcp CVEs at once.

Both packages were unpinned in pyproject.toml's security-floor block, so the locked resolution sat on the CVE-affected versions. Both are also imported directly in src/ (httplib2 in google_api_client.py; mcp.types.ToolAnnotations in decorators.py), so an explicit floor is doubly warranted. uv.lock regenerated via uv sync; only these two version entries changed (mcp 1.28.1's own dependency subtree is identical to 1.27.1's, no new transitive deps).

pip-audit proof (exact CI invocation)

Before:

Found 4 known vulnerabilities in 2 packages
Name     Version ID              Fix Versions
-------- ------- --------------- ------------
httplib2 0.31.2  PYSEC-2026-3444 0.32.0
mcp      1.27.1  CVE-2026-52870  1.27.2
mcp      1.27.1  CVE-2026-52869  1.27.2
mcp      1.27.1  CVE-2026-59950  1.28.1

After (uv export --frozen --format requirements-txt --no-hashes --no-emit-project piped to pip-audit --strict --ignore-vuln PYSEC-2025-183):

No known vulnerabilities found

No new advisories introduced by the bump.

FastMCP compatibility

mcp underlies fastmcp's server + oauth-proxy, so the bump was compat-checked three ways:

• Constraint: fastmcp-slim[client,server] declares mcp>=1.24.0,<2.0; 1.28.1 sits inside it (and my <2 ceiling matches fastmcp's own upper bound).
• Boot: appscriptly help (real console entry) boots clean (exit 0), firing auto-discovery, on_duplicate="error", and the _MIN_EXPECTED_TOOL_COUNT floor at import.
• Tests: test_tool_registration (live mcp.list_tools() == golden) and test_token_log_hygiene (runs fastmcp's REAL token verifier through our client, the N4 canary) both pass on 1.28.1.

Gate results (run in the worktree)

Gate	Result
pytest tests/unit --cov-fail-under=55	3195 passed, 2 skipped, coverage 89.92%
pytest tests/integration/	16 passed, 5 skipped (--live-gated)
pyright src/	0 errors, 0 warnings
ruff check src/ tests/	All checks passed
freeze_tool_surface.py --check	up to date, 141 tools (no drift)
pip-audit (CI invocation)	No known vulnerabilities found

One known-noise failure, ignored per builder brief: test_dcr_registration_survives_a_simulated_restart fails Windows-only with PathSecurityError from key_value.aio.stores.filetree (Windows Store Python's AppData virtualization redirects the write path under ...\Packages\PythonSoftwareFoundation.Python...\LocalCache\..., which the filetree store's path-traversal guard then reads as "outside" the root). It lives in py-key-value-aio (a fastmcp-slim dep), not mcp/httplib2; it is pre-existing (documented in the merged #224), not an import/API break, and is green on the Linux CI runner where CI actually gates.

Scope

Zero tool-surface change (golden stays at 141), no auth/scope edits (the OAuth review is open). Only pyproject.toml + uv.lock touched.

Dependabot #250-252 disposition

These three are orthogonal to this PR and none of them clears a pip-audit CVE:

• deps: update sentry-sdk requirement from >=2.62.0 to >=2.66.0 #250 sentry-sdk >=2.62.0 to >=2.65.0
• deps: update google-auth requirement from >=2.53.0 to >=2.56.0 #251 google-auth >=2.53.0 to >=2.55.2
• deps: update ruff requirement from >=0.15.17 to >=0.15.21 #252 ruff >=0.15.17 to >=0.15.21

Recommendation: keep all three open; do not fold into this PR. Folding unrelated routine floor-bumps into a security fix would broaden its scope against the tight-scope convention (and none is needed to clear the pip-audit reds). They each touch pyproject.toml/uv.lock too, so once this CVE PR merges, dependabot will auto-rebase them onto the new main; evaluate/merge each on its own merits afterward. (Left open per instructions, not closed here.)

---

🤖 Generated with Claude Code