Vulnerabilities, Secrets and Misconfiguration in the Highest-Exposure Docker Hub Images

Vulnerabilities, Secrets and Misconfiguration in the Highest-Exposure Docker Hub Images Cristhian Kapelinski ∗ , Beatriz Machado ∗ , Diego Kreutz ∗ ∗ AI Horizon Labs, Federal University of Pampa (UNIPAMPA), Alegrete, Brazil

{cristhianavila, beatrizmachado}.aluno@unipampa.edu.br, diegokreutz@unipampa.edu.br Abstract Docker Hub underpins containerized software, yet large-scale security measurements of its images are infrequent and rely on a single scanner. We present ChimangoScan, a pipeline that crawls Docker Hub and ranks images by a layer-graph exposure score: its pull count plus those of every image inheriting its layers. From a 12.7 million-repository crawl we scanned the 52,895 highest-exposure images, covering 84.7% of all 663.8 billion recorded pulls, with six open-source scanners (170.4 million findings). Known vulnerabilities are near-universal. 96.3% of images carry one, 93.4% carry a critical one, and 98.0% carry a misconfiguration. Yet the reported posture depends heavily on the scanner. Of the distinct vulnerabilities the three vulnerability scanners find, only 2.7% are reported by all three and 66.8% by one. Secrets show the opposite pattern. TruffleHog flags 76.9% of images, yet 99.7% of its hits are non-credentials by hand-labeling. A lone scanner’s count is thus largely an artifact of that scanner.

arXiv:2608.02669v1 [cs.CR] 2 Aug 2026

Index Terms Docker Hub, Container Security, Software Supply Chain, Vulnerability Scanners, Empirical Measurement.

I. I NTRODUCTION Software supply chain attacks are projected to cost USD 60 billion in 2025, up from USD 46 billion in 2023; Gartner estimated 45% of organizations would face one by 2025, and over 700,000 malicious open-source packages have now been cataloged.1 Containers sit on that supply chain, and Docker Hub is the registry underneath: 92% of IT professionals report using containers, and over half of organizations run most or all of their applications in containers.2 Docker Hub hosts over 14 million images and advertises “11B+ monthly image downloads”;3 cumulatively, our crawl sums 663,779,362,551 historical pulls (about 663.8 billion) across 12,716,568 public repositories (Section III-A). When a developer writes FROM python:3.12, what runs in production is pulled unmodified from an image someone else published, and a flaw in that base is inherited by every image built on it. The reach can be enormous; alpine draws 11.8 billion pulls of its own, but images built on its layers add roughly 71 billion more, so one critical vulnerability in alpine reaches about 83 billion inherited pulls. This parent-to-child propagation, first documented by Shu et al. [17], makes the registry a software-supply-chain attack surface [9] whose reach varies widely. A critical flaw in alpine:latest reaches the whole ecosystem, while the same flaw in an unused leaf image reaches almost nothing. ChimangoScan captures this with an exposure score (Section III-C). Since images also leak credentials and ship insecure defaults, a faithful measurement must look beyond CVE (Common Vulnerabilities and Exposures) counts. Yet prior ecosystem-scale measurements each rely on a single detector: Shu on Clair [17], Liu on one bespoke tool [10], Dahlmanns on one secret-detection pipeline [5], and Dr. Docker on one SCA (Software Composition Analysis) engine over 3,000 of its 33,952 images [16]. Each count thus carries unquantified tool-dependence. The studies that do compare scanners use small samples (Kaur et al., a pairwise Jaccard overlap of 0.59 to 0.80, on a 0-to-1 scale where 1 is identical, over 44 images [8]; Churakova et al., best pair 0.69 over 48 images [3]; Javed and Toor, 59 images [7]; Mills et al., 380 images [12]). No prior work crosses the two axes at ecosystem scale. This paper addresses that gap with ChimangoScan, a pipeline that crawls the Docker Hub namespace, reconstructs the image layer graph, ranks images by downstream exposure, and scans the highest-exposure ones with six independent scanners. Its contributions are (i) the exposure score E(I) (Section III-C), the first to fold an image’s own pull count and those of its entire downstream subtree into one scalar; (ii) a six-scanner measurement of all 52,895 top-ranked repositories (170.4 M findings), two orders of magnitude more images than prior multi-scanner studies (Section IV-A); (iii) an ecosystem-scale measurement of inter-scanner disagreement (Section IV-C), showing that the posture a single tool reports is substantially an artifact of that tool (only 2.7% of distinct vulnerabilities are flagged by all three vulnerability scanners, and 99.7% of TruffleHog’s hits, found in 76.9% of images, are non-credentials by hand-labeling); and (iv) a public dataset (Section III-E) released with the pipeline (metadata for 12,716,568 repositories, the layer graph, and the multi-scanner reports for the 52,895 scanned images). 1 Cybersecurity Ventures, 2023, Sonatype, 2024 2 Docker, 2025 survey, CNCF, 2024 3 Docker Hub

II. R ELATED W ORK Table I positions ChimangoScan against three lines of prior work: large-scale security measurements of Docker Hub, studies of inter-scanner agreement, and studies of secrets and misconfiguration in container images. Table I: Positioning against prior work. Work

Year

Images

Scanners

Vuln.

Misconfig.

Secrets

Crossscanner

Shu et al. [17] Zerouali et al. [20] Liu et al. [10] Wist et al. [19] Dahlmanns et al. [5] Dr. Docker [16]

2017 2019 2020 2021 2023 2025

356,218 7,380 2,227,244 2,500 337,171 33,952

1 1 1 1 1 1

✓ ✓ ✓ ✓ ✗ ✓

✗ ✗ ✗ ✗ ✗ ✓

✗ ✗ ✗ ✗ ✓ ✓

✗ ✗ ✗ ✗ ✗ ✗

Kaur et al. [8] Mills et al. [12]

2021 2023

44 380

4 6

✓ ✓

✗ ✗

