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

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](https://ubuntu.com/security/notices/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.*

Start with .github/workflows/build_docker_images.yml, comparing the ALLOWED_IMAGES array and strategy.matrix.image-name with the seven directories under docker/. Read docker/diffusers-onnxruntime-cpu/Dockerfile and the corresponding CUDA Dockerfile before confirming whether ONNX images are still supported. Done means the supported-image set and nightly/PR workflow behavior agree, with the chosen rebuild or retirement direction documented.

Written by the indexing model from the issue text.