Skip to content

Release v0.47.1 - #6554

Merged
rdimitrov merged 1 commit into
mainfrom
release/v0.47.1
Sep 8, 2026
Merged

Release v0.47.1#6554
rdimitrov merged 1 commit into
mainfrom
release/v0.47.1

Conversation

@toolhive-release-app

Copy link
Copy Markdown
Contributor

Release v0.47.1

Version Bump

patch release

Files Updated

  • VERSION
  • deploy/charts/operator-crds/Chart.yaml (path: version)
  • deploy/charts/operator-crds/Chart.yaml (path: appVersion)
  • deploy/charts/operator/Chart.yaml (path: version)
  • deploy/charts/operator/Chart.yaml (path: appVersion)
  • deploy/charts/operator/values.yaml (path: operator.image)
  • deploy/charts/operator/values.yaml (path: operator.toolhiveRunnerImage)
  • deploy/charts/operator/values.yaml (path: operator.vmcpImage)
  • Helm chart docs (via helm-docs)

Next Steps

  1. Review this PR
  2. Merge to main
  3. Release automation will handle the rest

Checklist

  • Version bump is correct
  • All CI checks pass

Release-Triggered-By: rdimitrov
@github-actions github-actions Bot added the size/XS Extra small PR: < 100 lines changed label Sep 8, 2026
@codecov

codecov Bot commented Sep 8, 2026

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 78.70%. Comparing base (a1f16ce) to head (da61aa8).

Additional details and impacted files
@@           Coverage Diff           @@
##             main    #6554   +/-   ##
=======================================
  Coverage   78.70%   78.70%           
=======================================
  Files         777      777           
  Lines       76949    76949           
=======================================
  Hits        60564    60564           
  Misses      16380    16380           
  Partials        5        5           

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@rdimitrov
rdimitrov merged commit 73c80e3 into main Sep 8, 2026
72 of 73 checks passed
@rdimitrov
rdimitrov deleted the release/v0.47.1 branch September 8, 2026 20:22
@github-actions

github-actions Bot commented Sep 8, 2026

Copy link
Copy Markdown
Contributor

📝 Generated release notes for v0.47.1

Auto-generated by the release-notes skill. Review and, if good, apply with:

gh release edit v0.47.1 --notes-file <paste-below>.md
Click to expand release notes

🚀 Toolhive v0.47.1 is live!

A security patch release. Two vulnerabilities reported through our private security-advisory process are fixed: an authorization bypass that leaked resource-template descriptors past Cedar policy, and a shared permission-profile mutation that could leak host volume mounts and network settings between workloads. The rest of the release is CI cost tuning.

🔒 Security

Both fixes were merged from private security-advisory forks, so they do not appear as pull requests in the commit log below.

  • resources/templates/list bypassed Cedar authorization — with an authz config in place, resources/templates/list was classified as a list operation (so no request-time check ran) but had no registered response filter, so every authenticated caller received the backend's complete resource-template list regardless of policy. Templates are now filtered per item against read_resource on the RFC 6570 uriTemplate, and the middleware now fails closed if any protected list method is ever added without a filter. (a1f16ce) — some Cedar policy sets need an update
  • Permission profiles leaked between workloads — the run config builder mutated the registry-owned permission profile in place, so --volume host bind mounts and network-mode changes accumulated onto it and were inherited by every later workload built from the same registry entry in the same process. The builder now deep-clones the profile before applying any workload-specific settings. (1f75a71)
Action required: Cedar policies that enumerate concrete resource URIs

Neither fix changes an API, CLI flag, config schema, or CRD field, and no configuration that worked as designed stops working. But because resources/templates/list was previously unfiltered, a Cedar deployment can legitimately see fewer items in that list than it did on v0.47.0.

Who is affected: deployments with Cedar authorization configured — thv run --authz-config, MCPServer.spec.authzConfig in the operator, and thv-proxyrunner — whose MCP server advertises resource templates. Workloads with no authz config are unaffected (the middleware is never added to the chain). Virtual MCP with incomingAuth.authz.type: cedar was already filtering templates at the vMCP core admission seam, so this is defence in depth there.

Cedar entity IDs for read_resource are the exact URI string, and a template's identifier is the literal template including its braces — it does not match a policy written against an expanded URI. A policy set that enumerates concrete resource URIs will now return an empty resourceTemplates array. Reads still work; only template discovery is lost.

Before

permit(principal, action == Action::"read_resource", resource == Resource::"file:///public/report.txt");

After

Option A — grant the template string explicitly (most precise):

permit(principal, action == Action::"read_resource", resource == Resource::"file:///public/report.txt");
permit(principal, action == Action::"read_resource", resource == Resource::"file:///public/{name}");

Option B — prefix match covering both concrete URIs and templates:

permit(principal, action == Action::"read_resource", resource)
when { resource.uri like "file:///public/*" };

Migration steps

  1. Check whether your MCP server advertises resource templates (resources/templates/list returns a non-empty list without authz).
  2. If it does, review your Cedar policies for read_resource rules that name concrete resource URIs.
  3. Add a rule for the literal uriTemplate string, or replace the exact-match rules with a resource.uri like "..." prefix match.
  4. Policies that are unconstrained on the resource, or that already use a like prefix, need no change.
Audit note: workloads created through the API server

The permission-profile leak is only observable in a process that builds more than one run config: the long-lived API server (thv serve, and the UI/desktop app that drives it) with a custom registry API configured, and code embedding pkg/runner's RunConfigBuilder across builds. thv run, thv restart, the Kubernetes operator, and thv-proxyrunner are not affected.

Leaked values were persisted into the affected workload's saved run configuration, so restarting does not clear them. To audit:

thv export <workload> ./config.json

Check permission_profile.read, permission_profile.write, and permission_profile.network.mode for entries you did not request, and recreate any workload showing unexpected mounts or a widened network mode.

🧹 Misc

  • Short CI jobs now run on the free standard runner instead of the paid large runner, cutting roughly 21 large-runner minutes per run with no change to overall wall time (#6541).
  • Operator E2E runs against a single Kubernetes version on pull requests, with the full three-version matrix kept for pushes to main and manual dispatches (#6540).
Full commit log

What's Changed

Full Changelog: v0.47.0...v0.47.1

🔗 Full changelog: v0.47.0...v0.47.1

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

release size/XS Extra small PR: < 100 lines changed

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant