Two ONNX Docker images are missing from build_docker_images.yml, so their :latest tags have been frozen since June 2025

[kobihikri]

Hello, and thank you for diffusers.

I read CONTRIBUTING.md first — this is the "find or open an issue and wait for maintainer acknowledgment before opening a PR" step, and I've tried to keep it to one systematic issue rather than several one-offs. No PR from me unless you'd like one.

What I observed

docker/ contains seven image directories. .github/workflows/build_docker_images.yml lists five, in both of its jobs:

• the PR-time check — ALLOWED_IMAGES array, lines 51–57
• the nightly build-and-push — strategy.matrix.image-name, lines 99–104, with push: true and tags: diffusers/${{ matrix.image-name }}:latest

diffusers-onnxruntime-cpu and diffusers-onnxruntime-cuda appear in neither list. I checked both jobs specifically rather than assuming one matched the other.

The effect is visible on Docker Hub. I queried last_updated for the :latest tag of all seven today:

image	in the workflow?	:latest last pushed
diffusers-pytorch-cpu	✅	2026-07-29
diffusers-pytorch-cuda	✅	2026-07-29
diffusers-pytorch-xformers-cuda	✅	2026-07-29
diffusers-pytorch-minimum-cuda	✅	2026-07-29
diffusers-doc-builder	✅	2026-07-29
diffusers-onnxruntime-cpu	❌	2025-06-27
diffusers-onnxruntime-cuda	❌	2025-06-27

The five in the matrix rebuilt today. The two that aren't have been frozen for thirteen months — but they're still on Docker Hub under :latest, so a docker pull diffusers/diffusers-onnxruntime-cpu today returns the June 2025 build.

What's in the frozen image

I pulled diffusers/diffusers-onnxruntime-cpu:latest (linux/amd64) and scanned it with Trivy 0.72.0 inside a container. Python packages:

41 HIGH, 38 MEDIUM. Concentrated in:

package	installed	HIGH findings
pillow	11.2.1	14
GitPython	3.1.44	13
urllib3	2.5.0	4
setuptools	65.5.0	3
transformers	4.53.0	2

pillow is the one I'd look at first given what this image does — it's an image-processing library in an image-generation container.

The base layer, which scanners miss

docker/diffusers-onnxruntime-cpu/Dockerfile line 1 is FROM ubuntu:20.04. Focal left standard security support on 2025-05-31; Trivy flags it EOSL: true.

There's a subtlety worth flagging, because it's the part I found genuinely surprising. The image carries openssl / libssl1.1 at 1.1.1f-1ubuntu2.24. USN-8414-2, published 2026-06-09, fixes six OpenSSL CVEs for focal — but at version 1.1.1f-1ubuntu2.24+esm4, in pocket esm-infra, which requires an Ubuntu Pro subscription attached to the running system. A plain container has no such entitlement. I confirmed empirically that apt-get update && apt-get install inside ubuntu:20.04 resolves to 2.24, not +esm4.

Those six, with NVD CVSS 3.1:

CVE
CVE-2026-34182	9.1 CRITICAL	CMS fails to validate cipher/tag length sufficiently
CVE-2026-45447	8.8 HIGH	use-after-free verifying a crafted PKCS#7 / S-MIME message
CVE-2026-7383	8.1 HIGH	signed integer overflow → heap overflow in ASN1_mbstring_ncopy()
CVE-2026-34180	7.5 HIGH	out-of-bounds read parsing crafted DER ASN.1
CVE-2026-9076	7.5 HIGH	out-of-bounds read in CMS PWRI key unwrap
CVE-2026-42766	5.9 MEDIUM	NULL dereference in CMS decryption

Trivy reported none of these. Its OS-layer result for this image was a single MEDIUM (CVE-2025-4802, libc-bin). As far as I can tell the scanner doesn't model the Pro entitlement boundary — it treats a fix that exists in esm-infra as a fix. So this particular gap is invisible to Dependabot (no manifest for a FROM line) and to the container scanner you'd reach for to double-check. That's the reason I thought it was worth writing up rather than assuming you already had eyes on it.

What I did NOT establish

• I did not scan diffusers-onnxruntime-cuda. It shares the freeze date and is FROM nvidia/cuda:12.1.0-runtime-ubuntu20.04, so I'd expect a similar picture, but I haven't verified it and am not claiming it.
• No exploitability or reachability analysis for any CVE listed. I have not shown that any of them is triggerable through these images.
• I don't know whether the omission is deliberate. If ONNX support is being wound down, the two images may have been dropped from the matrix on purpose — in which case the right fix is probably the opposite of rebuilding them.
• I didn't determine who actually consumes these tags, so I can't tell you the blast radius.

Possible directions — your call entirely

1. If the images are still wanted: add both names to the two lists in build_docker_images.yml. That's the smallest change and would have caught this on the next nightly.
2. If they're not: retiring the Dockerfiles and deprecating or removing the Hub tags would stop :latest handing out a thirteen-month-old build.

Either resolves it. I'd rather not guess which you intend — happy to open a PR for whichever you prefer, or to leave it with you entirely.

Disclosure: AI-assisted (Claude Opus 5). Every claim above was reproduced by me in this session — I read both workflow jobs, queried Docker Hub for all seven tags, pulled and scanned the image in a container, and fetched USN-8414-2 and the six CVE scores from Ubuntu and NVD directly rather than citing them from memory.