Patch Week Playbook: GitHub Actions Gets a Bouncer and Kubernetes 1.34 Nears End of Life

Anyone who has worked a restaurant knows the rule: the health inspector doesn't announce the visit, but the kitchen is always cleaner the week after one happens.

The past few weeks sent DevOps and DevSecOps teams a bunch of small inspection notices. GitHub Actions got a real bouncer. Kubernetes shipped fixes for two security advisories. The upstream 1.34 release is nearing its end of life. And GitHub changed how long it keeps your CI run history.

None of it is a five-alarm fire. All of it is the kind of thing that turns into a fire if nobody owns it. So here's a single playbook: what happened, who it affects, and a short checklist you can run in an afternoon.

What We Are Cooking Today

• Summarize what changed in CI/CD and Kubernetes security this month
• Audit your pipelines and clusters with a handful of quick commands
• Prioritize what to fix first, and what can wait

The News, Sorted by "Does This Affect Me?"

CI/CD: GitHub Actions

Workflow execution protections are generally available (September 17). By default, anyone with write access to a repository can trigger a workflow. Execution protections add an allowlist that controls who can trigger workflows (actor rules) and what events can start them (event rules). Rules are evaluated before a run begins, can be scoped to specific workflow files, and can be managed through a REST API. You'll find them under Settings, then Actions, then Policies.

The part to read twice: for public repositories that don't already have an applicable event policy, GitHub is introducing a default rule that disables pull_request_target. Specific workflows can be allowlisted. If you maintain open-source projects that use pull_request_target (often to give fork PRs access to variables), check whether your workflows are affected. Community reports also note that the Insights dashboard for policy evaluation is an enterprise feature.

Why GitHub is doing this: pull_request_target runs with the base repository's permissions. If a workflow also checks out untrusted pull request code, that's a classic path to poisoned pipelines. One secondary report says actions/checkout v7 now refuses to fetch fork PR code in such workflows unless you set allow-unsafe-pr-checkout. I haven't verified that against the official release notes, so check before relying on it.

Retention is changing (October 1). Checks, workflow runs, and statuses used to be kept for 400+ days regardless of settings. Now they follow the same Actions retention setting that governs artifacts and logs, with a default of 90 days. If you need run history for audits, review your retention setting, and remember that longer retention can increase billable storage.

macOS 14 runner image retirement. GitHub's changelog lists this as retired on October 1. If any workflow still says runs-on: macos-14, move it.

Kubernetes

Two security advisories, September 24. According to the Last Week in Kubernetes Development newsletter:

• CVE-2026-2270 (Medium, 5.9): a confused deputy issue in the StatefulSet controller. A user with namespace-scoped write permissions on StatefulSet and ControllerRevision objects could create a cross-namespace pod.
• CVE-2026-76654 (Medium, 5.8): an NTLM coercion issue on Windows nodes when a pod's subPath is a symlink to an attacker-controlled UNC share.

Both are fixed in the September patch releases: v1.34.12, v1.35.9, v1.36.5, and v1.37.1. Neither is rated critical, and I'm not aware of confirmed exploitation, but "medium" isn't "ignore."

More patches are on the way. The next scheduled patch round (1.37.2, 1.36.6, 1.35.10) was reported for October 20. Check the official Kubernetes patch calendar for exact dates.

Upstream 1.34 reaches end of life on October 27. That's according to multiple trackers, so confirm on the Kubernetes releases page. One nuance worth pausing on: upstream end of life isn't the same as your managed provider's support window. Amazon EKS, for example, tracks its own calendar (standard support for 1.34 on EKS runs to December 2, 2026 per endoflife.date). But you're still depending on the provider to backport security fixes, so know exactly what they promise.

Runtime and datastore patches too. The same newsletter lists new containerd releases (including v2.4.1, which fixes CVE-2026-53493) and etcd v3.7.2. Kubernetes security isn't only the control plane.

One for the calendar: KubeCon + CloudNativeCon North America 2026 runs November 9-12 in Salt Lake City.

Ingredients

• kubectl access to your clusters (read access is enough for most checks)
• The gh CLI, authenticated to your GitHub org (or just a terminal and your repos checked out)
• A list of your clusters and their versions
• About an hour

Kitchen Prep

Everything below is read-only. You're inspecting, not changing, so run it freely. Fixes come after you know what you have.

Recipe Steps

Step 1: Know your Kubernetes versions (server, nodes, and client)

kubectl version
kubectl get nodes -o custom-columns=NAME:.metadata.name,KUBELET:.status.nodeInfo.kubeletVersion,RUNTIME:.status.nodeInfo.containerRuntimeVersion

Expected: server, client, kubelet, and container runtime versions. Why the client matters: some fixes land in kubectl itself, so engineers running ancient local clients are part of your attack surface. Compare what you see against the fixed versions above.

Step 2: Check the StatefulSet exposure (CVE-2026-2270)

Exploitability depends on principals who can write both StatefulSets and ControllerRevisions in a namespace. Test a suspicious user or service account:

kubectl auth can-i update statefulsets -n <namespace> --as <user-or-sa>
kubectl auth can-i update controllerrevisions -n <namespace> --as <user-or-sa>

If both answers are yes for a principal that shouldn't have both, tighten the role while you schedule the patch. For a broader look, list the roles that mention these resources:

kubectl get roles,clusterroles -A -o json | jq -r '
  .items[]
  | select(any(.rules[]?; (.resources // []) | any(. == "statefulsets" or . == "controllerrevisions" or . == "*")))
  | "\(.kind) \(.metadata.namespace // "-")/\(.metadata.name)"'

Step 3: Find pull_request_target in your workflows

In a local checkout:

grep -rn "pull_request_target" .github/workflows/

Across an organization with the GitHub CLI:

gh search code pull_request_target --owner <your-org> --extension yml

For each hit, ask one question: does this workflow check out code from the pull request? If it does and it also has access to secrets or a write token, that's the pattern GitHub is trying to stop. Prefer the plain pull_request trigger where you can.

Step 4: Decide your execution policy

In your repository or organization settings, open Actions, then Policies. For sensitive workflows (deployments, releases), consider restricting who and what can trigger them, and leave ordinary CI open to a wider set of contributors. The GA release supports targeting individual workflow files, which is what makes this practical.

Step 5: Pin third-party actions to commit SHAs

Tags can move. Commit SHAs can't. Pin third-party actions, and keep the version in a comment so humans can still read it:

- uses: actions/checkout@<full-40-char-commit-sha> # v7

Let Dependabot or Renovate update the pins through pull requests. You get the safety of pinning without becoming the person who updates 200 SHAs by hand.

Step 6: Review retention and old runner labels

grep -rn "macos-14" .github/workflows/

For retention, open Settings, then Actions, then General, and look at the artifact and log retention setting. Decide how long you truly need run history, especially for audit and compliance reasons.

Step 7: Plan the upgrade ladder

Kubernetes only upgrades one minor version at a time. If you're on 1.34, the path is 1.34, 1.35, 1.36, then 1.37, and each hop needs its own rehearsal. Put the dates in a calendar, not in someone's memory.

Chef Tips

• Triage by blast radius, not by CVSS alone. A medium-severity bug in a multi-tenant cluster with loose RBAC can matter more than a higher score somewhere locked down. That's my opinion, but it's served me well.
• Make "who can trigger production workflows" a documented answer. If nobody can say, the answer is probably "everyone with write access."
• Patch the boring layers. Container runtime and etcd updates rarely get the headlines the control plane gets.
• Write the exceptions down. If you allowlist a pull_request_target workflow, leave a comment explaining why and who reviewed it.

Kitchen Disasters

Symptom	Likely cause	Fix
Fork PR workflows suddenly stop running in a public repo	Default rule disabling pull_request_target applies	Rework to pull_request, or explicitly allowlist the specific workflow file after review
Old workflow runs or checks disappear	Retention now applies to checks, runs, and statuses	Raise retention where you truly need history, and export audit data elsewhere
macOS jobs fail to start	Retired runner label	Move to a currently supported macOS runner label
auth can-i returns yes for too many users	Over-broad RBAC, often from wildcard rules	Replace wildcards with explicit resources and verbs
Cluster stuck on an unsupported version	Upgrade deferred repeatedly	Treat the upgrade as scheduled work with an owner and a date

Serving Suggestions

• Pair this with our Kubernetes security best practices for the cluster-hardening side.
• Manage Actions policies as code through the REST API so rules stay consistent across hundreds of repositories.
• Add a scheduled job that reports clusters within 60 days of leaving standard support, so the calendar nags you instead of the other way around.
• Run a short tabletop: "A contributor's PR runs in our deployment workflow. What stops it?" If the answer is a pause and a shrug, you have your next project.

Cleanup

Nothing to tear down. If you temporarily broadened RBAC or retention during testing, put those back, and file what you found somewhere your team will see it.

Frequently Asked Questions

Do these Kubernetes CVEs need an emergency patch?

Both are rated Medium in the newsletter coverage, with no confirmed exploitation I'm aware of. That says "patch promptly in your normal cycle, and tighten RBAC now where cheap." It doesn't say "wake the team at midnight." Read the official advisories for your environment.

Will the pull_request_target default break my private repositories?

The default rule is described for public repositories without an existing applicable event policy. Private repositories can still use execution protections if you configure them. Check the GitHub docs for your plan.

What does upstream end of life mean if I'm on a managed service?

It means upstream stops releasing patches for that branch. Your provider may keep supporting its own version for longer, but read their lifecycle policy to see exactly what they patch and for how long.

Is SHA pinning really worth the maintenance?

For third-party actions, yes. The annoyance is automated away by Dependabot or Renovate, and the benefit is that a retagged release can't silently change what your pipeline runs.

Final Thoughts

Security work rarely arrives as one big event. It arrives as ten small notices that each look skippable. This week's batch is a good reminder to batch them: one afternoon, one checklist, one owner. Check your workflows, check your RBAC, check your versions, and write the dates down. The inspector will be back, as they always are.

🔥 Related CloudChef Recipes

Related posts load automatically on the live site.

References

• GitHub Changelog: Workflow execution protections generally available
• GitHub Changelog: Actions retention will cover checks, workflow runs, and statuses
• Last Week in Kubernetes Development: week ending September 27, 2026
• Kubernetes releases and patch schedule
• endoflife.date: Amazon EKS release and support dates