Update Alpine-based rabbitmq images to fix SQLite CVE-2025-6965

[DougStanley14]

The rabbitmq:*-alpine images currently include SQLite 3.49.2-r0, which has a critical vulnerability CVE‑2025‑6965. According to the National Vulnerability Database, SQLite versions prior to 3.50.2 allow the number of aggregate terms to exceed the number of available columns, leading to a memory corruption issue. The SQLite project’s CVE table notes that the fix is in SQLite 3.50.2 (released 2025‑06‑28).

Only the 3.13.7-management-alpine image appears to have been rebuilt recently, but other tags (including 3.13.6-alpine, 3.13.7-alpine, etc.) still pull in the vulnerable sqlite-3.49.2-r0 package from Alpine, leaving users exposed. Could you please rebuild all RabbitMQ alpine variants against an Alpine release that provides SQLite ≥ 3.50.2 (or apply an explicit apk add --upgrade in the Dockerfiles)? This will address CVE‑2025‑6965 and ensure users receive the patched SQLite version.

Thanks in advance for your help!

[tianon]

The current latest Alpine image doesn't have any package updates available. 🤔

$ docker run -it --rm --pull=always rabbitmq:alpine sh
alpine: Pulling from library/rabbitmq
Digest: sha256:8f1a4555a52cb5bbd91fcacfed98f230a1762ef7a08cc05d7f711b8a31fb5ca5
Status: Image is up to date for rabbitmq:alpine
/ # apk list --no-cache --upgradeable
fetch https://dl-cdn.alpinelinux.org/alpine/v3.22/main/x86_64/APKINDEX.tar.gz
fetch https://dl-cdn.alpinelinux.org/alpine/v3.22/community/x86_64/APKINDEX.tar.gz
/ # 

Perhaps https://github.com/docker-library/faq#why-does-my-security-scanner-show-that-an-image-has-cves is useful 👀

[michaelklishin]

@DougStanley14 I am not against updating those older 3.13.x tags but as a RabbitMQ core team member, I fail to see why anyone would not move at least to 3.13.7 (or more recent 3.13.x release available to Broadcom customers), given that 3.13.x has been out of community support for close to a year now.

You cannot both stay on unsupported series and expect the latest updates, security-related or not.

[dstanbai]

@DougStanley14 I am not against updating those older 3.13.x tags but as a RabbitMQ core team member, I fail to see why anyone would not move at least to 3.13.7 (or more recent 3.13.x release available to Broadcom customers), given that 3.13.x has been out of community support for close to a year now.

You cannot both stay on unsupported series and expect the latest updates, security-related or not.

Understood (and agree) - we're in the process of upgrading to V4, but need some time to shake out any breaking changes. This vunl was a new blocker on our build pipeline, and we had some hot fixes that needed to go out, so I thought I'd ask

The latest 3.13.7 does have the fixed version of Sqlite, and neither does the latest 4.1.2 management alpine

[lukebakken]

Why is this CVE a concern as nothing in the RabbitMQ / Erlang / OpenSSL code uses SQLite?

Also, I just started up the rabbitmq:alpine, rabbitmq:3.13-alpine and rabbitmq:3.13.6-alpine images and find no evidence of SQLite on the running container. I'm not an Alpine expert, however.

docker-alpine-sqlite.txt

Is there a package that includes SQLite statically compiled in?

[yosifkit]

Oh, this is only the management images and only because it is a dependency of python3 (the only extra package in the alpine management images).

rabbitmq/3.13/alpine/management/Dockerfile

Line 18 in f48199c

apk add --no-cache python3; \

[yosifkit]

Background:

Tags in the [official-images] library file[s] are only built through an update to that library file or as a result of its base image being updated (ie, an image FROM debian:bookworm would be rebuilt when debian:bookworm is built).

-https://github.com/docker-library/official-images/tree/8384586122f68760fdcfc9472257d177be2d6282#library-definition-files

Official Images FAQ:

Though not every CVE is removed from the images, we take CVEs seriously and try to ensure that images contain the most up-to-date packages available within a reasonable time frame

- https://github.com/docker-library/faq/tree/e5475a9b3d7c34b8a1e3902df0f4959c5b33e593#why-does-my-security-scanner-show-that-an-image-has-cves

To ensure that we don't push contentless image changes, we rely on periodic base image updates.

We strive to publish updated images at least monthly for Debian. We also rebuild earlier if there is a critical security need. Many Official Images are maintained by the community or their respective upstream projects, like Ubuntu, Alpine, and Oracle Linux, and are subject to their own maintenance schedule.

- from the same FAQ link

[michaelklishin]

@yosifkit is Python needed by something in the image or is it to run rabbitmqadmin? If the latter, there is rabbitmqadmin v2 which compiles to a native binary.

In fact, one of the explicit design goals of v2 was to drop the Python dependency because it drags in a bunch of CVEs that eventually become our (Team RabbitMQ's) headache.

[tianon]

Oh, interesting - it's definitely for rabbitmqadmin! Is that something we should proactively update to, or will it become part of the plugin in the future replacing the Python version currently bundled?

rabbitmq/4.1/ubuntu/management/Dockerfile

Lines 13 to 21 in 01055a3

	# grab "rabbitmqadmin" from inside the "rabbitmq_management-X.Y.Z" plugin folder
	# see https://github.com/docker-library/rabbitmq/issues/207
	cp /plugins/rabbitmq_management-*/priv/www/cli/rabbitmqadmin /usr/local/bin/rabbitmqadmin; \
	[ -s /usr/local/bin/rabbitmqadmin ]; \
	chmod +x /usr/local/bin/rabbitmqadmin; \
	apt-get update; \
	apt-get install -y --no-install-recommends python3; \
	rm -rf /var/lib/apt/lists/*; \
	rabbitmqadmin --version

[lukebakken]

Yep, I suggest dropping the python-based rabbitmqadmin and upgrading to rabbitmqadmin-ng. I can find time to put together a PR for this.

I'm assuming I'll be pulling the latest rabbitmqadmin-ng from here, and installing it as /usr/local/bin/rabbitmqadmin.

@michaelklishin would it be possible to add checksums to the release artifacts on GitHub?

[tianon]

Also only currently covers two of amd64, arm32v7, arm64v8, ppc64le, riscv64, s390x (rabbitmq:management) and the slightly different amd64, arm32v6, arm32v7, arm64v8, i386, ppc64le, riscv64, s390x (rabbitmq:management-alpine), so we'll have to decide whether that warrants building from source, dropping support for architectures, or something else. 🤔

I also should've assumed it from the -gnu suffix, but those are also dynamic binaries compiled against glibc so they won't work at all for management-alpine. 😅

[lukebakken]

Maybe we should just drop rabbitmqadmin 🤔

[michaelklishin]

Building from source should not be particularly difficult. You need to install the Rust toolchain and delete it at the end of the image build.

[michaelklishin]

@lukebakken sure.

[michaelklishin]

Dropping rabbitmqadmin v1 entirely is also fine with me but given that building v2 is not going to be too involved, we should consider both options.

[lukebakken]

I'll look into adding @michaelklishin's excellent rabbitmqadmin via building with Rust.