GitHub Actions September 2026: Three Security Fixes Worth Applying Today

GitHub shipped three GitHub Actions changes on September 3 that close real security gaps — not marketing-grade “improvements,” but fixes to problems that have been quietly breaking CI pipelines and enabling over-permissioned tokens for years. None require a workflow rewrite. Apply all three before the end of the week.

Runner Deprecation API: Stop Discovering Deprecations by Accident

If your team runs self-hosted runners, you have probably discovered a deprecation the wrong way: a workflow fails, you dig into the logs, and you find out GitHub stopped supporting the runner version you are running. There has been no programmatic way to query deprecation timelines — just changelog archaeology and eventual surprises.

That changes with the new runner deprecation REST API. Call GET /actions/runners/deprecations/{version} at the repository, organization, or enterprise level and you get back exactly when support ends:

curl -H "Authorization: Bearer $GH_TOKEN"   https://api.github.com/repos/ORG/REPO/actions/runners/deprecations/2.329.0

The response includes three fields: runner_version, runtime_deprecates_at (when running jobs stops working), and registration_deprecates_at (when registering new runners stops working). The practical move: build a cron workflow that queries this endpoint for each version in your fleet and fires an alert 30 days before either date. You stop discovering deprecations by accident.

Node 20 was removed from GitHub-hosted runners on September 23 of this year. The minimum self-hosted runner version enforcement was paused in March after community backlash, then re-enforced. Teams have been reacting to these changes rather than planning for them. This API is the planning tool that was missing.

vulnerability-alerts Permission: Four Years to Close a GITHUB_TOKEN Gap

Reading Dependabot alerts inside a GitHub Actions workflow used to require a Personal Access Token or a GitHub App with security permissions. That is a lot of credential infrastructure for what should be a routine CI check. GitHub community Discussion #60612 tracked this gap since 2022. It is now closed.

Add vulnerability-alerts: read to your workflow’s permissions block and GITHUB_TOKEN can access the Dependabot alerts API natively:

permissions:
  vulnerability-alerts: read

jobs:
  audit-deps:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/github-script@v7
        with:
          script: |
            const alerts = await github.rest.dependabot.listAlertsForRepo({
              owner: context.repo.owner,
              repo: context.repo.repo,
              state: 'open',
              severity: 'critical'
            });
            if (alerts.data.length > 0) {
              core.setFailed(`${alerts.data.length} critical Dependabot alerts open`);
            }

You can now fail builds on critical open vulnerabilities, post Slack notifications when new alerts arrive, or auto-create issues for high-severity findings — all without storing a PAT. Least privilege is now the path of least resistance, not the hard way.

The March 2025 tj-actions supply chain attack (CVE-2025-30066) compromised 23,000+ repositories by stealing secrets from runner memory. Over-permissioned tokens were a contributing factor. Narrower, purpose-specific scopes reduce the blast radius when something goes wrong in CI.

Reusable Workflow Identity: The Fix for a Backwards Context Property

Reusable workflows have had an identity problem. The existing github.workflow_ref and github.workflow_sha properties point to the caller’s workflow — which is backwards if the reusable workflow needs to know about itself. Teams worked around this with the canonical/get-workflow-version-action, which is now deprecated because GitHub shipped the native fix.

Four new job.* context properties are available inside reusable workflows:

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

Two practical uses. First, a reusable workflow can check out its own code without hardcoding the repository path:

- uses: actions/checkout@v4
  with:
    repository: ${{ job.workflow_repository }}
    ref: ${{ job.workflow_sha }}

Second, and more important for security-conscious teams: log job.workflow_sha at the start of every reusable workflow run. GitHub’s SLSA tooling can consume this to build a cryptographic audit trail — the workflow attests its own identity rather than relying on caller-supplied data. This is the kind of feature that does not feel urgent until a supply-chain incident makes you wish you had it.

One caveat: these properties are not available on GitHub Enterprise Server.

Part of a Larger Security Roadmap

These three changes are real and worth applying, but they are incremental steps in a larger program. GitHub’s 2026 Actions security roadmap includes workflow dependency locking, a native Layer 7 egress firewall for hosted runners, and scoped secrets per job — all still in development. The September changes close specific gaps that had workarounds; the roadmap items will harden the platform at the structural level.

For now: add the runner deprecation cron, add vulnerability-alerts: read to your security audit workflows, and update any reusable workflows that relied on canonical/get-workflow-version-action. Three changes, a few hours of work, measurably better CI security posture. The full September changelog is worth bookmarking.