✗ ✗

✓ ✓

ChimangoScan (this work)

2026

52,895

6

✓

✓

✓

✓

Large-scale Docker Hub measurements. Docker Hub has been measured periodically since Shu et al. [17], whose DIVA tool scanned 356,218 images with Clair, found >180 vulnerabilities/image, and traced parent-to-child propagation. Liu et al. [10] scaled to 2.2 million images and found 42 malicious ones, and Zerouali et al. [20] measured technical lag (how far a package trails its latest fixed version) in 7,380 Debian-based images. All three used a single detector. A complementary line reconstructs ecosystem structure: Opdebeeck et al. [13] build an inheritance network from 636,625 images, the closest prior work to our layer graph but at a fraction of the scale and without multi-scanner measurement. The closest work. Dr. Docker [16] crawls 12,079,309 repositories, 637,259 fewer than our 12,716,568, builds an ancestry-hashed layer graph, selects influential images, and scans 33,952 images for five threat classes. ChimangoScan adopts two of its ideas, the cap-refining keyword crawl and the ancestry-hashed layer identifier, and forks its open Go codebase (Section III): we implement Stage I, an unimplemented stub upstream, and re-engineer Stage II for distributed, resumable operation. It departs in two respects: (i) scale and tooling: Dr. Docker scans only 3,000 sampled images for vulnerabilities with one SCA engine, whereas ChimangoScan runs six scanners on all scanned repositories; (ii) reproducibility: its malware verdicts use a corporate antivirus, whereas ChimangoScan uses only open-source scanners. Further related lines. Scanner agreement has been measured only on small samples (four scanners, 44 images, Jaccard 0.59 to 0.80 [8]; six scanners, 380 images [12]). We revisit this question at the scale of our corpus. For secrets and misconfiguration, Dahlmanns et al. [5] found secrets in 8.5% of images and over 52,000 private keys, building on repository secret-leakage work [11]. Rosa et al. [14] and Cito et al. [4] study Dockerfile smells, and Ahamed et al. [1] derive audit use cases that align image checks of this kind (content trust, HEALTHCHECK, non-root user) with the NIST SP 800-190 and OWASP container-security guidelines. ChimangoScan covers secrets (TruffleHog) and misconfiguration (Dockle) in the same pipeline. III. T HE C HIMANGO S CAN M EASUREMENT P IPELINE ChimangoScan is a three-stage pipeline (Figure 1). Stage I discovers Docker Hub repositories; Stage II resolves each into concrete images and reconstructs the image layer graph; Stage III scans images, prioritized by the layer graph, with six independent scanners. Stages I and II are written in Go, Stage III in Python. Two methodological ideas are adopted from Dr. Docker [16] and credited where used: the keyword crawl that recursively refines any query saturating the API’s result cap (Stage I) and the ancestry-hashed layer-node identifier (Stage II). We fork Dr. Docker’s open Go codebase, implementing the crawl (a stub upstream) ourselves and re-engineering the layer-node builder for distributed operation (Sections III-A and III-B). The new pipeline elements are the exposure-based prioritization of the scan queue (Section III-C) and the sixscanner consolidation pipeline of Stage III (Section III-D). a) Terminology.: We use four distinct nouns throughout. A repository is a namespaced bucket on Docker Hub (e.g. library/alpine); the Hub reports a single pull count per repository. A tag (e.g. latest, 3.18) is a mutable label inside a repository pointing to a specific image. An image is identified by a content-addressed sha256 digest; two repositories or tags may share a digest when byte-identical, and every aggregate statistic in this paper deduplicates by image digest. A layer is one filesystem slice inside an image, identified by its own digest and shared across images built from the same base; the IS_BASE_OF layer graph of Section III-B captures that sharing. Stage I enumerated 12,716,568 repositories; Stage II resolved the most-pulled repositories (the popularity head) in decreasing pull-count order, down to roughly 72 pulls (44.05% of the crawl, Section III-B), so the layer graph and the downstream-propagation counts built on it (Section IV-G) are lower bounds over the full namespace.

1

Dockerhub API

Crawler (Go)

2

Builder (Go)

3

Multi-scanner scan

→

Repository discovery via prefix search

Pull Extract, Layer Forest, Exposure E(I)

(12,716,568 repositories)

(84.7M nodes & 54.4M edges)

(6 scanners per image)

Figure 1: The three-stage pipeline.

A. Stage I: Repository Discovery Stage I enumerates the Docker Hub namespace through the public Search API. Because the API caps any query at 10,000 results, a crawler must refine any keyword whose query saturates the cap (the cap-refining idea of Dr. Docker [16]); we realize this as a prefix-trie traversal of repository names, seeding 38 single-character prefixes (a to z, 0 to 9, -, _) and expanding any prefix that returns the 10,000-result ceiling into its 38 children (py → pya, pyb, . . . ), shortest-first. The crawler is a distributed, resumable Go system and ran over several months in 2026. One caveat bounds exhaustiveness: the API’s ElasticSearch backend treats the hyphen as a token separator, so repository names with a hyphen in the middle are explored only best-effort; we are not aware of repositories missed this way but cannot rule it out. By scan time the crawler had indexed 12,716,568 repositories from 2,051,801 prefix queries (all in 2026), recording each one’s pull count, stars, and last-updated timestamp. Docker advertises “14M+ container images”; our 12.7 million repositories (each holding many tags) cover very nearly the entire public namespace, since every cap-saturated prefix was expanded. The 663.8 billion pulls of Table II are a cumulative historical total, not Docker’s “11B+ monthly”. The pull-count distribution (reproducing Dr. Docker [16]) is extremely heavy-tailed: a median of 62 pulls but a 99th percentile of 20,781 and a maximum of 2.4×1010 , with 113 repositories drawing 60.6% of all pulls and 95% pulled fewer than a thousand times (Table II4 ). The layer graph shows the same concentration structurally: only a small minority are base images, with heavytailed downstream counts. A uniform sample would thus spend almost all its effort on images the ecosystem barely uses; the exposure score (Section III-C) exploits exactly this imbalance. Table II: Repository pull-count distribution over the crawl. Pull count

