GitHub Action workflow is executed for a PR from a forked repo if the PR changes the workflow file

According to this thread, actions of a PR from a fork repo will be executed against the fork, and only if the fork is in the beta program.

I tested this by creating a test account (@huynguyendev) that is not in the beta. I then opened up a pull request to TextureGroup/Texture (which is in the beta) from my forked repo. The commit changes Texture’s worflow file to add pull_request event and voila, the workflow is now executed on my PR.

This has the potential of allowing bad actors to run their own scripts by simply opening up PRs on open source projects. Can someone verify if this is in fact intended behavior?


It allows bad actors to run their own scripts, but only in the context of their own repository. Basically, it works like this:

  1. A repo named foo/bar exists
  2. I fork the repository foo/bar to lee-dohm/bar
  3. I make a change to a workflow on a branch in lee-dohm/bar and open a pull request to foo/bar

Leaving aside the “which repo is in the Actions beta” part, the workflow executes in lee-dohm/bar even though the result is visible in foo/bar. This means that I can’t create a workflow that emails the secrets of foo/bar to me by creating a PR because it would email me the secrets of lee-dohm/bar.

I hope that helps to clarify things.


Is this still the case?

1 Like

This is still the case.  Forked repositories only have a read-only version of the repository token so that they can do a clone, and do not get a copy of workflow secrets.

1 Like

Builds should still be triggered even in forks, right? Somehow I don’t see any builds for a fork in this PR Is there a setting to enable builds on forks? 


Hi @lee-dohm  and @ethomson 

This limited support for forks is a big adoption problem, I hope you see it.

I wrote a blog post about it where I not only complain but also suggest a very handy possible solution that you could copy from other tools - I hope this helps, somehow.

1 Like

As we mentioned in other threads that you’re in - this is something that we’re investigating and working on.

In the meantime, you’re welcome to implement exactly the proposal that you describe in your blog post.  You can trigger a workflow on an issue comment, examine that issue comment for ok-to-test, then do whatever is necessary with secrets.  They’ll be available to that workflow since it’s not running on a pull request event from a fork.

Interesting. But how would I integrate it with pull requests?

For example. I need to enable static code analysis with eslint, and want it on PR of course.

So I would have eslint as part of the workflow that is triggering on issue comment? and I would somehow reference the PR number in the issue comment, so the workflow knows what repo and branch to checkout?

@ethomson, We are also facing the adoption problems for quite some time (nearly 5 months). Our GitHub Action progress is in a standstill due to this limitation.  

Can you give us an ETA ? So that I can pass it on to my colleagues.