A GitLab runner registration token lets whoever holds it register a new runner against your project, group or instance. A runner is the machine that executes your pipeline jobs, so a rogue one can read the environment variables and files that those jobs can see, including deploy keys and cloud credentials. It can also receive jobs that were meant for your own runners. Reset the token first, then look for runners you do not recognize.
Check your GitHub account for leaked secrets — free
- Provider
- GitLab
- Severity
- Critical
- Impact
- Source code and build access
- Checked live by LeakWatch
- No
What a GitLab Runner Registration Token looks like
Runner registration tokens start with a fixed prefix that is specific to GitLab, followed by a block of letters, digits, dashes and underscores. Masked, the shape is:
GR1348941…XXXX GitLab runner registration token (masked)
The prefix GR1348941 is what makes a hit reliable. It is rarely found by accident in ordinary code, so a match almost always means a real token. Do not confuse this value with the other runner credentials GitLab issues. Runner authentication tokens start with glrt- and are used by newer runners to register. They are a separate credential, and if one of them leaked as well, handle it in the same way: revoke it on the runner itself.
How GitLab Runner Registration Tokens get leaked
- Runner setup scripts. A
gitlab-runner registercommand pasted into a shell script or a provisioning file, with the token typed inline. - Infrastructure code. Helm values, Kubernetes secrets or Terraform files that hold the token as plain text.
- Setup documentation. A README that shows a real token in an example command.
- Pipeline definitions. A
.gitlab-ci.ymlor an autoscaling configuration that prints or stores the token where anyone with repository access can read it. - Issue and chat threads. A pasted error message that includes the registration command.
What to do in the first hour
- Reset the registration token first. Open the CI/CD settings of the project or group that the token belongs to, expand the runners section, and choose the option to reset the registration token. Resetting replaces the old value, so it stops working for new registrations straight away.
- Check the runners that exist. Open the list of runners for the same project, group or instance and look for any you do not recognize. Note the name, the tags, the last contact and the host it reports. Remove runners you cannot account for.
- Look at recent jobs. Review the jobs that ran on the shared or project runners since the exposure. Look for jobs that ran on a runner you did not set up, unexpected network calls, and artifacts you did not expect.
- Rotate what the jobs could see. Any variable, deploy key, cloud credential or token that a job on a rogue runner could read should be treated as exposed. Rotate those first.
- Update your own runners. Runners that were registered with the old token keep working. Register them again with the new authentication workflow, or follow GitLab’s current documentation for runner tokens. Newer GitLab versions refuse the old registration path, so plan the migration rather than resetting in the dark.
- Remove the value from the code. Take it out of scripts, values files and pipeline definitions, and rewrite history if you want to. See I accidentally pushed an API key to GitHub.
- Check for other exposed secrets. Look at the same files for personal access tokens, deploy tokens and cloud keys. See GitLab personal access token for that case, and run a wider sweep with deep-scan your whole git history.
Not sure what else leaked? Run a free scan.
Revoke it at GitLab
Reset the token from the CI/CD settings of the project, group or instance that it was issued for. Each level has its own registration token, so resetting one does not reset the others. The reset is also available through the GitLab API, which is the easier route when runners are managed from infrastructure code. Once the reset is done, check that the old value is refused when you try to use it, and check the runner list for anything that registered in the meantime.
How LeakWatch detects it
The rule is called GitLab Runner Registration Token. It looks for the fixed prefix GR1348941, followed by exactly twenty letters, digits, dashes or underscores. The prefix is matched in lower case as well, so a pasted or lower-cased copy is still reported. The severity is critical. This type is not checked live: LeakWatch does not try to register a runner or call GitLab with the token it found, so a finding means the value has the right shape, not that it is still valid.
LeakWatch detects this format but does not check it live: it can tell you the key is exposed, not whether it still works. Assume it does until you have revoked it.
FAQ
If I reset the token, do my existing runners stop working?
No. Runners that already registered keep their own credentials and continue to pick up jobs. Only new registrations with the old token are refused.
Can a leaked token give someone access to my source code?
Not directly. The token registers runners, and a runner receives the jobs that GitLab sends it. The real risk is that a rogue runner can see what those jobs can see, so the code and variables are exposed indirectly.
Do I need to reset the instance token as well as the project token?
Only if the leaked value came from the instance or a group you do not know about. Check where the token was issued, and reset that level and any higher level that shares it.