Repos

% pulls

Pull count

Repos

% pulls

≥1 B 100 M–1 B 10 M–100 M 1 M–10 M

113 461 2,595 11,856

60.6% 20.1% 11.1% 5.3%

100 k–1 M 1 k–100 k <1 k Total

42,145 572,662 12,050,759 12,680,591

2.1% 0.8% <0.1% 100%

B. Stage II: Image Resolution and the Layer Graph A repository is not an image: it is a set of tags, each resolving to one or more architecture-specific image digests. The Stage II builder claims each repository exclusively from the crawl pool (so none is processed twice), queries the Docker Hub API for each one’s tags and manifests, then pulls each image and extracts the ordered list of filesystem layers that compose it. The builder consumes repositories in decreasing pull-count order, so the popularity head is processed first; at the dataset freeze used in this paper Stage II has resolved 5,601,045 of the 12.7 M crawled repositories (44.05%) into 6,399,608 tags and 7,416,671 image digests, with the remaining tail of rarely pulled repositories still pending. Layers are the unit of reuse: an image built FROM python:3.12 physically shares that base’s layers, and ChimangoScan reconstructs this sharing as a directed graph. For the layer-node identifier we adopt Dr. Docker’s ancestry-hashed scheme [16], instantiated with SHA-256: id = sha256(parent_id ∥ sha256(layer_digest)), so the identifier encodes the layer’s full ancestry and identical-content layers with different histories stay distinct. Our builder is a distributed Go service: each worker atomically claims the next unbuilt repository from a shared MongoDB pool (resumable after crashes, stale claims released), pulls its recent tags and manifests, extracts the ordered layer list, and inserts IS_BASE_OF edges from each layer to the one above 4 The distribution covers the 12,680,591 repositories with a recorded pull count; 35,977 of the 12,716,568 crawled lack one.

it. Repositories deleted between crawl and build are retired rather than stalling the queue. The deterministic identifier gives each layer at most one parent, so the graph is a forest of out-trees (disjoint trees with all edges pointing away from the root), stored in Neo4j with 54,382,383 IS_BASE_OF edges over 84.7 M nodes. A flaw in a reused base layer is therefore inherited by its whole subtree. The exposure prioritization on this forest (Section III-C) is specific to this work: Dr. Docker ranks by dependency weight, its count of downstream images, whereas ChimangoScan folds an image’s own pull count and its downstream reach into the single score E(I). C. Exposure-Based Prioritization Scanning all 6.7 M images is infeasible, and they are not equally worth scanning: a flaw in a base image thousands inherit risks far more than one in a rarely pulled leaf. ChimangoScan ranks the queue by an exposure score that rewards downstream reuse. Prior work ranks bases by descendant count [17] or by dependency-graph weight [16]; exposure instead folds an image’s own popularity and that of its entire downstream subtree into a single scalar (the container-layer analog of dependency-graph impact scoring [15]), linearly ordering the queue by total ecosystem reach. For an image I, write RI for the repository publishing I, p(R) for the pull count of a repository R, LI for I’s top layer, and D(LI ) for the set of images whose top layer is a strict descendant of LI in the forest; a descendant image D ∈ D(LI ) is published by repository RD . Because bases nest, we attribute each image to a single owner, the image of greatest own pull count among it and its ancestors, so no downstream pull is double-counted. Exposure is then I’s own pull count plus those of every image it owns: X p(RD ). (1) E(I) = p(RI ) + D ∈ D(LI ) owner(D) = I

The queue is sorted by E(I), with ties broken by the downstream image count |D(LI )| (Dr. Docker’s dependency weight [16]). Single-owner attribution credits each downstream pull to the most-pulled base in its lineage, and a daemon recomputes the scores in a near-linear pass as the crawl grows, placing alpine:latest first (E ≈ 8.3 × 1010 ). Two rules guard against misplaced credit. A byte-identical republication (a bare FROM) is credited to the canonical most-pulled reference, and a generic metadata-only layer (LABEL, CMD) recurring under many parents is barred from owning downstream images; both rules only move credit toward the more-pulled base. Because Stage II resolves only recent tags, a subtree’s owner is occasionally a less-pulled repository pinning the same base; this occurs only among the least-pulled repositories Stage II resolved. The ranking head has two kinds of image. General-purpose bases (alpine, ubuntu, debian) draw 72% to 86% of their exposure from downstream images. Heavily pulled application images (nginx, memcached, busybox, Istio) are seldom used as a base, so their exposure is almost all their own pulls. D. Stage III: The Multi-Scanner Scan Pipeline Stage III serves the exposure-ordered queue to workers that pull each image pinned by digest and run six static scanners covering four dimensions: software inventory (Syft); package vulnerabilities from three databases (Trivy, Grype, OSV-Scanner, over the National Vulnerability Database (NVD)/OSS-Index, the Anchore VulnDB, and Google’s Open Source Vulnerabilities (OSV) database respectively, so each detects CVEs the others miss); misconfiguration against the CIS (Center for Internet Security) Docker Benchmark (Dockle); and hardcoded secrets across 700+ detectors (TruffleHog). The queue is keyed by each repository’s latest tag, so the reported posture is one of latest tags, not all published tags. A per-scanner adapter normalizes each output to a common six-level severity scale; TruffleHog secrets are marked critical only when verified live, otherwise medium. Findings are then consolidated per image but not deduplicated across scanners, so a CVE found by three scanners counts three times. That non-deduplication is what makes inter-scanner agreement measurable (Section IV-C). E. Dataset The scan ran on 13 commodity x86-64 workers (Debian 12 or Ubuntu 24.04, 8 to 32 threads, 32 to 128 GB of RAM, no GPU), each scanning linux/amd64 images. The unit is the repository reference, one latest image per repository; the campaign scanned the 52,895 highest-exposure ones (84.7% of all 663.8 billion recorded pulls), and deduplicating by content digest to 51,751 distinct images leaves the results essentially unchanged. The reports total 170,373,044 findings (141.7 M package vulnerabilities, 23.2 M inventory components, 4.96 M secrets, 0.58 M misconfigurations; Trivy’s built-in secret and misconfiguration checks feed the latter two categories alongside TruffleHog and Dockle); we release the full dataset with the pipeline (Table III). IV. R ESULTS ChimangoScan scanned the 52,895 highest-exposure repositories, a census of the most consequential images on Docker Hub, not an upper bound over the whole registry. Exposure does not predict vulnerability (Section IV-F).

