txn2/kubefwd is a Go CLI that bulk forwards Kubernetes services to unique loopback IPs so a laptop can resolve in cluster hostnames such as postgres:5432 or redis:6379. The last seven days produced one commit. On 8 September 2026 Craig Johnston rolled twelve open Dependabot PRs into a single change. Ten files changed, with 75 insertions and 184 deletions. No CLI flags moved. The useful work is the client pins, a docs lockfile Dependabot would have left broken, and three GHSA alerts that do not sit in the shipped binary.
Kubernetes clients move to 0.36.3 ¶
kubefwd reaches the API server through k8s.io/client-go, k8s.io/cli-runtime, k8s.io/kubectl, and k8s.io/streaming. Those modules, plus k8s.io/api and k8s.io/apimachinery, all moved from v0.36.2 to v0.36.3 in go.mod. k8s.io/component-base and sigs.k8s.io/structured-merge-diff/v6 followed on the same line. golang.org/x/time ticked from v0.14.0 to v0.15.0 as an indirect.
This is a patch on the 1.36 client train. It does not add flags and it does not change how sudo -E kubefwd svc -n ... binds loopback aliases or rewrites /etc/hosts. Operators who install a GitHub Release, a brew bottle, or a winget package see nothing until the next tagged build. Downstream Go importers that require github.com/txn2/kubefwd pick up the new client set on the next go get.
The same commit also moved github.com/modelcontextprotocol/go-sdk from v1.6.1 to v1.7.0. That library backs kubefwd mcp, the stdio bridge that talks to a running REST API without sudo so an editor can list forwarded services. Source under cmd/kubefwd/mcp did not change. Treat the SDK bump as a pin, not a feature drop.
k8s.io/api v0.36.3
k8s.io/apimachinery v0.36.3
k8s.io/cli-runtime v0.36.3
k8s.io/client-go v0.36.3
k8s.io/kubectl v0.36.3
k8s.io/streaming v0.36.3
A naive docs pin would have failed the hash check ¶
The docs job in .github/workflows/docs.yml still runs pip install --require-hashes -r .github/requirements-docs.txt and then mkdocs build --strict. Dependabot’s own patch only rewrote two version lines: mkdocs-material from 9.5.50 to 9.7.7 and pymdown-extensions from 11.0 to 11.0.1.
That patch would have been wrong. Material 9.7.7 adds backrefs. pymdown 11.0.1 drops regex. Under --require-hashes, pip refuses an unpinned backrefs and the docs job dies before MkDocs runs. The commit regenerates .github/requirements-docs.txt with pip-compile instead of taking the bot diff as is. Most of the 137 line swing in that file is the regex hash block leaving, plus the new backrefs==8.0 pin with its own hashes.
If you keep hash pinned Python installs in CI, this is the failure mode to remember. A version bump in a compiled requirements file is not a two line edit. Rebuild the lock, then confirm pip install --require-hashes and mkdocs build --strict both pass. The commit message says those two checks ran.
Security alerts live in tests and docs, not the CLI ¶
The commit message lists three Dependabot alerts. None of them sit on the path that opens SPDY streams to Pods.
github.com/moby/go-archive in test/integration/go.mod moved from v0.2.0 to v0.3.0 (GHSA-hfg8-hc9c-6c3h, high). The integration module uses testcontainers-go to start Docker sidecars for forwarding tests. go-archive is an indirect extractor. v0.3.0 hardens tar unpack so a crafted archive cannot follow links out of the destination directory (CVE-2026-17106). The blast radius is CI runners that pull images, not laptops running kubefwd svc. Transitive bumps came along: klauspost/compress 1.18.7, moby/sys/sequential 0.7.0, moby/sys/user 0.4.1.
pymdown-extensions 11.0.1 closes GHSA-gm37-52c6-37mw. Four inline processors (caret, tilde, betterem, magiclink) had regular expressions with exponential backtracking. A short untrusted Markdown line could pin a CPU on the render thread. For this repo the renderer is the docs job, which builds committed docs, not public paste.
mkdocs-material 9.7.7 closes GHSA-xvg9-69gf-fjrf, a medium DOM XSS in search suggestions. That one can reach visitors of the published docs site. It is the only alert with a reader facing blast radius, and even then it is the docs origin, not the port forward process.
Action SHAs move, including a major setup go tag ¶
.github/workflows/ci.yml, plus the CodeQL, docs, release, and Scorecard workflows, pin Actions by full SHA with a version comment. actions/checkout went from 7.0.0 to 7.0.1. actions/setup-go jumped from 6.5.0 to 7.0.0. CodeQL init, analyze, and upload-sarif moved 4.37.2 to 4.37.3. Scorecard moved 2.4.3 to 2.4.4. The Scorecard upload step also dropped a stale # v3 comment that no longer matched the SHA it sat on.
setup go v7 is a major tag. Upstream says the action internals moved to ESM and that inputs, outputs, and behavior stay the same. The workflows still ask for Go 1.26, matching go 1.26.0 in the main module. The integration module stays on go 1.25.0. That split is unchanged.
The repo already runs scripts/validate-action-shas.sh as its first CI job. The commit claims that script passed and that every SHA matches its upstream tag. That is the right check when you refuse floating major tags on a tool that ships SLSA attestations.
What to watch ¶
The next tagged release is what actually ships client-go 0.36.3 to brew, winget, and GitHub Releases users. Until then this lives on master only.
Keep the hash compile step. The next Dependabot PR against requirements-docs.txt will try the two line pin again. Reject it unless pip-compile reruns and --require-hashes still installs.
The MCP SDK is now 1.7.0 with no matching source change. If a later commit starts using new SDK types, that is when kubefwd mcp behavior can actually shift. Watch cmd/kubefwd/mcp, not this pin.