The secrets of repositories using github actions can be modified by a collaborator using the REST API

[jorgedomingomasmovil]

Select Topic Area

Question

Body

Hello,

The secrets of repositories using github actions can be modified by a collaborator using the REST API. I'm not sure if this is a bug or an expected behavior

Is there a way to limit this behavior with github permissions, so that collaborators cannot modify the values of secrets using the REST API.

To recreate it you can have two users and add one as a contributor to a private repository. Create with the owner of the repository the secret in Settings > Secrets and Variables > Actions > New repository secret
With the user with the role of collaborator the repository is cloned and using ghcli you can change the value of the created secret. The command is:
gh secret set <secret_name> -b "secret_value_changed_by_collaborator"

thanks in advance for the help

[Hanashiko]

Hi there,

Thanks for bringing this up — it’s a very important topic, especially for teams that rely heavily on GitHub Actions and proper permission management.

What you’ve described appears to align with the current behavior of GitHub’s permissions model, where users with the "Write" role (which includes collaborators) have the ability to create, update, and delete repository-level secrets via both the UI and the CLI/REST API. This is considered expected behavior and is documented in GitHub’s permission documentation.

Unfortunately, at this time, there is no granular permission setting at the repository level that would allow you to prevent collaborators with write access from modifying secrets while still retaining their ability to contribute to the repository in other ways (e.g., pushing code, creating PRs).

Options You Can Consider:

1. Switch to organization-level secrets: If you're working in an organization, you might consider using organization or environment secrets, where you can limit access based on more fine-grained controls like repository selection or required approvals for workflows.
2. Use environments with required reviewers: For sensitive operations, configuring environments with required reviewers can help ensure that workflows using sensitive secrets cannot run without manual approval, even if a collaborator updates the secrets.
3. Submit a feature request: If finer-grained secret management is important for your use case, I’d encourage submitting feedback via GitHub's official feedback form. It’s a common request for larger teams and enterprises who want to limit secret access without downgrading developer permissions.