Description

The GET /api/v1/user/actions/runners/registration-token endpoint (and its owner- and repository-level equivalents) creates a new runner registration token if none exists, yet the API scope middleware classifies it as read-only because it is a GET request. A holder of a leaked read:user-scoped token can therefore mint a registration token and register a malicious Actions runner that executes workflow jobs with access to repository secrets and source code.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.5",
  "pubDate": "2026-08-13T17:17:21.887Z",
  "pubdate": "2026-08-13T17:17:21.887Z",
  "executiveSummary": "An authorization bypass vulnerability exists within the API scope enforcement mechanism governing runner registration token generation endpoints, specifically affecting GET /api/v1/user/actions/runners/registration-token and its owner- and repository-level equivalents.\nThe root cause stems from the API scope middleware incorrectly classifying the endpoint as read-only strictly because it relies on the HTTP GET method, failing to account for the state-changing side effect of creating a new runner registration token if one does not already exist.\nThe business impact is severe, as a malicious actor possessing a leaked read:user-scoped token can successfully interact with this endpoint to mint valid runner registration tokens.\nWith a minted registration token, the attacker can register a malicious Actions runner to the target environment.\nThis unauthorized runner subsequently executes workflow jobs, granting the attacker access to sensitive repository secrets and private source code.\nExploitation requires network exposure of the API endpoints and possession of a compromised read-scoped token, bypassing the intended write-level privilege separation for administrative runner provisioning actions.",
  "technicalDetails": "The vulnerability resides in the API scope middleware logic responsible for enforcing permission boundaries based on HTTP verbs rather than actual state semantics. The affected components include the GET /api/v1/user/actions/runners/registration-token endpoint along with its corresponding owner- and repository-level routing equivalents.\nThe root cause is a semantic mismatch between the HTTP method design and the internal application logic. While RESTful conventions conventionally restrict GET requests to safe, idempotent, and read-only operations, the underlying handler for this endpoint performs an implicit write or state mutation: it checks for the existence of an active runner registration token and automatically generates and persists a new one if none is found.\nThe API scope middleware evaluates incoming requests against required permission scopes by inspecting the HTTP method. Because the request utilizes the GET method, the middleware improperly classifies the operation as falling under a read-only scope, such as read:user, rather than enforcing the required write-level or administrative scopes necessary for credential and token generation.\nThe attack flow proceeds as follows: 1) An attacker obtains a leaked or compromised read:user-scoped API token through external exposure or previous compromise. 2) The attacker issues an HTTP GET request to the vulnerable endpoint GET /api/v1/user/actions/runners/registration-token. 3) The API scope middleware intercepts the request, verifies the read:user scope against the GET method, and permits the execution to pass through. 4) The application logic executes the token generation routine, minting a valid runner registration token despite the caller lacking elevated administrative privileges. 5) The attacker captures the generated registration token in the HTTP response. 6) Using the minted token, the attacker registers an external, attacker-controlled runner instance to the user, owner, or repository context. 7) When subsequent GitHub Actions or CI/CD workflow jobs are triggered, the malicious runner picks up execution tasks, enabling the payload behavior of intercepting repository secrets, environment variables, and source code."
}