Leaked GitLab Personal Access Token? Revoke It Now

A GitLab personal access token acts as you. It replaces your password for the GitLab API and for Git over HTTPS, with the same permissions you have on every project, group and package registry, limited only by the scopes chosen when the token was created. With a broad scope such as api, a leaked token can read private source code, push commits, change CI/CD variables and read the secrets stored there. Revoke it first, then check what it touched.

Check your GitHub account for leaked secrets — free

Provider: GitLab
Severity: Critical
Impact: Source code and build access
Checked live by LeakWatch: Yes
Revoke at: GitLab

What a GitLab personal access token looks like

Personal access tokens begin with the glpat- prefix. Older tokens are a short run of letters, digits, dashes and underscores after the prefix. Newer routable tokens are longer and carry two dot-separated suffixes after the main body:

glpat-…XXXX                  personal access token (masked)
glpat-…XXXX.<xx>.<checksum>  routable form (masked)

LeakWatch handles both forms, and the dots in the longer form matter: a token cut off before them is a fragment, not the full credential.

GitLab has other token types that look similar but are revoked elsewhere. Project access tokens and group access tokens belong to a project or group rather than to a person, and are managed in that project’s or group’s Settings → Access tokens. Deploy tokens, runner tokens and CI job tokens are separate again. If your token came from a self-managed GitLab, the format is the same, but the token only works against your own instance’s host, and you revoke it there, not on gitlab.com.

How GitLab personal access tokens get leaked

Remote URLs with a token inside. A git clone https://oauth2:<token>@gitlab.com/... command gets stored in .git/config, shell history, scripts and CI logs.
CI/CD configuration. A token written into .gitlab-ci.yml or a pipeline script instead of a masked CI/CD variable.
Package registry settings. .npmrc, .pypirc, Maven settings.xml and Docker config files that authenticate to GitLab’s registries with a token.
Automation scripts. Release scripts, mirror jobs and backup tools that call the API, committed with the token as a default value.
Issues and merge requests. A token pasted into a comment or a bug report along with a log or curl command.

What to do in the first hour

Revoke the token. In GitLab open your avatar → Edit profile → Access tokens and revoke the exposed token. A revoked token stops working immediately.
Note its scopes and expiry first. The token list shows the scopes and the expiry date. api or write_repository means the token could change code; read_api or read_repository means mostly reading. This tells you how deep to look.
Create a narrower replacement if you need one. Pick the fewest scopes, a short expiry, and where you can, use a project or group access token with a limited role rather than a token tied to your whole account.
Audit recent activity. Under your profile open Activity, and in each important project check Code → Commits and branches for pushes you did not make. Group owners can read Audit events under Secure. Look for new tokens, new deploy keys, new SSH keys and changed project members.
Check what a token with api scope could have read. Look at Settings → CI/CD → Variables in your projects. If any contain credentials, treat them as exposed and rotate them at their own providers.

Not sure what else leaked? Run a free scan. 6. Review account security. Open Preferences and Account to check for unfamiliar SSH keys, other personal access tokens and connected applications. Enable two-factor authentication if it is not already on. 7. Then clean the repository: remove the value and rewrite history if you want to. See I accidentally pushed an API key to GitHub.

Not sure what else leaked? Run a free scan.

Revoke it at GitLab

Open gitlab.com/-/user_settings/personal_access_tokens, find the leaked token in the active tokens list and use Revoke. That page is on gitlab.com. If the token belongs to a self-managed instance, open the same Access tokens page on your own GitLab host instead. Project and group access tokens do not appear here: revoke those in the Settings → Access tokens page of the project or group that owns them.

How LeakWatch detects it

LeakWatch has two rules for this type, both called GitLab PAT in the findings: one for the short format and one for the routable format, both starting with glpat-. This type is checked live: LeakWatch can check whether a detected token is still active with a read-only request to the GitLab API that returns information about the token itself. It never reads your projects or code and changes nothing in your account. A token for a self-managed instance cannot be confirmed this way, so “not confirmed” does not mean safe.

LeakWatch can check whether a detected key is still active with a read-only request to GitLab. It never reads your data or spends your credits.

FAQ

Is a leaked project access token the same problem?

Similar, but narrower. A project access token only reaches its own project and has a role instead of your account’s permissions. Revoke it in that project’s Access tokens settings, and check that project’s activity.

Does the token still work if I change my password?

Yes. Personal access tokens are independent of your password, so changing it does not revoke them. You must revoke the token itself.

My token had an expiry date. Do I still need to act?

Yes. An expiry limits how long it works, but until that date the token is fully valid. Revoke it now and set a short expiry on the new one.