Table III: Dataset summary. Crawl and layer graph

Scan campaign (Stage III)

Repositories crawled 12,716,568 Repositories Stage II-resolved 5,601,045 Prefix queries issued 2,051,801 Tags resolved 6,399,608 Image digests resolved 7,416,671 Layer nodes 84.7 M IS_BASE_OF edges 54,382,383 Images in scan queue 6.7 M last_updated coverage (crawl) 95.7%

Repositories scanned Distinct images by content Scanners per image Worker machines Median scan time / image Distinct CVEs detected Per-image reports (DB) MongoDB crawl Neo4j layer graph Total dataset

Merged findings by category

(52,895 repositories, total 170,373,044)

Category

Findings

Package vulnerabilities Software-inventory components Embedded secrets Misconfigurations

52,895 51,751 6 13 (Debian/Ubuntu) 117 s 52,624 192 GB 24.9 GB 65.9 GB 283 GB

Share

Scanners

Img. ≥1

3 1 2 2

96.3% 96.3% 76.9% 98.0%

141,683,960 83.2% 23,151,449 13.6% 4,955,892 2.9% 581,743 0.3%

A. Vulnerability Prevalence Known vulnerabilities are pervasive. Of the scanned repositories, 96.3% carry at least one known package vulnerability (only 3.7% are clean), 93.4% ship a critical-severity one and 95.5% a high-severity one; the per-image count is heavily right-skewed (Figure 2(a)): the median image carries 885 merged findings, the mean is 2,679, the 99th percentile 20,109, and the maximum 113,166. These counts are merged, not deduplicated across scanners, which inflates the mean (Section IV-C). Across the 141.7 million package-vulnerability findings (Table IV), 5.2% are critical and 25.2% high, a combined 43.1 million; because a base image’s layers are inherited by every image built on it (Section III-B), each critical finding in a widely reused base propagates across its entire downstream subtree. Table IV: Package-vulnerability findings by severity. Critical

High

Medium

Low

Info.

Unrated

Total

7,377,355 5.2 49,392 93.4

35,740,343 25.2 50,534 95.5

65,727,713 46.4 50,872 96.2

19,418,002 13.7 49,951 94.4

9,927,589 7.0 33,708 63.7

3,492,958 2.5 37,393 70.7

141,683,960 100 50,957 96.3

1.00

medium

(b)

low

info

unknown

60M

0.75 0.50 0.25 0.00

high

median 885

0

5k

10k

15k

Vulnerabilities per image

20k

40M 20M 0

t y e Syf Triv Gryp

e g V OS Dockl rufHo T

Scanner

Wall time per scan (s)

critical

(a) Findings

Cumulative fraction

Findings % of findings Images ≥1 % of images

80 60 40 20 0

(c)

t Syf

y e Triv Gryp

e g V OS ockl ufHo D Tr

Scanner

Figure 2: Per-image: (a) cumulative vulnerability distribution, (b) by scanner/severity, (c) scan time. B. Per-Scanner Output, Reliability and Cost The six scanners measure different things, and their volumes are not comparable across categories (Table V, Figure 2(b)): among the three vulnerability scanners Grype emits the most findings (59.1 M), followed by Trivy (45.0 M) and OSVScanner (38.0 M). Syft inventories 23.2 M software components, TruffleHog reports 4.9 M secret findings and Dockle 0.24 M misconfigurations. Reliability varies sharply. The share of images scanned without error was 94.6% to 98.8% for five scanners but only 79.9% for Trivy (10,614 invocations errored). The failures are specific to Trivy, not to the infrastructure. All six scanners run against the same locally exported image archive (Section III-D), yet Syft and Grype error on only about 1,200 to 1,900 images each. Four in five of Trivy’s error messages report a timeout acquiring the tool’s local cache lock (“cache may

be in use by another process”), a concurrency limitation of the scanner under parallel operation rather than a property of the images scanned. A measurement that relied on Trivy alone would therefore silently miss roughly one image in five. Table V: Findings by scanner and severity. Scanner

Findings

Critical

High

Medium

Low

Run OK

Syft Trivy Grype OSV Dockle TruffleHog

23,151,449 44,957,561 59,061,336 38,046,373 235,029 4,921,296

– 1,478,679 2,163,552 3,741,595 45,411 2,209

– 9,813,224 11,733,733 14,304,383 – 0

– 25,275,077 25,802,146 14,738,700 42,587 4,919,087

– 8,069,525 9,354,135 2,169,974 147,031 0

97.7% 79.9% 96.4% 94.6% 98.0% 98.8%

The measurement is also costly. Grype is the slowest at 35.1 s per image, and running all six on one image took a median of 117 s (Figure 2(c)); the mean of 197 s is inflated by a tail reaching 9,433 s. Syft found a median of 205 components per image (mean 438, maximum 51,021; Figure 3(c)), dominated by npm (33.7%) and deb (28.2%), then Java, Go and .NET (Figure 3(a)).

npm deb java-archive go-module dotnet rpm apk python

(b) 6.5M

2.0M 1.8M 1.6M 910k 809k 718k

0

2M

4M

6M

SBOM components

7.8M

