I can't believe the default is to persist credentials and expose them to other jobs :( this is a major security issue.

Just as a heads up for anyone stumbling upon this issue:

1. persist-credentials: false is only relevant when you use ssh authentication, because
2. GITHUB_TOKEN is always exposed to all jobs, and by default has write access to your repo.

So if you want to harden security, apart from setting persist-credentials: false for ssh auth, make sure that GITHUB_TOKEN auth has no write permission to your repo.

See https://github.blog/changelog/2021-04-20-github-actions-control-permissions-for-github_token/ for reference.

+1

Agreed this seems a severe security issue, because it means any workflow using actions/checkout basically leaks the token to any process/action in that workflow which can just read it from .git/config.

@haampie IIUC it is a problem also with no ssh authentication (the default). The GitHub token is given only to this action and maybe a few other actions/* actions (default: ${{ github.token }} only work for those AFAIK), but is otherwise given to no other action unless done explicitly (like with: token: ${{ github.token }}/${{ secrets.GITHUB_TOKEN }}).
The token is not in the environment.

In other words, actions/checkout leaks the token to .git/config, making it very easy to read for anything running inside the workflow.
If the token was not written to .git/config, then I think stealing the GitHub token would require (one of):

• passing the token explicitly to some action in the workflow and that action gets compromised
• actions/checkout gets compromised
• compromise the workflow definition to e.g. print the token

So, depending on whether the token is explicitly passed to some action:

• If yes, then it seems the only safety net is to set token permissions
• If no, it would be safe by default with this change or with persist-credentials: false, regardless of the token permissions. A workaround is to set token permissions

I guess GitHub sees setting token permissions as the more general solution.
If so, fine, but then the default should be secure and so the default workflow permissions should be just contents: read.

https://securitylab.github.com/research/github-actions-preventing-pwn-requests/ also has a mention related to this, search for persist-credentials:

If the workflow uses actions/checkout and does not pass the optional parameter persist-credentials as false, it makes it even worse. The default for the parameter is true. It means that in any subsequent steps any running code can simply read the stored repository token from the disk.

+1

I updated the issue title since v3 and v4 have already shipped, so asking for a new v3 doesn't make sense.

Fast forward to 2024, and we have https://johnstawinski.com/2024/01/11/playing-with-fire-how-we-executed-a-critical-supply-chain-attack-on-pytorch/

PyTorch had several workflows that used the actions/checkout step with a GITHUB_TOKEN that had write permissions. For example, by searching through workflow logs, we can see the periodic.yml workflow also ran on the jenkins-worker-rocm-amd-34 self-hosted runner. The logs confirmed that this workflow used a GITHUB_TOKEN with extensive write permissions.

@ericsciple could you please take this issue seriously and disable persisting credentials to disk?

Not sure this is actually necessary. There seems to be a mismatch between the documentated default and the code

As I read the code, the 'persist-credentials' value will be false if the input does not contain a 'persist-credentials' entry.

The issue should be changed to a 'fix the documentation' if my understanding is correct.

Still no update on this?

GitHub chose a different path:

1. new users get accounts configured with contents: read by default.
2. new orgs are created with contents: read by default.
3. existing users/orgs can opt into contents: read

For more information, see:

• https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository#configuring-the-default-github_token-permissions
• https://docs.github.com/en/organizations/managing-organization-settings/disabling-or-limiting-github-actions-for-your-organization#setting-the-permissions-of-the-github_token-for-your-organization
  (There's a similar setting for user accounts, but I can't find the docs for it right now)

As it stands today, if someone were to change the default for persist-credentials to false it would break checking out repositories that have submodules in public repositories, as shown in https://github.com/check-spelling-sandbox/editorconfig-gedit/actions/runs/14555001851/job/40830764625). I'm in the process of hunting down that bug and hopefully finding someone who will either fix it or let me fix it...

GitHub chose a different path:

Token permissions help mitigate this problem, but they do not solve it.

I can't commit to any timelines, but this is something we want to fix - whether that's changing the default persist-credentials setting, storing the token in a safer way to limit how steps can access it, or some combination of the two.

GitHub chose a different path:

Token permissions help mitigate this problem, but they do not solve it.

I can't commit to any timelines, but this is something we want to fix - whether that's changing the default persist-credentials setting, storing the token in a safer way to limit how steps can access it, or some combination of the two.

IMHO this should be on a higher priority than it currently is. There are known security issues with current settings at least since 2021 and nobody seems to be working on this. This is not on par with Microsoft's own Secure Future Initiative.