GitHub Actions Adds a vulnerability-alerts Permission — Stop Over-Scoping Tokens Just to Read Dependabot

GitHub’s 2026-09-03 changelog bundled three GitHub Actions updates. Two of them got very little attention and matter more than they look — starting with the new vulnerability-alerts permission. Verified 2026-09-07.

1. A read-only permission for Dependabot alerts

Per the announcement, you can now grant workflows read-only access to Dependabot alerts with the new vulnerability-alerts permission for GITHUB_TOKEN. It supports read and none.

The stated reason is the interesting part: it lets you follow least-privilege practices instead of relying on broader scopes.

Why that matters in practice

A common setup: a scheduled workflow collects Dependabot findings and posts a digest to Slack or opens an issue.

To read those alerts before this change, the token had to carry a wider scope — so a workflow that only wanted to read was handed capabilities far beyond its job. If that workflow were ever tampered with (an unpinned third-party action, say), the attacker inherits the oversized scope.

Now you can state exactly what it needs:

permissions:
  vulnerability-alerts: read

And nothing else. The capability is unchanged; the blast radius when something goes wrong is much smaller.

2. Reusable workflows can now identify themselves

The second update adds four job context properties:

The announcement spells out the distinction: these reflect the workflow that defines the current job, whereas the existing github.workflow_ref and github.workflow_sha describe the outer caller. For a job defined directly in a workflow they match; they diverge only for reusable workflows.

Plainly: if you maintain a central workflow consumed by a dozen repositories, it previously had no clean way to know at runtime which repository and commit its own definition came from. Now it does — useful for auditing, signature verification, and confirming callers are on an approved version.

Caveat, stated by GitHub: these properties are not available on GitHub Enterprise Server.

3. The third item is the runner deprecation API

The same post announced a REST API returning when registration and runtime support end for a runner version: GET /actions/runners/deprecations/{version}, returning runner_version, runtime_deprecates_at and registration_deprecates_at, callable at repository, organization or enterprise level.

We covered that one separately in how to use the GitHub Actions runner deprecation API.

4. The one thing to do this week

If any workflow you own touches Dependabot data, open its permissions: block and read it. Most were configured years ago and never revisited, and most are broader than the job requires.

This change makes narrowing them a one-line edit. Cheap security consolidation beats the kind that needs a refactor.

The same week also tightened CodeQL’s Actions checks, which may add alerts to your repository — see CodeQL 2.26.4 surfaces more Actions issues.

Source: GitHub’s changelog entry, GitHub Actions: Early September 2026 updates (2026-09-03), read directly. Verified 2026-09-07. Consult GitHub’s workflow syntax documentation for the full permissions key reference. Plan pricing is summarised on our GitHub Copilot tool page.