security: pin patched Starlette (>=1.0.1) for CVE-2026-48710 BadHost - #35118
Merged
Conversation
Starlette < 1.0.1 is affected by CVE-2026-48710 ("BadHost", CWE-444). The HTTP Host header was not validated before being used to rebuild `request.url`, so a malformed Host could make `request.url.path` desync from the raw ASGI path the router actually dispatched. Middleware and endpoints that apply path-based authorization off `request.url` (rather than `scope["path"]`) can therefore be bypassed. Hermes pulls Starlette transitively, never directly: - [web] -> fastapi==0.133.1 (starlette>=0.40.0, no upper bound) - [mcp] -> mcp==1.26.0 + sse-starlette (starlette>=0.27 / >=0.49.1) - [computer-use] -> mcp==1.26.0 - [dev] -> mcp==1.26.0 A fresh resolve landed starlette 0.52.1 — vulnerable. With no upper bound on the transitive specs, pip/uv could resolve any pre-1.0.1 release on a fresh install. Fix: pin starlette==1.0.1 directly in every extra that exposes a Starlette-backed server surface, regenerate uv.lock (only starlette moves: 0.52.1 -> 1.0.1, hash-verified), and mirror the pin in the lazy-install map (tools/lazy_deps.py `tool.dashboard`) so `hermes` on-demand dashboard installs can't re-resolve a vulnerable version. 1.0.1 is the advisory's named fix floor and the oldest patched release (more bake time than 1.1.0/1.2.0, which are days old); it satisfies every carrier constraint and our requires-python>=3.11. Scope note: this is a dependency-level fix complementing the application-layer Host-header validator added in #34162 (`hermes_cli/web_server.py` `_is_accepted_host`). Defense in depth at both the framework and app layers. Guards: two invariant tests in tests/test_packaging_metadata.py assert every server-surface extra pins starlette and that pyproject + uv.lock both resolve >= the 1.0.1 CVE floor — a dropped pin or stale lock fails in CI instead of shipping the bypass. Closes #35067
Contributor
🔎 Lint report:
|
alt-glitch
added
type/security
Collaborator
|
Competing fix: #35068 also pins Starlette for CVE-2026-48710 but targets |
KKT-OPT
pushed a commit
to KKT-OPT/hermes-agent
that referenced
this pull request
May 31, 2026
…ousResearch#35118) Starlette < 1.0.1 is affected by CVE-2026-48710 ("BadHost", CWE-444). The HTTP Host header was not validated before being used to rebuild `request.url`, so a malformed Host could make `request.url.path` desync from the raw ASGI path the router actually dispatched. Middleware and endpoints that apply path-based authorization off `request.url` (rather than `scope["path"]`) can therefore be bypassed. Hermes pulls Starlette transitively, never directly: - [web] -> fastapi==0.133.1 (starlette>=0.40.0, no upper bound) - [mcp] -> mcp==1.26.0 + sse-starlette (starlette>=0.27 / >=0.49.1) - [computer-use] -> mcp==1.26.0 - [dev] -> mcp==1.26.0 A fresh resolve landed starlette 0.52.1 — vulnerable. With no upper bound on the transitive specs, pip/uv could resolve any pre-1.0.1 release on a fresh install. Fix: pin starlette==1.0.1 directly in every extra that exposes a Starlette-backed server surface, regenerate uv.lock (only starlette moves: 0.52.1 -> 1.0.1, hash-verified), and mirror the pin in the lazy-install map (tools/lazy_deps.py `tool.dashboard`) so `hermes` on-demand dashboard installs can't re-resolve a vulnerable version. 1.0.1 is the advisory's named fix floor and the oldest patched release (more bake time than 1.1.0/1.2.0, which are days old); it satisfies every carrier constraint and our requires-python>=3.11. Scope note: this is a dependency-level fix complementing the application-layer Host-header validator added in NousResearch#34162 (`hermes_cli/web_server.py` `_is_accepted_host`). Defense in depth at both the framework and app layers. Guards: two invariant tests in tests/test_packaging_metadata.py assert every server-surface extra pins starlette and that pyproject + uv.lock both resolve >= the 1.0.1 CVE floor — a dropped pin or stale lock fails in CI instead of shipping the bypass. Closes NousResearch#35067
shivros
pushed a commit
to shivros/hermes-agent
that referenced
this pull request
Jun 6, 2026
…ousResearch#35118) Starlette < 1.0.1 is affected by CVE-2026-48710 ("BadHost", CWE-444). The HTTP Host header was not validated before being used to rebuild `request.url`, so a malformed Host could make `request.url.path` desync from the raw ASGI path the router actually dispatched. Middleware and endpoints that apply path-based authorization off `request.url` (rather than `scope["path"]`) can therefore be bypassed. Hermes pulls Starlette transitively, never directly: - [web] -> fastapi==0.133.1 (starlette>=0.40.0, no upper bound) - [mcp] -> mcp==1.26.0 + sse-starlette (starlette>=0.27 / >=0.49.1) - [computer-use] -> mcp==1.26.0 - [dev] -> mcp==1.26.0 A fresh resolve landed starlette 0.52.1 — vulnerable. With no upper bound on the transitive specs, pip/uv could resolve any pre-1.0.1 release on a fresh install. Fix: pin starlette==1.0.1 directly in every extra that exposes a Starlette-backed server surface, regenerate uv.lock (only starlette moves: 0.52.1 -> 1.0.1, hash-verified), and mirror the pin in the lazy-install map (tools/lazy_deps.py `tool.dashboard`) so `hermes` on-demand dashboard installs can't re-resolve a vulnerable version. 1.0.1 is the advisory's named fix floor and the oldest patched release (more bake time than 1.1.0/1.2.0, which are days old); it satisfies every carrier constraint and our requires-python>=3.11. Scope note: this is a dependency-level fix complementing the application-layer Host-header validator added in NousResearch#34162 (`hermes_cli/web_server.py` `_is_accepted_host`). Defense in depth at both the framework and app layers. Guards: two invariant tests in tests/test_packaging_metadata.py assert every server-surface extra pins starlette and that pyproject + uv.lock both resolve >= the 1.0.1 CVE floor — a dropped pin or stale lock fails in CI instead of shipping the bypass. Closes NousResearch#35067
alt-glitch
pushed a commit
that referenced
this pull request
Jun 14, 2026
…35118) Starlette < 1.0.1 is affected by CVE-2026-48710 ("BadHost", CWE-444). The HTTP Host header was not validated before being used to rebuild `request.url`, so a malformed Host could make `request.url.path` desync from the raw ASGI path the router actually dispatched. Middleware and endpoints that apply path-based authorization off `request.url` (rather than `scope["path"]`) can therefore be bypassed. Hermes pulls Starlette transitively, never directly: - [web] -> fastapi==0.133.1 (starlette>=0.40.0, no upper bound) - [mcp] -> mcp==1.26.0 + sse-starlette (starlette>=0.27 / >=0.49.1) - [computer-use] -> mcp==1.26.0 - [dev] -> mcp==1.26.0 A fresh resolve landed starlette 0.52.1 — vulnerable. With no upper bound on the transitive specs, pip/uv could resolve any pre-1.0.1 release on a fresh install. Fix: pin starlette==1.0.1 directly in every extra that exposes a Starlette-backed server surface, regenerate uv.lock (only starlette moves: 0.52.1 -> 1.0.1, hash-verified), and mirror the pin in the lazy-install map (tools/lazy_deps.py `tool.dashboard`) so `hermes` on-demand dashboard installs can't re-resolve a vulnerable version. 1.0.1 is the advisory's named fix floor and the oldest patched release (more bake time than 1.1.0/1.2.0, which are days old); it satisfies every carrier constraint and our requires-python>=3.11. Scope note: this is a dependency-level fix complementing the application-layer Host-header validator added in #34162 (`hermes_cli/web_server.py` `_is_accepted_host`). Defense in depth at both the framework and app layers. Guards: two invariant tests in tests/test_packaging_metadata.py assert every server-surface extra pins starlette and that pyproject + uv.lock both resolve >= the 1.0.1 CVE floor — a dropped pin or stale lock fails in CI instead of shipping the bypass. Closes #35067
T02200059
pushed a commit
to T02200059/hermes-agent
that referenced
this pull request
Jun 18, 2026
…ousResearch#35118) Starlette < 1.0.1 is affected by CVE-2026-48710 ("BadHost", CWE-444). The HTTP Host header was not validated before being used to rebuild `request.url`, so a malformed Host could make `request.url.path` desync from the raw ASGI path the router actually dispatched. Middleware and endpoints that apply path-based authorization off `request.url` (rather than `scope["path"]`) can therefore be bypassed. Hermes pulls Starlette transitively, never directly: - [web] -> fastapi==0.133.1 (starlette>=0.40.0, no upper bound) - [mcp] -> mcp==1.26.0 + sse-starlette (starlette>=0.27 / >=0.49.1) - [computer-use] -> mcp==1.26.0 - [dev] -> mcp==1.26.0 A fresh resolve landed starlette 0.52.1 — vulnerable. With no upper bound on the transitive specs, pip/uv could resolve any pre-1.0.1 release on a fresh install. Fix: pin starlette==1.0.1 directly in every extra that exposes a Starlette-backed server surface, regenerate uv.lock (only starlette moves: 0.52.1 -> 1.0.1, hash-verified), and mirror the pin in the lazy-install map (tools/lazy_deps.py `tool.dashboard`) so `hermes` on-demand dashboard installs can't re-resolve a vulnerable version. 1.0.1 is the advisory's named fix floor and the oldest patched release (more bake time than 1.1.0/1.2.0, which are days old); it satisfies every carrier constraint and our requires-python>=3.11. Scope note: this is a dependency-level fix complementing the application-layer Host-header validator added in NousResearch#34162 (`hermes_cli/web_server.py` `_is_accepted_host`). Defense in depth at both the framework and app layers. Guards: two invariant tests in tests/test_packaging_metadata.py assert every server-surface extra pins starlette and that pyproject + uv.lock both resolve >= the 1.0.1 CVE floor — a dropped pin or stale lock fails in CI instead of shipping the bypass. Closes NousResearch#35067
xyshanren
pushed a commit
to xyshanren/hermes-agent-cn
that referenced
this pull request
Jun 25, 2026
…ousResearch#35118) Starlette < 1.0.1 is affected by CVE-2026-48710 ("BadHost", CWE-444). The HTTP Host header was not validated before being used to rebuild `request.url`, so a malformed Host could make `request.url.path` desync from the raw ASGI path the router actually dispatched. Middleware and endpoints that apply path-based authorization off `request.url` (rather than `scope["path"]`) can therefore be bypassed. Hermes pulls Starlette transitively, never directly: - [web] -> fastapi==0.133.1 (starlette>=0.40.0, no upper bound) - [mcp] -> mcp==1.26.0 + sse-starlette (starlette>=0.27 / >=0.49.1) - [computer-use] -> mcp==1.26.0 - [dev] -> mcp==1.26.0 A fresh resolve landed starlette 0.52.1 — vulnerable. With no upper bound on the transitive specs, pip/uv could resolve any pre-1.0.1 release on a fresh install. Fix: pin starlette==1.0.1 directly in every extra that exposes a Starlette-backed server surface, regenerate uv.lock (only starlette moves: 0.52.1 -> 1.0.1, hash-verified), and mirror the pin in the lazy-install map (tools/lazy_deps.py `tool.dashboard`) so `hermes` on-demand dashboard installs can't re-resolve a vulnerable version. 1.0.1 is the advisory's named fix floor and the oldest patched release (more bake time than 1.1.0/1.2.0, which are days old); it satisfies every carrier constraint and our requires-python>=3.11. Scope note: this is a dependency-level fix complementing the application-layer Host-header validator added in NousResearch#34162 (`hermes_cli/web_server.py` `_is_accepted_host`). Defense in depth at both the framework and app layers. Guards: two invariant tests in tests/test_packaging_metadata.py assert every server-surface extra pins starlette and that pyproject + uv.lock both resolve >= the 1.0.1 CVE floor — a dropped pin or stale lock fails in CI instead of shipping the bypass. Closes NousResearch#35067
waefrebeorn
pushed a commit
to waefrebeorn/slermes
that referenced
this pull request
Jul 2, 2026
…ousResearch#35118) Starlette < 1.0.1 is affected by CVE-2026-48710 ("BadHost", CWE-444). The HTTP Host header was not validated before being used to rebuild `request.url`, so a malformed Host could make `request.url.path` desync from the raw ASGI path the router actually dispatched. Middleware and endpoints that apply path-based authorization off `request.url` (rather than `scope["path"]`) can therefore be bypassed. Hermes pulls Starlette transitively, never directly: - [web] -> fastapi==0.133.1 (starlette>=0.40.0, no upper bound) - [mcp] -> mcp==1.26.0 + sse-starlette (starlette>=0.27 / >=0.49.1) - [computer-use] -> mcp==1.26.0 - [dev] -> mcp==1.26.0 A fresh resolve landed starlette 0.52.1 — vulnerable. With no upper bound on the transitive specs, pip/uv could resolve any pre-1.0.1 release on a fresh install. Fix: pin starlette==1.0.1 directly in every extra that exposes a Starlette-backed server surface, regenerate uv.lock (only starlette moves: 0.52.1 -> 1.0.1, hash-verified), and mirror the pin in the lazy-install map (tools/lazy_deps.py `tool.dashboard`) so `hermes` on-demand dashboard installs can't re-resolve a vulnerable version. 1.0.1 is the advisory's named fix floor and the oldest patched release (more bake time than 1.1.0/1.2.0, which are days old); it satisfies every carrier constraint and our requires-python>=3.11. Scope note: this is a dependency-level fix complementing the application-layer Host-header validator added in NousResearch#34162 (`hermes_cli/web_server.py` `_is_accepted_host`). Defense in depth at both the framework and app layers. Guards: two invariant tests in tests/test_packaging_metadata.py assert every server-surface extra pins starlette and that pyproject + uv.lock both resolve >= the 1.0.1 CVE floor — a dropped pin or stale lock fails in CI instead of shipping the bypass. Closes NousResearch#35067
santhreal
pushed a commit
to santhreal/hermes-agent
that referenced
this pull request
Jul 13, 2026
…ousResearch#35118) Starlette < 1.0.1 is affected by CVE-2026-48710 ("BadHost", CWE-444). The HTTP Host header was not validated before being used to rebuild `request.url`, so a malformed Host could make `request.url.path` desync from the raw ASGI path the router actually dispatched. Middleware and endpoints that apply path-based authorization off `request.url` (rather than `scope["path"]`) can therefore be bypassed. Hermes pulls Starlette transitively, never directly: - [web] -> fastapi==0.133.1 (starlette>=0.40.0, no upper bound) - [mcp] -> mcp==1.26.0 + sse-starlette (starlette>=0.27 / >=0.49.1) - [computer-use] -> mcp==1.26.0 - [dev] -> mcp==1.26.0 A fresh resolve landed starlette 0.52.1 — vulnerable. With no upper bound on the transitive specs, pip/uv could resolve any pre-1.0.1 release on a fresh install. Fix: pin starlette==1.0.1 directly in every extra that exposes a Starlette-backed server surface, regenerate uv.lock (only starlette moves: 0.52.1 -> 1.0.1, hash-verified), and mirror the pin in the lazy-install map (tools/lazy_deps.py `tool.dashboard`) so `hermes` on-demand dashboard installs can't re-resolve a vulnerable version. 1.0.1 is the advisory's named fix floor and the oldest patched release (more bake time than 1.1.0/1.2.0, which are days old); it satisfies every carrier constraint and our requires-python>=3.11. Scope note: this is a dependency-level fix complementing the application-layer Host-header validator added in NousResearch#34162 (`hermes_cli/web_server.py` `_is_accepted_host`). Defense in depth at both the framework and app layers. Guards: two invariant tests in tests/test_packaging_metadata.py assert every server-surface extra pins starlette and that pyproject + uv.lock both resolve >= the 1.0.1 CVE floor — a dropped pin or stale lock fails in CI instead of shipping the bypass. Closes NousResearch#35067
donbowman
pushed a commit
to donbowman/hermes-agent
that referenced
this pull request
Jul 13, 2026
…ousResearch#35118) Starlette < 1.0.1 is affected by CVE-2026-48710 ("BadHost", CWE-444). The HTTP Host header was not validated before being used to rebuild `request.url`, so a malformed Host could make `request.url.path` desync from the raw ASGI path the router actually dispatched. Middleware and endpoints that apply path-based authorization off `request.url` (rather than `scope["path"]`) can therefore be bypassed. Hermes pulls Starlette transitively, never directly: - [web] -> fastapi==0.133.1 (starlette>=0.40.0, no upper bound) - [mcp] -> mcp==1.26.0 + sse-starlette (starlette>=0.27 / >=0.49.1) - [computer-use] -> mcp==1.26.0 - [dev] -> mcp==1.26.0 A fresh resolve landed starlette 0.52.1 — vulnerable. With no upper bound on the transitive specs, pip/uv could resolve any pre-1.0.1 release on a fresh install. Fix: pin starlette==1.0.1 directly in every extra that exposes a Starlette-backed server surface, regenerate uv.lock (only starlette moves: 0.52.1 -> 1.0.1, hash-verified), and mirror the pin in the lazy-install map (tools/lazy_deps.py `tool.dashboard`) so `hermes` on-demand dashboard installs can't re-resolve a vulnerable version. 1.0.1 is the advisory's named fix floor and the oldest patched release (more bake time than 1.1.0/1.2.0, which are days old); it satisfies every carrier constraint and our requires-python>=3.11. Scope note: this is a dependency-level fix complementing the application-layer Host-header validator added in NousResearch#34162 (`hermes_cli/web_server.py` `_is_accepted_host`). Defense in depth at both the framework and app layers. Guards: two invariant tests in tests/test_packaging_metadata.py assert every server-surface extra pins starlette and that pyproject + uv.lock both resolve >= the 1.0.1 CVE floor — a dropped pin or stale lock fails in CI instead of shipping the bypass. Closes NousResearch#35067
Gravezzz
pushed a commit
to Gravezzz/hermes-agent
that referenced
this pull request
Jul 21, 2026
…ousResearch#35118) Starlette < 1.0.1 is affected by CVE-2026-48710 ("BadHost", CWE-444). The HTTP Host header was not validated before being used to rebuild `request.url`, so a malformed Host could make `request.url.path` desync from the raw ASGI path the router actually dispatched. Middleware and endpoints that apply path-based authorization off `request.url` (rather than `scope["path"]`) can therefore be bypassed. Hermes pulls Starlette transitively, never directly: - [web] -> fastapi==0.133.1 (starlette>=0.40.0, no upper bound) - [mcp] -> mcp==1.26.0 + sse-starlette (starlette>=0.27 / >=0.49.1) - [computer-use] -> mcp==1.26.0 - [dev] -> mcp==1.26.0 A fresh resolve landed starlette 0.52.1 — vulnerable. With no upper bound on the transitive specs, pip/uv could resolve any pre-1.0.1 release on a fresh install. Fix: pin starlette==1.0.1 directly in every extra that exposes a Starlette-backed server surface, regenerate uv.lock (only starlette moves: 0.52.1 -> 1.0.1, hash-verified), and mirror the pin in the lazy-install map (tools/lazy_deps.py `tool.dashboard`) so `hermes` on-demand dashboard installs can't re-resolve a vulnerable version. 1.0.1 is the advisory's named fix floor and the oldest patched release (more bake time than 1.1.0/1.2.0, which are days old); it satisfies every carrier constraint and our requires-python>=3.11. Scope note: this is a dependency-level fix complementing the application-layer Host-header validator added in NousResearch#34162 (`hermes_cli/web_server.py` `_is_accepted_host`). Defense in depth at both the framework and app layers. Guards: two invariant tests in tests/test_packaging_metadata.py assert every server-surface extra pins starlette and that pyproject + uv.lock both resolve >= the 1.0.1 CVE floor — a dropped pin or stale lock fails in CI instead of shipping the bypass. Closes NousResearch#35067
leewenjie
pushed a commit
to leewenjie/hermes-agent
that referenced
this pull request
Aug 7, 2026
…ousResearch#35118) Starlette < 1.0.1 is affected by CVE-2026-48710 ("BadHost", CWE-444). The HTTP Host header was not validated before being used to rebuild `request.url`, so a malformed Host could make `request.url.path` desync from the raw ASGI path the router actually dispatched. Middleware and endpoints that apply path-based authorization off `request.url` (rather than `scope["path"]`) can therefore be bypassed. Hermes pulls Starlette transitively, never directly: - [web] -> fastapi==0.133.1 (starlette>=0.40.0, no upper bound) - [mcp] -> mcp==1.26.0 + sse-starlette (starlette>=0.27 / >=0.49.1) - [computer-use] -> mcp==1.26.0 - [dev] -> mcp==1.26.0 A fresh resolve landed starlette 0.52.1 — vulnerable. With no upper bound on the transitive specs, pip/uv could resolve any pre-1.0.1 release on a fresh install. Fix: pin starlette==1.0.1 directly in every extra that exposes a Starlette-backed server surface, regenerate uv.lock (only starlette moves: 0.52.1 -> 1.0.1, hash-verified), and mirror the pin in the lazy-install map (tools/lazy_deps.py `tool.dashboard`) so `hermes` on-demand dashboard installs can't re-resolve a vulnerable version. 1.0.1 is the advisory's named fix floor and the oldest patched release (more bake time than 1.1.0/1.2.0, which are days old); it satisfies every carrier constraint and our requires-python>=3.11. Scope note: this is a dependency-level fix complementing the application-layer Host-header validator added in NousResearch#34162 (`hermes_cli/web_server.py` `_is_accepted_host`). Defense in depth at both the framework and app layers. Guards: two invariant tests in tests/test_packaging_metadata.py assert every server-surface extra pins starlette and that pyproject + uv.lock both resolve >= the 1.0.1 CVE floor — a dropped pin or stale lock fails in CI instead of shipping the bypass. Closes NousResearch#35067
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #35067
What
Pin
starlette==1.0.1directly in every extra that exposes a Starlette-backed server surface, fixing CVE-2026-48710 ("BadHost", CWE-444).Starlette < 1.0.1 did not validate the HTTP
Hostheader before rebuildingrequest.url. Because routing dispatches on the raw ASGI path whilerequest.urlis reconstructed fromHost, a malformed header can makerequest.url.pathdiffer from the path actually requested — so middleware/endpoints that gate authorization onrequest.url(instead ofscope["path"]) can be bypassed. CVSS 6.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N).Why it reached us
Hermes pulls Starlette transitively only, with no upper bounds on the carriers:
webfastapi==0.133.1starlette>=0.40.0mcpmcp==1.26.0+sse-starlettestarlette>=0.27/>=0.49.1computer-usemcp==1.26.0devmcp==1.26.0A fresh lock resolution landed starlette 0.52.1 — vulnerable. With unbounded transitive specs, a fresh
pip/uvinstall could resolve any pre-1.0.1 release.The fix
starlette==1.0.1to theweb,mcp,computer-use, anddevextras inpyproject.toml.tools/lazy_deps.pytool.dashboardsohermeson-demand dashboard installs can't re-resolve a vulnerable Starlette.uv.lock— only starlette moves (0.52.1 → 1.0.1, sha256-verified); no transitive flipped.Version choice:
1.0.1is the advisory's named fix floor and the oldest patched release (more bake time than1.1.0/1.2.0, which are days old per the no-bleeding-edge supply-chain rule). It satisfies every carrier constraint and ourrequires-python>=3.11(starlette 1.0.1 needs>=3.10).Scope / defense-in-depth
This is the dependency-level fix. It complements the application-layer Host-header validator (
hermes_cli/web_server.py_is_accepted_host) landed in #34162. Both layers stay — framework patch + app-layer allowlist.No base-install impact: Starlette stays out of core deps, so default installs are unaffected (no capability regression). Only the four server-surface extras gain the pin.
Tests / verification
uv lock --checkclean (no drift).uv sync --locked --extra web --extra mcpinstallsstarlette==1.0.1+fastapi==0.133.1+sse-starlettewith no resolver conflict; real import test passes.tests/test_packaging_metadata.py:test_starlette_pinned_above_cve_2026_48710_floor_in_pyproject— every server-surface extra must pin starlette>= 1.0.1.test_locked_starlette_is_not_vulnerable_to_cve_2026_48710— the committed lockfile must resolve>= 1.0.1.pytest tests/test_packaging_metadata.py tests/tools/test_lazy_deps.py tests/hermes_cli/test_web_server_host_header.py→ 78 passed.