Box URI PrivateKey BingSubscrip.. GitHubOauth2 Alchemy Confluent FixerIO

8M

281k 209k 190k 150k 103k 98k

0

Cumulative fraction

(a)

2.1M

559k

500k 1M 1.5M 2M

Secret detections

(c)

1.00 0.75 0.50 0.25 0.00

median 205

0

1k

2k

3k

Components per image

Figure 3: (a) Components by ecosystem, (b) secrets by detector, (c) components per image. C. Inter-Scanner Divergence

Trivy

16.4M

Grype

22.2M

28.3M

2.2M 1.0M

1.4M

9.2M

OSV-Scanner

(b) marginal Nth-scanner gain 100%

100 78%

75 50

cumulative marginal gain

45%

25 0

1

2

3

Number of vulnerability scanners

(c) all vs distinct, by severity 108

Vulnerability count

(a) scanner agreement

Distinct vulns recovered (%)

Running three vulnerability scanners on every image lets us quantify how much the measurement depends on the tool. We group the package-vulnerability findings within each image by (vulnerability, package). Of the 80.7 million distinct groups, 66.8% are reported by only one scanner and just 2.7% by all three (Figure 4(a)); even the closest pair, Grype and Trivy, co-detect only 22.2 M. The divergence also shows in the aggregate counts. Grype reports 59.1 M findings against OSV’s 38.0 M, a 1.55× spread (Table V). The best single scanner recovers only 66.9% of distinct groups (Figure 4(a)), so a one-tool measurement misses about one distinct vulnerability in three. Figure 4(b) shows the marginal gain of each added scanner, and Figure 4(c) contrasts merged findings with distinct groups per severity. This is consistent with the small-sample scanneragreement literature [8, 12], here at the scale of our full corpus: a single Docker Hub vulnerability count reflects, in large part, the scanner used to obtain it.

all findings distinct (CVE, pkg)

107 106 . . . Crit High Med Low Info Unr

Figure 4: Inter-scanner divergence: (a) groups by subset, (b) N th-scanner gain, (c) all vs. distinct by severity.

D. Secrets and Misconfiguration Beyond vulnerabilities, ChimangoScan measures two further dimensions. Dockle flagged at least one misconfiguration from the CIS Docker Benchmark in 98.0% of images (51,853 of them); the most frequent (Table VI) are a missing content-trust configuration, a missing HEALTHCHECK instruction, and the container running as root. Of Dockle’s findings, 45,411 are at its FATAL checkpoint level, which we treat as critical severity. These flag concrete security faults: the most consequential is a credential stored in an environment variable or file (check CIS-DI-0010), which Dockle raised for 10,303 images, and others include an empty user password and the presence of sudo in the image. These counts rest on structural properties of the image rather than on verdicts from a vulnerability database, so they are less tied to any single scanner’s vulnerability feed, though we do not measure their scanner-to-scanner stability directly. The near-universal prevalence is in line with studies of Dockerfile authoring practice, which find Dockerfile smells in a large share of images [6]. TruffleHog flagged at least one embedded secret in 76.9% of images (40,667 images, 4.9 M secret findings). This raw prevalence must be read with care. It counts detector hits, that is, strings matching a detection pattern, not exploitable credentials. As Dr. Docker and Dahlmanns et al. [16, 5] document, the large majority of TruffleHog hits are example keys, test fixtures, or already-public material; Dr. Docker found 99.3% of its raw detections invalid after filtering. We confirm this directly on our corpus. We drew a uniform random sample of 1,100 detections (95% confidence, ±3% margin) and classified every one by hand, rather than only the residual left after rule-based filtering. Just three were plausible live credentials: an application service-account key, an SSH host key, and an access token captured in an application log. The other 1,097 (99.7%, Wilson 95% CI 99.2 to 99.9%) are non-credentials. About 60% are package checksums and OS metadata; the rest are test fixtures, dependency caches, documentation examples, placeholders, and binary or locale artifacts. Every PrivateKey detection but the service-account key fell in a crypto-library self-test, an SSH/TLS test fixture, or a shared object. The 76.9% detector-hit prevalence is therefore an upper bound dominated by false positives: only about 0.3% of detections are plausible credentials, so the prevalence of validated secrets is far lower. Active validation of these residual candidates is left to future work (Section V). The detector mix (Figure 3(b)) corroborates this. Generic URI and private-key patterns dominate, exactly the categories most prone to false positives from example values. Beyond prevalence, the distribution of how many secrets an image carries is itself heavy-tailed (Figure 5). The median image carries 13 detector hits, but the 99th percentile reaches 1,230 and the image with the most hits reports 19,856. Official images, although slightly more likely to carry at least one secret (Section IV-E), carry far fewer of them; their per-image count tops out at 1,251 against the community tail above 19,000. This is consistent with Dahlmanns et al. [5], who likewise found that a minority of images account for most embedded secrets; here the distribution makes that concentration explicit.

Misconfiguration check

Images

%

Content-trust off (CIS-DI-0005) No HEALTHCHECK (CIS-DI-0006) No dedicated user (CIS-DI-0001) setuid/setgid files (CIS-DI-0008) Credential in env/file (CIS-DI-0010) Empty user password (DKL-LI-0001) sudo present (DKL-DI-0001)

51,847 49,792 41,863 31,785 10,303 4,867 4,168

98.0 94.1 79.1 60.1 19.5 9.2 7.9

Figure 5: Secret detections per image (CDF): official vs. community.

1.00

Cumulative fraction

Table VI: Top Dockle misconfiguration checks.

0.75 0.50 0.25 0.00

Community Official

100

101

102

103

TruffleHog secret detections per image

104

