GCP - Artifact Registry Persistence
Artifact Registry
For more information about Artifact Registry check:
Dependency Confusion
Artifact Registry virtual repositories expose one endpoint for downloading, installing, or deploying artifacts from one or more upstream standard or remote repositories. Each upstream has an integer priority: a higher value takes precedence when a requested artifact exists in multiple upstreams. If upstreams have the same priority, Artifact Registry may serve the artifact from any of them; it does not document an alphabetical policy-name or highest-version tie-breaker.[1][2]
Google Cloud describes dependency confusion as a mixed private/public repository configuration in which an attacker uploads a new package version with bad code to a public repository and a client selects that version. The recommended design is a remote repository that proxies the public registry, a standard repository for private packages, and a virtual repository that prioritizes the standard repository. Configure package managers and other clients to use only the virtual repository; if a client also searches a public index, its own selection logic can still choose the latest version regardless of the source repository.[1][4]
[!CAUTION] A vulnerable setup can let a public remote upstream win package selection when it has a higher priority than the private upstream, or when a client searches multiple indexes. An attacker needs to publish a package under the internal package's name in the relevant public registry, but this is a package supply-chain attack against authorized consumersโnot an unauthenticated Artifact Registry access bypass. Equal upstream priorities do not guarantee that the remote repository is selected, and a remote repository can serve a cached copy after its first request, so both tie behavior and cache state matter.[1][4]
For an authorized assessment, the persistence path is:
-
Requirements: A virtual repository must be in use by the consumers, and the target package name must be an internal name that is not claimed in the public registry used by the remote upstream (or otherwise be publishable by the assessor). If the remote upstream is already configured with an unsafe priority, the package-publication step is the relevant dependency-confusion path; changing the virtual repository policy requires permission to update the repository.[1][3]
-
Create a remote repository that proxies the relevant public registry if one does not already exist, then add it as an upstream of the virtual repository.[1][2]
-
Edit the virtual repository's upstream policy so that the public remote has a higher priority than the private standard repository for a controlled test. Do not rely on equal priorities for a deterministic result.[1][2]
-
Apply the complete upstream policy file to the virtual repository:
gcloud artifacts repositories update <VIRTUAL-REPOSITORY> \ --location=<LOCATION> \ --upstream-policy-file=<UPSTREAM_POLICY_FILE>The
--upstream-policy-fileflag updates upstreams for virtual repositories; ensure the file contains the intended standard and remote entries with their priorities.[2][3] -
In a dedicated test registry, create a package under the same name with a version higher than the internal package, preserve the expected interface, and use a benign marker to demonstrate impact before publishing it to the public upstream. A real attack would replace that marker with malicious installation or runtime behavior. A remote repository fetches and caches a package version on its first request, then serves the cached copy on later requests, so test with a version that is not already cached.[1][4]
For more information about dependency confusion check:
https://book.hacktricks.wiki/en/pentesting-web/dependency-confusion.html
References
- [1] Virtual repositories overview | Artifact Registry
- [2] Create virtual repositories | Artifact Registry
- [3] gcloud artifacts repositories update
- [4] Remote repositories overview | Artifact Registry
[!TIP] Learn & practice AWS Hacking:
HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking:HackTricks Training GCP Red Team Expert (GRTE)
Learn & practice Az Hacking:HackTricks Training Azure Red Team Expert (AzRTE)
Browse the full HackTricks Training catalog.Support HackTricks
- Check the subscription plans!
- Join the ๐ฌ Discord group or the telegram group or follow us on Twitter ๐ฆ @hacktricks_live.
- Share hacking tricks by submitting PRs to the HackTricks and HackTricks Cloud github repos.


