GitHub Actions September 2026: Three Updates for Workflow Control

GitHub published three GitHub Actions updates on 3 September 2026. The changes cover: a REST API for checking runner version deprecation timelines, a new vulnerability-alerts permission for GITHUB_TOKEN that scopes access to Dependabot alerts, and four job context properties that give reusable workflows a way to identify which workflow file and commit they originate from at runtime.

What happened

Update	Detail
Runner deprecation API endpoint	GET /actions/runners/deprecations/{version}
API response fields	runner_version, runtime_deprecates_at, registration_deprecates_at
New GITHUB_TOKEN permission	vulnerability-alerts (values: read, none)
New job context properties	job.workflow_ref, job.workflow_sha, job.workflow_repository, job.workflow_file_path
Enterprise Server support	Job context properties not available

Runner deprecation REST API

You can now call GET /actions/runners/deprecations/{version} at the repository, organization, or enterprise level to find out exactly when a runner version will stop accepting new registrations and when runtime support ends. The response returns runner_version, runtime_deprecates_at, and registration_deprecates_at, giving you the specific dates you need to plan upgrades before GitHub drops support.

Vulnerability-alerts permission for GITHUB_TOKEN

Workflows can now read Dependabot alerts without relying on broader token scopes. The new vulnerability-alerts permission accepts two values: read (grants access to alerts) and none (explicitly denies it). This fits the least-privilege pattern: grant only what the job actually needs, nothing more. The permission is set via the permissions key in your workflow syntax, the same place you control other GITHUB_TOKEN scopes.

Job context properties for reusable workflows

Reusable workflows (pre-packaged workflow files that other workflows call as a step) now have four new properties on the job context:

• job.workflow_ref: the full ref of the workflow file that defines the current job.
• job.workflow_sha: the commit SHA of that workflow file.
• job.workflow_repository: the owner/repo where the workflow file lives.
• job.workflow_file_path: the file path relative to the repository root.

The key distinction: the existing github.workflow_ref and github.workflow_sha properties refer to the caller workflow. The new job.* equivalents refer to whichever workflow actually defines the job. For a non-reusable job, they match. For a reusable workflow, they point to the called workflow’s file. Note that these properties are not available on GitHub Enterprise Server.

Why it matters

Each of these changes addresses a common pain point in production CI/CD pipelines. Runner deprecations have historically caught teams off guard, forcing emergency upgrades. The new API makes it straightforward to build a monitoring script or dashboard that flags expiring runner versions before they become a problem.

The vulnerability-alerts permission closes a gap where teams either gave workflows too much access or had to use a personal access token with a custom scope just to read Dependabot alerts. Tighter permissions reduce your blast radius if a workflow is compromised.

The reusable workflow context properties matter most for teams who share workflows across many repositories or who enforce security policies based on workflow identity. Previously, a called workflow could not reliably tell GitHub which file it came from, which made audit trails and conditional logic harder to implement.

Our take

These are unglamorous but genuinely useful fixes. The runner deprecation API is the kind of thing that prevents a 2 a.m. incident when a CI runner silently stops working. The vulnerability-alerts permission is a small but correct step toward proper least-privilege setup in workflows, which many teams skip because it has been inconvenient until now.

The job context properties for reusable workflows are the most niche of the three, but if you maintain a shared workflow library across an organization, they solve a real identity problem. Teams building AI integration pipelines that rely on CI for model deployment or data processing will find precise workflow identity useful for audit and compliance checks. For general web development shops doing standard web development work, the deprecation API and token permission are the most immediately actionable changes here.

What to do about it

1. Query GET /actions/runners/deprecations/{version} for each runner version your organization uses and note the registration_deprecates_at and runtime_deprecates_at dates.
2. Add those dates to your team calendar or a monitoring alert so upgrades happen on your schedule, not GitHub’s.
3. Audit any workflow that reads Dependabot alerts and replace broad token scopes with permissions: vulnerability-alerts: read.
4. If you maintain reusable workflows, test the new job.workflow_ref and related properties to confirm identity-based conditional logic works as expected. Skip this step if you run GitHub Enterprise Server.

The deprecation API alone is worth adding to your runner maintenance routine this week.

Source: GitHub Changelog