CVEs found in latest ghcr.io/vroom-project/vroom-docker:v1.14.0

[joewragg]

Total: 24 (HIGH: 24, CRITICAL: 0)

Library	Vulnerability	Severity	Status	Installed Version	Fixed Version	Title	Link
bsdutils	CVE-2024-28085	HIGH	fixed	1:2.38.1-5+b1	2.38.1-5+deb12u1	util-linux: CVE-2024-28085: wall: escape sequence injection	Link
curl	CVE-2024-2398	HIGH	fixed	7.88.1-10+deb12u5	7.88.1-10+deb12u6	curl: HTTP/2 push headers memory-leak	Link
libblkid1	CVE-2024-28085	HIGH	fixed	2.38.1-5+b1	2.38.1-5+deb12u1	util-linux: CVE-2024-28085: wall: escape sequence injection	Link
libc-bin	CVE-2023-6246	HIGH	fixed	2.36-9+deb12u3	2.36-9+deb12u4	glibc: heap-based buffer overflow in __vsyslog_internal()	Link
libc-bin	CVE-2023-6779	HIGH	fixed	2.36-9+deb12u3	2.36-9+deb12u4	glibc: off-by-one heap-based buffer overflow in __vsyslog_internal()	Link
libc-bin	CVE-2024-2961	HIGH	fixed	2.36-9+deb12u3	2.36-9+deb12u6	glibc: Out of bounds write in iconv may lead to remote code execution	Link
libc-bin	CVE-2024-33599	HIGH	fixed	2.36-9+deb12u3	2.36-9+deb12u7	glibc: stack-based buffer overflow in netgroup cache	Link
libc6	CVE-2023-6246	HIGH	fixed	2.36-9+deb12u3	2.36-9+deb12u4	glibc: heap-based buffer overflow in __vsyslog_internal()	Link
libc6	CVE-2023-6779	HIGH	fixed	2.36-9+deb12u3	2.36-9+deb12u4	glibc: off-by-one heap-based buffer overflow in __vsyslog_internal()	Link
libc6	CVE-2024-2961	HIGH	fixed	2.36-9+deb12u3	2.36-9+deb12u6	glibc: Out of bounds write in iconv may lead to remote code execution	Link
libc6	CVE-2024-33599	HIGH	fixed	2.36-9+deb12u3	2.36-9+deb12u7	glibc: stack-based buffer overflow in netgroup cache	Link
libcurl4	CVE-2024-2398	HIGH	fixed	7.88.1-10+deb12u5	7.88.1-10+deb12u6	curl: HTTP/2 push headers memory-leak	Link
libgnutls30	CVE-2024-0553	HIGH	fixed	3.7.9-2+deb12u1	3.7.9-2+deb12u2	gnutls: incomplete fix for CVE-2023-5981	Link
libgnutls30	CVE-2024-0567	HIGH	fixed	3.7.9-2+deb12u1	3.7.9-2+deb12u2	gnutls: rejects certificate chain with distributed trust	Link
libmount1	CVE-2024-28085	HIGH	fixed	2.38.1-5+b1	2.38.1-5+deb12u1	util-linux: CVE-2024-28085: wall: escape sequence injection	Link
libsmartcols1	CVE-2024-28085	HIGH	fixed	2.38.1-5+b1	2.38.1-5+deb12u1	util-linux: CVE-2024-28085: wall: escape sequence injection	Link
libsystemd0	CVE-2023-50387	HIGH	fixed	252.19-1~deb12u1	252.23-1~deb12u1	bind9: KeyTrap - Extreme CPU consumption in DNSSEC validator	Link
libsystemd0	CVE-2023-50868	HIGH	fixed	252.19-1~deb12u1	252.23-1~deb12u1	bind9: Preparing an NSEC3 closest encloser proof can exhaust CPU resources	Link
libudev1	CVE-2023-50387	HIGH	fixed	252.19-1~deb12u1	252.23-1~deb12u1	bind9: KeyTrap - Extreme CPU consumption in DNSSEC validator	Link
libudev1	CVE-2023-50868	HIGH	fixed	252.19-1~deb12u1	252.23-1~deb12u1	bind9: Preparing an NSEC3 closest encloser proof can exhaust CPU resources	Link
libuuid1	CVE-2024-28085	HIGH	fixed	2.38.1-5+b1	2.38.1-5+deb12u1	util-linux: CVE-2024-28085: wall: escape sequence injection	Link
mount	CVE-2024-28085	HIGH	fixed	2.38.1-5+b1	2.38.1-5+deb12u1	util-linux: CVE-2024-28085: wall: escape sequence injection	Link
util-linux	CVE-2024-28085	HIGH	fixed	2.38.1-5+b1	2.38.1-5+deb12u1	util-linux: CVE-2024-28085: wall: escape sequence injection	Link
util-linux-extra	CVE-2024-28085	HIGH	fixed	2.38.1-5+b1	2.38.1-5+deb12u1	util-linux: CVE-2024-28085: wall: escape sequence injection	Link

[jcoupey]

Thanks for reporting, do you have any suggestion on how to fix this?

[joewragg]

It looks like most of these vulnerabilities are debian packages so looking at your dockerfile they maybe come from node:20-bookworm-slim?

Given that all these CVEs are 2024 and you haven't released since Jan I would imagine doing another release of vroom perhaps v1.14.1 would fix the issue.

By releasing again you're grabbing a more up to date node image it's looking like the latest node 20 bookworm has no HIGH or CRITICAL vulnerabilities in it.

I've just built a fresh image of vroom-docker getting:

Node.js (node-pkg)
==================
Total: 6 (HIGH: 4, CRITICAL: 2)

so a rerelease would be a massive improvement

[joewragg]

Additionally do you plan to release vroom-docker on a regular basis? Otherwise we may go ahead and release it ourselves on a more regular basis for our security needs

[jcoupey]

Releases for vroom-docker typically follow the upstream release process, see #80 on the workflow.

[jcoupey]

I guess most of those are now fixed after the upgrade in #88, shall we close here?

[joewragg]

We should probably release a new version of vroom-docker for these CVE fixes? I think you only release when there's a new version of vroom though right?