# Prevent a shared GitLab runner from reusing another project’s private image without a registry check

> The if-not-present pull policy can cross an authorization boundary through the local image cache.

- Canonical URL: https://update.dsesecurity.com/updates/gitlab-shared-runner-private-image-pull-policy/
- Publisher: Detection Systems & Engineering (DSE Security)
- Author: DSE Security Editorial Team
- Published: 2026-10-15T13:33:43+00:00
- Modified: 2026-10-15T13:36:17+00:00
- Last reviewed by DSE: 2026-10-15
- Resource type: Guide
- DSE priority: Information
- Topics: Cybersecurity, IT
- Reading time: 2 minutes

## What you need to know

The if-not-present pull policy can cross an authorization boundary through the local image cache.

## Potentially affected

This concerns self-managed GitLab runners using the relevant container executors and pull policies. It is an image-access review, not a claim that one pull-policy setting provides complete job or host isolation.

## DSE recommendation

DSE recommends documenting which users and projects share each runner and who controls image selection.

## Article

The if-not-present pull policy can cross an authorization boundary through the local image cache.

## Source facts

GitLab’s runner security guide describes a private-image risk on shared runners. One user’s authorized job can pull an image into the runner’s local cache. A later user without registry access can request that image and receive the cached copy when the pull policy is if-not-present. GitLab recommends always for mixed-trust runners where users may request registry images, and reserves if-not-present for trusted dedicated use. The guide also distinguishes never for an administrator-controlled set of images already present on the runner.

Source: [GitLab — Runner security](https://docs.gitlab.com/runner/security/).

## Applicability

This concerns self-managed GitLab runners using the relevant container executors and pull policies. It is an image-access review, not a claim that one pull-policy setting provides complete job or host isolation.

## DSE recommendation

DSE recommends documenting which users and projects share each runner and who controls image selection. For mixed-trust use, require an appropriate registry authorization check instead of silently trusting a cached private image. For a deliberately fixed image set, review the administrator-maintained model separately. Inspect runner configuration, allowed policies, and job overrides together. Keep credential helpers and host-side registry configuration in the broader runner security review, and consider dedicated execution capacity for workloads with incompatible trust requirements.

## Verification

Using a disposable private image and two test identities, verify the chosen policy with a warm cache and with no cache. Confirm that an identity lacking registry permission cannot obtain the cached private image through the shared runner. Remove the test image and credentials afterward.

## Official reference

[GitLab — Runner security](https://docs.gitlab.com/runner/security/). Reviewed October 15, 2026.

## Primary reference

- Name: GitLab — Runner security
- Authority: docs.gitlab.com
- URL: https://docs.gitlab.com/runner/security/
- Source publication date: Not stated by the source

## Citation and use

Preferred citation: “Prevent a shared GitLab runner from reusing another project’s private image without a registry check,” DSE Security, https://update.dsesecurity.com/updates/gitlab-shared-runner-private-image-pull-policy/
Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/
Usage and citation policy: https://update.dsesecurity.com/usage/
Copyright © 2026 Detection Systems & Engineering. All rights reserved.