Spoofable Actor Condition

Spoofable Actor Condition

Description

Workflows sometimes gate privileged behaviour on the actor context — for example if: github.actor == 'dependabot[bot]' — to “only run for a trusted user or bot.” The github.actor and github.triggering_actor contexts are not a reliable trust boundary: across chained events (workflow_run), re-runs, and certain automation flows the effective actor can be influenced, so a check based on it can be bypassed to run the protected path. 1 Actor gates are also a common way people think they have restricted a dangerous trigger when they have not.

Vulnerable Instance

  • A job- or step-level if: condition compares github.actor / github.triggering_actor to a specific user or bot to gate sensitive behaviour.
on:
  workflow_run:
    workflows: [build]
jobs:
  deploy:
    if: github.actor == 'dependabot[bot]'   # spoofable trust gate
    runs-on: ubuntu-latest
    steps:
      - run: ./deploy.sh

Mitigation Strategies

  1. Do not use the actor as a security control. Treat github.actor as informational only.
  2. Verify the event payload. For Dependabot, check github.event.pull_request.user.login and the event source rather than the actor string.
  3. Use real controls. Enforce trust with least-privilege permissions, environment protection rules with required reviewers, or a GitHub App identity — not a string comparison.
  4. Avoid privileged triggers where an actor check is your only guard (see Dangerous Event).

Secure Version

 jobs:
   deploy:
-    if: github.actor == 'dependabot[bot]'
     runs-on: ubuntu-latest
+    environment: production   # required reviewers enforce the real gate
     steps:
       - run: ./deploy.sh

Impact

DimensionSeverityNotes
LikelihoodMediumActor-based gates are a common misconception.
RiskMediumA bypassable gate can expose the protected path to unauthorized triggers.
Blast radiusModerateDepends on what the gated job does — often deploys or privileged automation.

References


Last updated on