Image pull failure causes masked variable token leak in job log

Summary

When specifying an image in CI/CD YAML using a masked CI/CD variable containing a token, the token value is not consistently masked in the CI/CD job log.

If there are errors pulling the image, the error message contains the CI/CD variable token in plaintext.

This occurs for Docker and Kubernetes executor Runners.

Steps to reproduce

1. Create a project with a CI/CD variable called MY_TOKEN with the value this-is-a-sensitive-value-12345
2. Create a CI/CD pipeline with the following YAML, start a pipeline, and check the job log

build:
    image: service-user:$MY_TOKEN@$CI_SERVER_HOST/path/to/container/image:96d47f48
    script:
        - echo "this job should fail and reveal a masked variable in the job log"

Example Project

What is the current bug behavior?

The CI/CD variable is masked earlier in the job log, but the later error contains the masked variable value in plaintext

What is the expected correct behavior?

CI/CD variable should be masked consistently

Relevant logs and/or screenshots

Running with gitlab-runner 18.3.0 (9ba718cd)
  on dfa3f92cc8c9 OLJ5GQn3x, system ID: r_Ys99YA7fc2RX
Resolving secrets
Preparing the "docker" executor
00:00
Using Docker executor with image service-user:[MASKED]@my-server/path/to/container/image:96d47f48 ...
Using effective pull policy of [always] for container service-user:[MASKED]@my-server/path/to/container/image:96d47f48
Pulling docker image service-user:[MASKED]@my-server/path/to/container/image:96d47f48 ...
WARNING: Failed to pull image with policy "always": invalid reference format (manager.go:238:0s)
ERROR: Job failed: failed to pull image "service-user:this-is-a-sensitive-value-12345@my-server/path/to/container/image:96d47f48" with specified policies [always]: invalid reference format (manager.go:238:0s)

Output of checks

Results of GitLab environment info

Expand for output related to GitLab environment info

   (For installations with omnibus-gitlab package run and paste the output of: \\\\\\\`sudo gitlab-rake gitlab:env:info\\\\\\\`)  (For installations from source run and paste the output of: \\\\\\\`sudo -u git -H bundle exec rake gitlab:env:info RAILS_ENV=production\\\\\\\`)    

Results of GitLab application Check

Expand for output related to the GitLab application check

  (For installations with omnibus-gitlab package run and paste the output of: \\\`sudo gitlab-rake gitlab:check SANITIZE=true\\\`)  (For installations from source run and paste the output of: \\\`sudo -u git -H bundle exec rake gitlab:check RAILS_ENV=production SANITIZE=true\\\`)  (we will only investigate if the tests are passing)   

Possible fixes

Patch release information for backports

If the bug fix needs to be backported in a patch release to a version under the maintenance policy, please follow the steps on the patch release runbook for GitLab engineers.

Refer to the internal "Release Information" dashboard for information about the next patch release, including the targeted versions, expected release date, and current status.

High-severity bug remediation

To remediate high-severity issues requiring an internal release for single-tenant SaaS instances, refer to the internal release process for engineers.