# GitHub Actions September 2026: Three Pipeline Fixes > Source: > Published: 2026-09-18 17:10:31+00:00 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.