E. Official versus Community Images Splitting the corpus by namespace (official images occupy library) reproduces Liu et al.’s [10] official-versus-community comparison (Figure 6(a)). The 130 official images carry a median of 455 merged vulnerability findings, the 52,765 community images 886 (means: 1,046 official, 2,683 community), and 50.0% of community images sit above the corpus median against 32.3% of official ones: community images remain the more vulnerable population, as Liu reported, though both now sit far higher in absolute counts. Secrets show the reverse ordering (Figure 6(b)): TruffleHog flags a secret in 86.9% of official against 76.9% of community images, but these are raw hits and the gap is modest. The same ordering held in Shu et al. [17] (community median 158 in 2017), so it persists across nine years even as counts rose. F. Popularity, Exposure and Security Posture A natural question for a popularity-ranked corpus is whether the images the ecosystem most depends on are better maintained. They are not. Raw pull count is essentially uncorrelated with distinct vulnerability count (Spearman rank correlation ρ = −0.01,

Vulnerabilities per image

100k 10k 1k 100 10 1

Official

(a) med. 886

med. 455

Vuln. above corpus median

Community

(b)

50%

32%

77% 87%

1 secret Official

Community

0

25

50

75

100

Images (%)

Figure 6: Official vs. community: (a) vulnerabilities per image, (b) secret prevalence and share above median.

102

1k 100

101

10 1 100

10k

1M

100M

Repository pull count

10B

100

(b) exposure decile (ρ = −0.016)

2000

100 80

1500

60

1000

40

500 0

IQR median vuln. critical prev.

1

2

3

20 4

5

6

7

8

Exposure decile (1 = lowest)

9

Images with a critical vuln. (%)

103

Distinct vulnerabilities per image

10k

(a) pull count Spearman ρ = −0.008

Images per bin

Distinct vulnerabilities per image

Figure 7(a)); our exposure metric (Section III-C), which adds the pulls flowing through an image’s downstream layer subtree, gives the same verdict. Across exposure deciles (Figure 7(b)) the median vulnerability count shows no clear trend (369 in the highest-exposure decile), with ρ = −0.02 for exposure against vulnerability count and ρ = −0.04 against critical-vulnerability count, both negligible. Critical prevalence stays near 93% across the higher-exposure deciles, so even the most heavily reused base images almost all ship a critical finding, echoing a Maven Central study where dependency centrality is not a safeguard against vulnerability [18].

10

0

Figure 7: (a) Vulnerabilities vs. pull count; (b) by exposure decile. G. Exposure-Weighted Vulnerability Risk Counting the images a CVE affects treats a flaw in alpine and a flaw in an abandoned image with no dependents as equal. Because every image in the corpus carries an exposure score, we can instead weight each CVE by the ecosystem reach of the images it affects. We sum exposure over the images that carry each CVE, which ranks vulnerabilities by the share of the ecosystem they can affect rather than by raw image count. In Table VII, “% expo.” is the share of total corpus exposure carried by the affected images. The ranking is dominated by recent CVEs in zlib and glibc, the C libraries embedded in nearly every base image, together with the Go standard library (stdlib) that ships inside the many Go-based images in the corpus: the single highest-reach CVE touches images accounting for 47.3% of the corpus’s total exposure while being present in only 44.9% of images by count. This gap between image count and exposure share is the central finding: a CVE in a base library is not just one of many; it endangers a share of the ecosystem far larger than its image count suggests, and the exposure metric makes that quantitatively concrete. The layer graph lets us go one step further and measure how far a vulnerability propagates. For each CVE we count the distinct downstream images that inherit a vulnerable layer. Starting from the images that directly carry the CVE, we take the union of their descendant subtrees in the IS_BASE_OF forest. Each distinct downstream image is counted once (Table VIII). Taking the union, rather than summing each affected image’s downstream count, avoids double-counting the descendants that several affected base images share. The reach is nonetheless large. Each top CVE is inherited by 1.0 to 1.14 million distinct downstream images, a propagation factor (distinct downstream over directly affected images) of 39 to 49, with a single zlib flaw reaching 1,129,391. These counts quantify, on the reconstructed IS_BASE_OF forest, how far a single flaw spreads through the supply chain, and they render per-CVE the parent-to-child vulnerability inheritance that Shu et al. [17] first documented at the level of whole images. The top-reach CVEs sit in libraries that ship with nearly every base image (zlib,

Table VII: Highest-reach CVEs by exposure. CVE

Package

Sev.

Images

% expo.

CVE-2026-27171 CVE-2026-4046 CVE-2026-5928 CVE-2026-5435 CVE-2026-5450 CVE-2026-33814 CVE-2026-33811 CVE-2026-39820

zlib glibc glibc glibc glibc stdlib stdlib stdlib

High High High Crit. Crit. High High High

23,726 18,774 18,599 18,549 18,086 12,873 12,778 12,778

47.3% 46.5% 46.2% 46.1% 45.6% 44.6% 43.2% 43.2%

glibc, libcrypto3), so part of their reach reflects sheer ubiquity rather than the layer hierarchy; the columns of Table VIII separate these effects, with the direct count measuring how widespread the vulnerable library is among the scanned images and the propagation factor measuring the amplification contributed by layer inheritance alone. Direct counts are restricted to images resolved in the Stage II layer graph, so they sit slightly below the affected-image counts of Table VII. One caveat remains. The IS_BASE_OF graph spans only the Stage II-resolved fraction of the crawl, so these distinct-downstream counts are structural lower bounds; the true reach on Docker Hub is at least this large. Table VIII: Per-CVE downstream propagation. CVE

Package

Direct Distinct downstr. Factor

CVE-2026-28388 CVE-2026-28390 CVE-2026-28389 CVE-2026-27171 CVE-2026-28387 CVE-2026-22796 CVE-2025-68160 CVE-2025-69421

libcrypto3 libcrypto3 libcrypto3 zlib libcrypto3 libcrypto3 libcrypto3 libcrypto3

28,343 27,768 27,758 23,013 23,819 26,279 26,279 26,278

1,144,010 1,134,329 1,134,319 1,129,391 1,096,284 1,033,461 1,033,461 1,033,459

40.4 40.9 40.9 49.1 46.0 39.3 39.3 39.3

