# Leaked GitLab Runner Token? Reset It Now > GitLab runner registration token exposed on GitHub? Reset it in CI/CD settings, check for unknown runners and review jobs. Step-by-step guide. Source: https://leakwatch.net/secrets/gitlab-runner-registration-token --- [LeakWatch](/) [Product](/product)[Live feed](/leaks)[Guides](/secrets)[Blog](/blog)[Free scan](/) 1. [Home](/) 2. [Secrets](/secrets) 3. GitLab Runner Registration Token Code & CI · Secret guide # Leaked GitLab Runner Registration Token: what to do in the first hour Critical severityDetected onlyLast verified October 23, 2026 · 5 min read 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: ```text 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 register` command 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.yml` or 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 1. **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. 2. **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. 3. **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. 4. **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. 5. **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. 6. **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](/blog/i-accidentally-pushed-an-api-key-to-github). 7. **Check for other exposed secrets.** Look at the same files for personal access tokens, deploy tokens and cloud keys. See [GitLab personal access token](/secrets/gitlab-personal-access-token) for that case, and run a wider sweep with [deep-scan your whole git history](/blog/deep-scan-your-whole-git-history). Not sure what else leaked? [Run a free scan](/). [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. ## Related - [GitLab Personal Access Token](/secrets/gitlab-personal-access-token) - [GitHub Personal Access Token](/secrets/github-personal-access-token) - [Vault Service Token](/secrets/vault-service-token) - [I accidentally pushed an API key to GitHub](/blog/i-accidentally-pushed-an-api-key-to-github) - [Which vendors leak most this week](/leaks/trends) - [All secret guides](/secrets) [Get alerted next time a secret leaks — create a free account](/) LeakWatch is not affiliated with GitLab. ![Gabriel Diyan, founder of LeakWatch](/brand/Photo-Gabriel-Diyan.webp) Gabriel Diyan (0xCr0c0) Cybersecurity student, founder of LeakWatch. I built and run the scanner described here — the detection patterns, the false-positive classifier and the provider validators are mine. [More about who I am](/about). [GitHub](https://github.com/Leakwatch-Scan) · [X](https://x.com/LeakwatchScan) · [LinkedIn](https://www.linkedin.com/in/gabriel-diyan-80a378375) · [GitHub (personal)](https://github.com/crocogab) LeakWatch Secrets leak into public commits every minute. This watches the forges for yours. Built and run by [Gabriel Diyan](/about), a cybersecurity student — [why LeakWatch exists](/about). Scan - [Product](/product) - [Live feed](/leaks) - [Trends](/leaks/trends) - [API docs](/docs) - [CI/CD](/docs?tab=ci) Read - [Blog](/blog) - [Secret guides](/secrets) - [Changelog](/changelog) - [About](/about) Verify - [Security](/security) - [Privacy](/privacy) - [Terms](/terms) - [Legal](/legal) - [Contact](/contact) - [Status](https://status.leakwatch.net) © 2026 LeakWatch [GitHub](https://github.com/Leakwatch-Scan)[X](https://x.com/LeakwatchScan)