GitLab
GitLab Inc.CI/CD13 credentials1 default credential
Initial Root Password
gitlab / initial-root-password
Omnibus and Docker GitLab generate a random root password on first boot and write it to /etc/gitlab/initial_root_password. The file is auto-deleted 24 hours after install.
Looks like
pattern^Password:\s+\S+$Location
/etc/gitlab/initial_root_passwordcontainer / journald output on first boot in some deployments
Notes
Auto-deletion at 24 h is a mitigation, not a guarantee — it removes the file, not any access already captured, and not the account itself if never secured. The initial_root_password value can also be pre-set via gitlab_rails['initial_root_password'] in /etc/gitlab/gitlab.rb, which means the same value can leak from a plaintext gitlab.rb backup.
gitlab.rb Configuration Secrets
gitlab / gitlab-rb-secrets
The Omnibus main config file /etc/gitlab/gitlab.rb stores multiple secrets in plaintext: initial_root_password, database password (gitlab_rails['db_password']), initial_shared_runners_registration_token, Redis password, SMTP credentials, LDAP bind password, and more. The vendor explicitly documents that this file "should have file permissions 0600 because it contains plain-text passwords."
Looks like
patterngitlab_rails\['(db_password|initial_root_password|initial_shared_runners_registration_token)'\]\s*=\s*'[^']+'postgresql\['sql_user_password'\]\s*=\s*'[a-f0-9]{32}'Location
/etc/gitlab/gitlab.rbmain Omnibus configuration; 0600 by design, world-readable in backups
gitlab-ctl backup-etc archives, config-management output, snapshots
Notes
This is the single highest-value file on a GitLab host — one read hands you the DB password, the Rails-seeded root credential, and any pre-set runner registration tokens. Frequently exposed via misconfigured backups, config-management repos, and container images built with the file baked in.
Rails Encryption Secrets (gitlab-secrets.json)
gitlab / gitlab-secrets-json
/etc/gitlab/gitlab-secrets.json holds the Rails secret_key_base, db_key_base, and OTP/OpenID signing keys. These keys decrypt every encrypted value in the GitLab database — including stored CI/CD variables, integrations, and personal access tokens.
Looks like
pattern"(secret_key_base|db_key_base|otp_key_base)":\s*"[a-f0-9]{64,}"Location
/etc/gitlab/gitlab-secrets.jsongitlab-ctl backup-etc archives include this file
Notes
Losing this file is worse than losing an admin session — it lets an attacker decrypt every stored secret offline, including secrets belonging to users who never logged in through the attacker's access. Must be backed up separately from the DB backup, and consequently is often stored insecurely by operators who don't understand its role.
Bundled PostgreSQL User
gitlab / default-db-user
The Omnibus package's bundled PostgreSQL is created with the username 'gitlab' by default. Password is set via postgresql['sql_user_password'] (MD5-encoded) and consumed by gitlab_rails['db_password'] (plaintext).
Default credentials
gitlabLocation
/etc/gitlab/gitlab.rbpostgresql['sql_user_password'] and gitlab_rails['db_password']
bundled Postgres, TCP 5432 (localhost by default)
Notes
The bundled Postgres binds to localhost with peer/trust auth by default, so the username being "gitlab" isn't exploitable on its own — but the moment listen_address is changed for HA or external access, the known username plus a leaked gitlab.rb (see gitlab-rb-secrets) gives direct DB access. The DB holds every stored token in encrypted form; combined with gitlab-secrets.json it's a full offline compromise.
Personal / Project / Group Access Token
gitlab / personal-access-token
GitLab's family of user-scoped tokens all share the glpat- prefix: personal access tokens, impersonation tokens, project access tokens, and group access tokens.
Looks like
exampleglpat-XXXXXXXXXXXXXXXXXXXXLocation
git remote URLs, CI config, committed .env files
GITLAB_TOKEN, CI_JOB_TOKEN, PRIVATE_TOKENNotes
Scope depends on how the token was minted; api scope is effectively full account access. The glpat- prefix was introduced specifically to make these detectable by secret scanners. Users routinely paste these into git remote URLs (https://oauth2:glpat-...@gitlab.example.com/…), which Git then writes to .git/config in plaintext.
OAuth Application Secret
gitlab / oauth-application-secret
Client secret for an OAuth 2.0 application registered in GitLab, used when GitLab acts as an OAuth provider for other services.
Looks like
examplegloas-XXXXXXXXXXXXXXXXXXXXLocation
OAuth client configuration in downstream applications
application config files that integrate with GitLab SSO
Notes
A leaked OAuth application secret lets an attacker impersonate the downstream application to GitLab, potentially receiving user tokens via a spoofed authorization flow.
Deploy Token
gitlab / deploy-token
Project-scoped credential (username + token) for cloning, pushing, and pulling packages and container registry images. Not tied to a user account and cannot be used with the GitLab API.
Looks like
examplegldt-XXXXXXXXXXXXXXXXXXXXLocation
docker login / helm registry login flows in CI files, kustomize configs
Notes
Because deploy tokens have no user context, revocation and auditability are poor. A writable deploy token supports pushing malicious container images — a supply-chain concern for downstream consumers of the registry.
Deploy Key
gitlab / deploy-key
SSH key granting read-only or read-write access to a single repository, without a user account. The private key is what actually gets leaked.
Looks like
pattern-----BEGIN (OPENSSH|RSA|EC|DSA) PRIVATE KEY-----Location
~/.ssh/id_*, deploy.key in CI runner homedirs and Kubernetes SecretsNotes
Scope is exactly one repo - smaller blast radius than a PAT, but writable deploy keys still enable per-repo supply-chain tampering. No 2FA, no user context.
Runner Authentication Token
gitlab / runner-authentication-token
Long-lived token stored on each GitLab Runner in config.toml, used to authenticate to GitLab and pick up jobs. Replaces the legacy runner registration token as of GitLab 16.0.
Looks like
exampleglrt-XXXXXXXXXXXXXXXXXXXXglrtr-XXXXXXXXXXXXXXXXXXXXLocation
/etc/gitlab-runner/config.tomltoken = "glrt-..." in each [[runners]] block
often referenced by Kubernetes Secrets when using the Runner Helm chart / operator
Notes
GitLab's own docs: "Malicious access to a runner's file system might expose the config.toml file and the runner authentication token. The attacker could use the runner authentication token to clone the runner." A cloned runner picks up real jobs and sees their secrets as they run. Common exposure: config.toml baked into container images or checked into infrastructure repos.
Runner Registration Token (legacy)
gitlab / runner-registration-token
Legacy instance/group/project token used to register new runners. Deprecated in favor of runner authentication tokens (GitLab 16.0+) but still functional on many self-managed instances.
Looks like
pattern[A-Za-z0-9_\-]{20,}Location
/etc/gitlab/gitlab.rbgitlab_rails['initial_shared_runners_registration_token']
CI/CD onboarding scripts, Helm values files
Notes
A leaked registration token lets an attacker register their own runner to the instance/group/project, which then picks up real jobs and reads their CI variables. The initial_shared_runners_registration_token set in gitlab.rb is the highest-value variant — it's the instance-wide token, baked into a config file most operators forget grants runner registration to anyone who reads it.
CI/CD Job Token
gitlab / cicd-job-token
Short-lived token injected into every CI/CD job as CI_JOB_TOKEN. Valid only for the duration of the job; grants a limited set of API endpoints authenticated as the user who triggered the job.
Looks like
exampleglcbt-XXXXXXXXXXXXXXXXXXXXLocation
CI_JOB_TOKENecho'd into job logs by misconfigured pipelines; visible in artifacts
Notes
The token is short-lived but on shell/Docker Machine runners with MaxBuilds != 1 it can be captured by a subsequent job on the same host. Frequently accidentally echo'd in debug output despite GitLab's masking — masking is a display filter, not a control on what leaves the runner.
GitLab Agent for Kubernetes Token
gitlab / cluster-agent-token
Token that authenticates a GitLab Agent for Kubernetes back to the GitLab server. Grants the cluster agent the ability to receive configuration, run CI jobs on the cluster, and expose the cluster to GitLab-side features.
Looks like
exampleglagent-XXXXXXXXXXXXXXXXXXXXLocation
Kubernetes Secret used by the agent Helm chart (typically named gitlab-agent-token)
Notes
The token authenticates one side of a bidirectional control channel between GitLab and the cluster. A leaked agent token is essentially persistent cluster access from anyone who can reach the GitLab instance.
Feed Token
gitlab / feed-token
Long-lived user token embedded in RSS/calendar feed URLs. Does not expire. Grants read-only access to the user's activity feed — including confidential issues — as if they were the user.
Looks like
exampleglft-XXXXXXXXXXXXXXXXXXXXLocation
RSS/calendar URLs pasted into feed readers, wikis, bookmarks
shared feed URLs in browser history and proxy logs
Notes
Users routinely paste their feed URL (containing the token) into shared calendar tools, wikis, and cross-team Slack messages, treating it as "just a link." Anyone with the token sees every issue the user can see. Reset immediately if exposed.
Scope
Authorized use
LOLCreds helps map the credential surface of real products: known defaults, generated values, credential locations, and exposure patterns.