H. Comparison with Prior Measurements

Images with a known vulnerability (%)

Absolute vulnerability counts are not comparable across studies, since the measurements differ in scanner, sample and elapsed time, and our own data shows a 1.55× inter-scanner spread in finding volume alone (Section IV-C); we therefore compare prevalence and orders of magnitude rather than raw counts. Known-vulnerability prevalence shows continuity, not reversal. Across 2017 to 2025 it has stayed high (Shu: >80% of images; Liu: >64% of community images; Wist: 81.8% of certified images; Mills: 98.4% of images, 374 of 380; Dr. Docker: 93.7% of images; each with a different metric and scanner). Our 96.3% is at the upper end of this range, on par with the most recent multi-scanner study (Mills, 98.4%), so prevalence has not declined over the eight years these studies span (Figure 8).

100 90 80 70 60 50

Zerouali 100%

Mills 98.4%

Shu 80%

This work 96.3% 93.7% Dr. Docker

82.2% Wist 64% Liu

2017

2019

2021

Year of measurement

2023

2025

Figure 8: Known-vulnerability prevalence across studies, 2017 to 2026. I. Reproducing Prior Docker Hub Analyses To ground the comparison in method, we reproduced one concrete analysis from each of six prior Docker Hub measurements on our corpus (Table IX; Figures 9 and 10). As above, these comparisons show trends, not exact replications.

Table IX: Prior measurements reproduced on our corpus. Study

Reproduced analysis

Reported by the study

This corpus

Shu et al. [17]

high modal; community median 158

critical modal (93.4%); median 885

median 601, mean 1,336, max 7,338 ∼30% official, >64% community severe surface in language ecosystems

median 885, mean 2,679, max 113,166 93.8% official, 95.6% community 76.9% OS, 21.7% language

Mills et al. [12]

Worst-severity bucket; community vuln. median Vulnerabilities-per-image distribution High/critical prevalence, official vs. comm. Severe findings by ecosystem (OS vs. language) Oldest CVE still present; staleness effect

CVEs back to 1999

Dahlmanns et al. [5]

Secret prevalence; private-key category

8.5% validated; private keys dominant

CVEs back to 1999; median 414 (recent) vs. 1,085 (old images) 76.9% hits, 99.7% FP (hand-labeled)

Zerouali et al. [20] Liu et al. [10] Wist et al. [19]

Liu et al.\ 2020

This corpus (2026)

Share of high/critical findings (%)

Images with high/critical vuln. (%)

a) Shu, Zerouali, Liu.: Shu et al. [17] classified images by worst severity, ranked vulnerable packages, and tracked CVEs by year (Figure 10): the most common (modal) worst severity has shifted from high to critical (Figure 10(a)); the 52,624 distinct CVEs reach back to 1999 but 68.4% are 2020-or-later (Figure 10(b)); and the top vulnerable packages remain operatingsystem libraries (zlib 44,574 images, openssl 39,209; Table X). Zerouali et al. [20] found essentially every Debian-based container affected; we reproduce this at 96.3% prevalence. Liu et al. [10] split official versus community (Figure 9(a)): the community-above-official ordering holds, but both populations now sit far higher.

(a) Liu et al.\ 2020

100

95.6

93.8

75

64

50 30

25 0

Official

Community

Image type

(b) Wist et al.\ 2021 80

76.9

60 40 21.7

20 0

1.5

OS package ecosystems

Language ecosystems

Other

Package ecosystem class

Figure 9: Reproductions: (a) official vs. community prevalence [10]; (b) severe findings by ecosystem [19]. b) Wist, Mills, Dahlmanns.: Wist et al. [19] found severe vulnerabilities concentrated in language ecosystems; our corpus, ranked by exposure and dominated by OS images, inverts this (Figure 9(b)): of 43.1 million severe findings most are operatingsystem packages, with Go (5.3 M), npm (1.3 M) and Python (1.0 M) leading the language share. Mills et al. [12] noted CVEs back to 1999 and a staleness effect; both patterns hold in our corpus: images updated within a year carry a median 414 vulnerabilities against 1,085 for older ones (Figure 10(c)), consistent with the rising vulnerability lifespans reported across open-source ecosystems [2]. Dahlmanns et al. [5] found private keys dominant (8.5% validated); TruffleHog flags a private-key pattern in 40.2% of images, but our hand-labeling puts its false-positive rate at 99.7% (Section IV-D). (b)

n

one

low

2.2

ium

high

med

0.6

Most severe vulnerability

crit

ical

(c) Vulnerabilities per image

3.7

0

2k 0

20 11 20 15 20 19 20 23 20 26

20

20 07

40

4k

20 03

Images (%)

60

6k

19 99

93.4

80

Distinct CVEs detected

(a) 100

CVE publication year

median 75th pct.

6000 4000 2000 0 0

2

4

6

Image age (years since update)

8

Figure 10: Shu et al. [17] reproduced: (a) worst severity, (b) CVEs by year, (c) vulns vs. image age. V. L IMITATIONS AND C ONCLUSION Limitations. The corpus is not a random sample but the top of the exposure ranking, so prevalences describe the most consequential images, not the average one, and are not an upper bound (exposure does not predict vulnerability). The 76.9%

Table X: Ten most prevalent vulnerable packages. Package zlib openssl tar util-linux curl coreutils ncurses-base systemd expat bash

Vuln. img.

% corpus

Findings

CVEs

Img. w/ crit.

44,574 39,209 32,031 28,555 28,516 27,896 27,671 27,343 25,886 25,857

84.3% 74.1% 60.6% 54.0% 53.9% 52.7% 52.3% 51.7% 48.9% 48.9%

177,503 2,597,921 499,294 785,349 2,836,304 142,134 372,917 1,121,059 649,552 85,097

15 290 27 21 187 33 30 57 47 15

28,695 27,479 0 14 18,309 0 1,440 3,476 16,282 19

