GitHub Actions September 2026: Three Pipeline Fixes

GitHub shipped three Actions changes on September 3, 2026: a runner deprecation REST API, a new `vulnerability-alerts` permission for `GITHUB_TOKEN` that grants read-only Dependabot alert access without a stored Personal Access Token, and four new `job` context properties (`job.workflow_ref`, `job.workflow_sha`, `job.workflow_repository`, `job.workflow_file_path`) that let reusable workflows identify their own source repository, commit SHA, and file path. The new `vulnerability-alerts` permission supports `read` and `none`, and the `job` context properties are available only on GitHub.com, not GitHub Enterprise Server in this release.

On September 3, GitHub shipped three changes to Actions that most developers missed while watching the AI release cycle. No new model, no Copilot integration, no viral tweet. What shipped was a runner deprecation REST API, a new GITHUB TOKEN permission for Dependabot alerts, and four new job context properties for reusable workflows. Each one closes a gap that has been making pipelines brittle or forcing ugly credential workarounds for years. Worth fifteen minutes of your attention. Kill the PAT: vulnerability-alerts Permission Is Here Reading Dependabot alerts from a workflow has always required a stored Personal Access Token with security events scope — a broad, long-lived credential sitting in your repo secrets, rotated manually, and quietly accumulating scope-creep across the org. The new vulnerability-alerts permission for GITHUB TOKEN eliminates all of that. Add two lines to your workflow and you have read-only Dependabot alert access — no PAT required: permissions: contents: read vulnerability-alerts: read The permission supports read and none . Here is a minimal security gate that blocks deployment when critical Dependabot alerts are open: name: Security Gate on: push permissions: vulnerability-alerts: read jobs: check-alerts: runs-on: ubuntu-latest steps: - name: Block on critical Dependabot alerts run: | ALERTS=$ gh api /repos/${{ github.repository }}/dependabot/alerts \ --jq ' . | select .state=="open" and .security advisory.severity=="critical" | length' if "$ALERTS" -gt "0" ; then echo "$ALERTS critical alerts open. Fix before deploy." exit 1 fi This should have been possible two years ago. Every team that wanted automated Dependabot gates without PAT sprawl was stuck. Now it is not. If your security posture relies on a stored security events PAT today, replacing it with this permission is the first thing to do this week. The GitHub secure use reference https://docs.github.com/en/actions/reference/security/secure-use documents the full permissions model. Reusable Workflows Can Finally Identify Themselves Reusable workflows are how large engineering orgs share CI/CD logic across dozens of repositories. Their persistent problem was self-identification: a reusable workflow had no reliable way to know its own source repository, commit SHA, or file path at runtime. github.workflow ref points to the caller’s workflow, not the callee’s, which means audit logs attributed CI runs to the wrong place. September 3 fixed this with four new job context properties available when a workflow is invoked as a reusable workflow: - job.workflow ref — full ref of the workflow file that defines the current job - job.workflow sha — commit SHA of the workflow file - job.workflow repository — owner/repo of the workflow file - job.workflow file path — file path relative to the repository root The key behavior: for a regular workflow job, job.workflow ref and github.workflow ref match. For a called reusable workflow, they diverge — job.workflow ref identifies the callee, github.workflow ref still identifies the caller. That divergence is the whole point. Your shared deploy workflow can now log its own source identity without being passed explicit inputs: org/.github/workflows/shared-deploy.yml jobs: deploy: runs-on: ubuntu-latest steps: - name: Audit log run: | echo "Workflow: ${{ job.workflow ref }}" echo "SHA: ${{ job.workflow sha }}" echo "Repo: ${{ job.workflow repository }}" One limitation: these properties are only available on GitHub.com. GitHub Enterprise Server does not get them in this release. Check the contexts reference https://docs.github.com/en/actions/reference/workflows-and-actions/contexts for the complete job context schema. The Runner Deprecation API — Right Before the September 25 Deadline GitHub is enforcing a minimum self-hosted runner version 2.329.0 starting September 25 for GitHub Enterprise Cloud. If you manage many self-hosted runners and want to know which versions will stop receiving jobs before they actually stop, there is now a REST API for that. The endpoint is available at repository, organization, and enterprise scope: GET https://api.github.com/orgs/YOUR ORG/actions/runners/deprecations/2.300.0 The response includes runner version , runtime deprecates at , and registration deprecates at . Write a script that loops your runner versions, hits this endpoint for each, and fires a Slack alert when runtime deprecates at is within 30 days. Your ops team knows before pipelines go dark, not after. For the enforcement deadline itself, see GitHub Actions Self-Hosted Runners: Fix Before September 25 https://byteiota.com/github-actions-runner-enforcement-september-2026/ . What to Do This Week 1. Replace any security events PATs in CI with vulnerability-alerts: read on GITHUB TOKEN . Audit your repo secrets — PATs with this scope are now unnecessary and should be revoked. 2. Add job.workflow ref logging to your reusable workflows if you share CI logic across repos. Immediate audit traceability with zero infrastructure cost. 3. Query the runner deprecation API against your fleet before September 25. Any runner version with a past runtime deprecates at needs an upgrade now. Review your Actions cache configuration https://byteiota.com/github-actions-cache-mode-lock-down-your-ci-cache/ while you are in the runner settings. All three changes are live for all GitHub.com users now. The full changelog is on the GitHub Blog https://github.blog/changelog/2026-09-03-github-actions-early-september-2026-updates/ . GitHub’s broader security direction for Actions is documented in the 2026 security roadmap https://github.blog/news-insights/product-news/whats-coming-to-our-github-actions-2026-security-roadmap/ — these three updates are direct items from it.