This release includes 1 security fix for security teams reviewing exposed deployments.
Topics
+8 more
Affected surfaces
ReleasePort's take
Moderate signalkubefwd v1.25.15 now mandates Bearer‑token authentication for its REST API while keeping the health endpoint unauthenticated.
Why it matters: Security: all API calls require a bearer token (severity 90); only /health remains open, tightening access controls for operators and integrations.
Summary
AI summaryUpdates Highlights, CI / Build, and kubefwd v1.25.15 across a mixed release.
Changes in this release
| Type | Severity | Summary | CVE |
|---|---|---|---|
| Security | Critical |
REST API now requires Bearer-token authentication; health endpoint remains unauthenticated. REST API now requires Bearer-token authentication; health endpoint remains unauthenticated. Source: llm_adapter@2026-05-29 Confidence: high |
— |
| Bugfix | Medium |
Multi‑port services recover after a single port is reset, fixing unrecoverable zombie state. Multi‑port services recover after a single port is reset, fixing unrecoverable zombie state. Source: llm_adapter@2026-05-29 Confidence: high |
— |
Full changelog
kubefwd v1.25.15
Highlights
🔒 REST API now requires authentication (security)
The optional REST API (--api) and the HTTP MCP bridge previously served every endpoint — Kubernetes context enumeration, pod log reads, and port-forward creation — with no authentication. Because kubefwd runs as root via sudo -E, any local process could drive it against your kubeconfig. This release adds Bearer-token authentication, addressing advisory GHSA-vwjh-p4vp-9rp2 (#507, #508).
- The API key is resolved from
KUBEFWD_API_KEY; if unset, a random 32-character hex key is generated and only its last 4 characters are logged on startup. - All endpoints require
Authorization: Bearer <key>except/api/health, which stays open for liveness probes. - Token comparison uses
crypto/subtle.ConstantTimeCompareto avoid timing side channels. kubefwd mcpreadsKUBEFWD_API_KEYautomatically; a new--api-keyflag overrides it.
[!IMPORTANT]
Upgrade note: If you use--apior the HTTP MCP bridge, set a known key so automation/CI can authenticate instead of scraping a generated one from logs:export KUBEFWD_API_KEY=my-known-key sudo -E kubefwd svc -n my-namespace --api
🐛 Multi-port services recover after a single port is reset (#509)
Fixed an unrecoverable zombie state in which a multi-port service that lost one port's connection — e.g. the TCP RST behavior of kubernetes/kubernetes#111825 — would never re-establish that port or restore its /etc/hosts entries. Auto-reconnect (-a, on by default in --tui) found the pod but did nothing, and only a full kubefwd restart recovered the service.
syncNormalService now reasons in terms of the pod being forwarded rather than a single port: it keeps every port of that pod and re-establishes any that were torn down independently. This also fixes a related regression where a healthy multi-port service could drop all but one port on the periodic resync. (#509, #510)
Dependencies
golang.org/x/sys→ 0.45.0 (#502)github.com/modelcontextprotocol/go-sdk→ 1.6.1 (#501)
CI / Build
goreleaser/goreleaser-action→ 7.2.2 (#500)github/codeql-action→ 4.36.0 (#504, #499)golangci/golangci-lint-action→ 9.2.1 (#506)docker/setup-buildx-action→ 4.1.0 (#505)docker/login-action→ 4.2.0 (#503)codecov/codecov-action→ 6.0.1 (#498)
Full changelog: https://github.com/txn2/kubefwd/compare/v1.25.14...v1.25.15
Breaking Changes
- REST API endpoints now require `Authorization: Bearer <token>`; only `/api/health` remains unauthenticated.
Security Fixes
- GHSA-vwjh-p4vp-9rp2 — Added Bearer‑token authentication to the REST API and HTTP MCP bridge, preventing unauthorized access when kubefwd runs as root.
Weekly OSS security release digest.
The CVE patches and breaking changes that affected production tools this week. One email, every Sunday.
No spam, unsubscribe anytime.
Share this release
About txn2/kubefwd
Kubernetes bulk port forwarding with service discovery, /etc/hosts management, traffic monitoring, and pod log streaming
Related context
Related tools
Beta — feedback welcome: [email protected]