secret figure counts raw detector hits (99.7% non-credentials by hand-labeling), and reported vulnerabilities are likewise static scanner findings, not confirmed exploitable. Per-image counts are merged, not deduplicated (we report medians), and the unit is one latest image per repository (deduplicating to 51,751 digests leaves results unchanged). We scanned linux/amd64 only, and Stage II resolved only the most popular repositories (44%) and recent tags, so the propagation counts are lower bounds. Finally, the scan-reports database is frozen, but the crawl (MongoDB) and layer graph (Neo4j) are snapshots of a pipeline that kept running past the freeze, so the released copies sit a few percent above the counts reported here; every scan-derived result reproduces exactly from the frozen database, and the crawl- and graph-derived counts reproduce to within that margin. Practical implications. Three practices follow from the measurements. First, because the best single scanner recovers only 66.9% of distinct vulnerabilities (Section IV-C), audits and continuous-integration (CI) pipelines should run at least two vulnerability scanners backed by different databases rather than trust a single count. Second, exposure gives registry operators and platform teams a remediation order. It identifies the base images whose flaws reach the most pulls, so addressing those first targets the largest share of downstream inheritance, whereas ranking flaws by raw affected-image count alone would spend the same effort on images the ecosystem barely pulls (Section IV-G). Third, raw secret detections should not gate a deployment. With 99.7% of hits being non-credentials (Section IV-D), a validation step must precede any action on them, while the structural misconfigurations Dockle flags (running as root, missing HEALTHCHECK) are cheap to check and enforce in CI. Conclusion. We measured the security posture of the highest-exposure Docker Hub images,5 the bases on which 84.7% of all recorded pulls depend, with six independent scanners rather than one. Vulnerabilities, critical ones, and misconfigurations are near-universal, yet the single number a lone tool reports is largely a property of that tool, so ecosystem-scale measurements should report a scanner battery, not a single count. Exposure marks where a flaw does the most damage yet does not predict how vulnerable an image is; resolving Stage II fully and validating the residual secrets are natural extensions. We release the pipeline and dataset for audit and reuse.6 R EFERENCES [1] Waheeda Syed Shameem Ahamed, Pavol Zavarsky, and Bobby Swar. Security audit of Docker container images in cloud architecture. In ICSCCC 2021, pages 202–207. IEEE, 2021. [2] Seyed Ali Akhavani et al. Open source, open threats? investigating security challenges in open-source software. arXiv preprint arXiv:2506.12995, 2025. [3] Yekatierina Churakova et al. Vexed by VEX tools: Consistency evaluation of container vulnerability scanners. In FPS 2025, Lecture Notes in Computer Science, pages 139–156, 2025. [4] Jürgen Cito et al. An empirical analysis of the Docker container ecosystem on GitHub. In MSR 2017, pages 323–333. IEEE, 2017. [5] Markus Dahlmanns et al. Secrets revealed in container images: An internet-wide study on occurrence and impact. In ASIA CCS ’23, pages 797–811. ACM, 2023. [6] Thomas Durieux. Empirical study of the Docker smells impact on the image size. In ICSE 2024. ACM, 2024. [7] Omar Javed et al. Understanding the quality of container security vulnerability detection tools. arXiv preprint arXiv:2101.03844, 2021. [8] Bhupinder Kaur et al. An analysis of security vulnerabilities in container images for scientific data analysis. GigaScience, 10(6):giab025, 2021. [9] Piergiorgio Ladisa et al. SoK: Taxonomy of attacks on open-source software supply chains. In S&P 2023, pages 1509–1526. IEEE, 2023. [10] Peiyu Liu et al. Understanding the security risks of Docker Hub. In ESORICS 2020, volume 12308 of Lecture Notes in Computer Science, pages 257–276. Springer, 2020. [11] Michael Meli et al. How bad can it git? characterizing secret leakage in public GitHub repositories. In NDSS 2019. Internet Society, 2019. [12] Alan Mills et al. Longitudinal risk-based security assessment of Docker software container images. Computers & Security, 135:103478, 2023. [13] Ruben Opdebeeck et al. The Docker Hub image inheritance network: Construction and empirical insights. In SCAM. IEEE, 2023. [14] Giovanni Rosa et al. Fixing Dockerfile smells: An empirical study. In ICSME 2022. IEEE, 2022. [15] Bonan Ruan et al. Propagation-based vulnerability impact assessment for software supply chains. In ASE, 2025. [16] Hequan Shi et al. Dr. Docker: A large-scale security measurement of Docker image ecosystem. In WWW ’25. ACM, 2025. [17] Rui Shu et al. A study of security vulnerabilities on Docker Hub. In CODASPY ’17, pages 269–280. ACM, 2017. [18] Ehtisham Ul Haq et al. The ripple effect of vulnerabilities in Maven central: Prevalence, propagation, and mitigation challenges. arXiv preprint arXiv:2504.04175, 2025. 5 Code and dataset: https://github.com/ChimangoScan/chimangoscan 6 Generative AI tools assisted with writing and language revision of this manuscript; the authors reviewed all content and take full responsibility for it.

[19] Katrine Wist et al. Vulnerability analysis of 2500 Docker Hub images. In Advances in Security, Networks, and Internet of Things, Transactions on Computational Science and Computational Intelligence, pages 307–327. Springer, 2021. [20] Ahmed Zerouali et al. On the relation between outdated Docker containers, severity vulnerabilities, and bugs. In SANER 2019, pages 491–501. IEEE, 2019.

Related documents

• CVE-2026-91936 — HIGH 8.3#976188
• Vulnerability Management for Containers across Continuous Integration and Continuous Delivery (CI/CD) Pipelines#621150
• CVE-2026-97241 — HIGH 7.5#1159296
• No-Box Vulnerability Analysis: Description-only Detection of Indirect Prompt Injection Vulnerabilities in MCP Servers#1013684
• CVE-2026-92934 — CRITICAL 9.5#1001408