registry.redhat.io/ocp-tools-4/jenkins-rhel8:v4.12.0-1723557810

With RPM updates as of

Show kernel-headers

ID	Age	Component	Trivy Severity	Grype Severity	Red Hat Severity	Scandy Opinion
CVE-2025-21613	108	github.com/go-git/go-git/v5	Critical	Critical	Important
CVE-2024-45337	134	golang.org/x/crypto	Critical	Critical	Important
CVE-2024-41110	276	github.com/docker/docker	Critical	Critical	Critical	False Positive
CVE-2024-38821	178	org.springframework.security:spring-security-web spring-security-web	Critical	Critical	Moderate
CVE-2024-24790	325	git-lfs stdlib	Critical	Critical	Moderate
CVE-2024-23653	450	github.com/moby/buildkit	Critical	Critical	Important	False Positive
CVE-2024-23652	450	github.com/moby/buildkit	Critical	Critical	Important	False Positive
CVE-2023-49569	472	github.com/go-git/go-git/v5	Critical	Critical	Critical	False Positive
CVE-2016-1000027	3213	org.springframework:spring-web spring-web	Critical	Critical	Moderate	Ignorable
CVE-2025-32913	11	libsoup	High	High	Important
CVE-2025-32911	11	libsoup	High	High	Important
CVE-2025-32908	11	libsoup	High	High	Important
CVE-2025-32907	11	libsoup	High	High	Important
CVE-2025-32906	11	libsoup	High	High	Important
CVE-2025-30204	34	github.com/golang-jwt/jwt/v4	High	High	Important
CVE-2025-27363	44	freetype	High	High	Important
CVE-2025-24928	66	libxml2 python3-libxml2	High	High	Important
CVE-2025-24855	42	libxslt	High	High	Important
CVE-2025-22869	58	golang.org/x/crypto	High	High	Important
CVE-2025-22228	35	org.springframework.security:spring-security-crypto spring-security-crypto	High	High	Important
CVE-2025-21614	108	github.com/go-git/go-git/v5	High	High	Important
CVE-2025-1244	72	emacs-filesystem	High	High	Important	Ignorable
CVE-2025-0624	65	grub2-common grub2-tools grub2-tools-minimal	High	High	Important
CVE-2024-56171	66	libxml2 python3-libxml2	High	High	Important
CVE-2024-55549	42	libxslt	High	High	Important
CVE-2024-54534	134	java-1.8.0-openjdk java-1.8.0-openjdk-devel java-1.8.0-openjdk-headless	High		Important
CVE-2024-53263	100	git-lfs	High	High	Important
CVE-2024-52531	165	libsoup	High	High	Important
CVE-2024-52530	165	libsoup	High	High	Important
CVE-2024-47606	134	java-1.8.0-openjdk java-1.8.0-openjdk-devel java-1.8.0-openjdk-headless	High		Important
CVE-2024-47072	168	com.thoughtworks.xstream:xstream xstream	High	High	Important
CVE-2024-34156	230	git-lfs stdlib	High	High	Important
CVE-2024-23651	450	github.com/moby/buildkit	High	High	Moderate	False Positive
CVE-2024-21626	449	github.com/opencontainers/runc	High	High	Important	False Positive
CVE-2024-12085	100	rsync	High	High	Important
CVE-2024-11187	86	bind-libs bind-libs-lite bind-license bind-utils python3-bind	High	High	Important
CVE-2024-10963	169	pam	High	High	Important
CVE-2024-6345	284	platform-python-setuptools python3-setuptools python3-setuptools-wheel	High	High	Important
CVE-2024-3727	351	github.com/containers/image/v5	High	High	Moderate
CVE-2024-3596	290	krb5-libs	High	High	Important
CVE-2024-1975	276	bind-libs bind-libs-lite bind-license bind-utils python3-bind	High	High	Important
CVE-2024-1737	276	bind-libs bind-libs-lite bind-license bind-utils python3-bind	High	High	Important
CVE-2024-1488	437	python3-unbound unbound-libs	High		Important
CVE-2023-49568	488	github.com/go-git/go-git/v5	High	High	Important
CVE-2023-45288	387	golang.org/x/net stdlib	High	High	Important
CVE-2023-45287	507	stdlib	High	High	Moderate
CVE-2023-45283	532	stdlib	High
CVE-2023-39325	563	golang.org/x/net stdlib	High	High	Important
CVE-2023-28840	752	github.com/docker/docker	High	High	Important
CVE-2023-27561	795	github.com/opencontainers/runc	High	High	Moderate
CVE-2023-2253	716	github.com/docker/distribution	High	High	Moderate
CVE-2022-23648	1150	github.com/containerd/containerd	High	High	Important
CVE-2021-43816	1206	github.com/containerd/containerd	High	High	Important
GHSA-xmmx-7jpf-fx42	318	github.com/docker/docker	Medium	Medium
GHSA-jq35-85cj-fj4p	542	github.com/docker/docker	Medium	Medium
GHSA-7ww5-4wqc-m92c	492	github.com/containerd/containerd	Medium	Medium
CVE-2025-46421	1	libsoup	Medium		Moderate
CVE-2025-46420	1	libsoup	Medium		Moderate
CVE-2025-32914	11	libsoup	Medium	Medium	Moderate
CVE-2025-32912	11	libsoup	Medium	Medium	Moderate
CVE-2025-32910	11	libsoup	Medium	Medium	Moderate
CVE-2025-32909	11	libsoup	Medium	Medium	Moderate
CVE-2025-32728	15	openssh openssh-clients	Medium	Medium	Moderate	Removable
CVE-2025-32414	17	libxml2 python3-libxml2	Medium	Medium	Moderate
CVE-2025-32053	22	libsoup	Medium	Medium	Moderate
CVE-2025-32052	22	libsoup	Medium	Medium	Moderate
CVE-2025-32051	22	libsoup	Medium	Medium	Moderate
CVE-2025-32050	22	libsoup	Medium	Medium	Moderate
CVE-2025-32049	22	libsoup	Medium	Medium	Moderate
CVE-2025-31721	22	org.jenkins-ci.main:jenkins-core	Medium		Moderate
CVE-2025-31720	22	org.jenkins-ci.main:jenkins-core	Medium		Moderate
CVE-2025-31344	10	java-1.8.0-openjdk java-1.8.0-openjdk-devel java-1.8.0-openjdk-headless	Medium	Medium	Moderate
CVE-2025-30698	9	java-1.8.0-openjdk java-1.8.0-openjdk-devel java-1.8.0-openjdk-headless java-11-openjdk java-11-openjdk-devel java-11-openjdk-headless	Medium	Medium	Moderate
CVE-2025-30691	9	java-1.8.0-openjdk java-1.8.0-openjdk-devel java-1.8.0-openjdk-headless java-11-openjdk java-11-openjdk-devel java-11-openjdk-headless	Medium	Medium	Moderate
CVE-2025-27625	50	org.jenkins-ci.main:jenkins-core	Medium		Moderate
CVE-2025-27624	50	org.jenkins-ci.main:jenkins-core	Medium		Moderate
CVE-2025-27623	50	org.jenkins-ci.main:jenkins-core	Medium		Moderate
CVE-2025-27622	50	org.jenkins-ci.main:jenkins-core	Medium		Moderate
CVE-2025-26465	67	openssh openssh-clients	Medium	Medium	Moderate	Removable
CVE-2025-25724	54	libarchive	Medium	Medium	Moderate
CVE-2025-24528	453	krb5-libs	Medium	Medium	Moderate
CVE-2025-22872	8	golang.org/x/net	Medium	Medium	Moderate
CVE-2025-22871	16	git-lfs stdlib	Medium	Critical	Moderate
CVE-2025-22870	43	git-lfs golang.org/x/net	Medium	Medium	Moderate
CVE-2025-22866	77	git-lfs stdlib	Medium	Medium	Moderate
CVE-2025-21587	9	java-1.8.0-openjdk java-1.8.0-openjdk-devel java-1.8.0-openjdk-headless java-11-openjdk java-11-openjdk-devel java-11-openjdk-headless	Medium	Medium	Moderate
CVE-2025-21502	93	java-11-openjdk java-11-openjdk-devel java-11-openjdk-headless	Medium	Medium	Moderate
CVE-2025-3576	10	krb5-libs	Medium	Medium	Moderate
CVE-2025-2784	31	libsoup	Medium	Medium	Moderate
CVE-2025-1118	65	grub2-common grub2-tools grub2-tools-minimal	Medium	Medium	Moderate
CVE-2025-0938	83	platform-python python3-libs python36	Medium	Medium	Moderate
CVE-2025-0690	65	grub2-common grub2-tools grub2-tools-minimal	Medium	Medium	Moderate
CVE-2025-0677	65	grub2-common grub2-tools grub2-tools-minimal	Medium	Medium	Moderate
CVE-2025-0622	65	grub2-common grub2-tools grub2-tools-minimal	Medium	Medium	Moderate
CVE-2025-0395	92	glibc glibc-common glibc-gconv-extra glibc-langpack-en glibc-locale-source glibc-minimal-langpack	Medium	Medium	Moderate
CVE-2024-57970	68	libarchive	Medium	Medium	Moderate
CVE-2024-56738	117	grub2-common grub2-tools grub2-tools-minimal	Medium	Medium	Moderate
CVE-2024-53920	149	emacs-filesystem	Medium	Medium	Moderate	Ignorable
CVE-2024-52616	161	avahi-libs	Medium	Medium	Moderate
CVE-2024-52615	161	avahi-libs	Medium	Medium	Moderate
CVE-2024-52533	165	glib2	Medium	Medium	Moderate
CVE-2024-52532	165	libsoup	Medium	Medium	Moderate
CVE-2024-52005	99	git git-core git-core-doc perl-Git	Medium	Medium	Moderate
CVE-2024-50602	180	expat	Medium	Medium	Moderate
CVE-2024-47804	204	org.jenkins-ci.main:jenkins-core	Medium		Moderate
CVE-2024-47803	204	org.jenkins-ci.main:jenkins-core	Medium		Moderate
CVE-2024-45783	65	grub2-common grub2-tools grub2-tools-minimal	Medium	Medium	Moderate
CVE-2024-45781	65	grub2-common grub2-tools grub2-tools-minimal	Medium	Medium	Moderate
CVE-2024-45777	65	grub2-common grub2-tools grub2-tools-minimal	Medium	Medium	Moderate
CVE-2024-45776	65	grub2-common grub2-tools grub2-tools-minimal	Medium	Medium	Moderate
CVE-2024-45775	87	grub2-common grub2-tools grub2-tools-minimal	Medium	Medium	Moderate
CVE-2024-45774	66	grub2-common grub2-tools grub2-tools-minimal	Medium	Medium	Moderate
CVE-2024-45492	238	expat	Medium	Medium	Moderate
CVE-2024-45491	238	expat	Medium	Medium	Moderate
CVE-2024-45490	238	expat	Medium	Medium	Moderate
CVE-2024-45341	98	git-lfs stdlib	Medium	Medium	Low
CVE-2024-45336	98	git-lfs stdlib	Medium	Medium	Moderate
CVE-2024-45310	233	github.com/opencontainers/runc	Medium	Medium	Low
CVE-2024-40635	38	github.com/containerd/containerd	Medium	Medium	Moderate
CVE-2024-39331	306	emacs-filesystem	Medium	Medium	Moderate	Ignorable
CVE-2024-38827	143	org.springframework.security:spring-security-core spring-security-core	Medium	Medium	Moderate
CVE-2024-38820	188	org.springframework:spring-context spring-context	Medium	Medium
CVE-2024-38809	212	org.springframework:spring-web spring-web	Medium	Medium	Moderate
CVE-2024-38808	248	org.springframework:spring-expression spring-expression	Medium	Medium	Moderate
CVE-2024-38428	328	wget	Medium	Medium	Moderate
CVE-2024-37891	312	python3-urllib3	Medium	Medium	Moderate
CVE-2024-37371	302	krb5-libs	Medium	Medium	Moderate
CVE-2024-37370	302	krb5-libs	Medium	Medium	Moderate
CVE-2024-35195	340	python3-requests	Medium	Medium	Moderate
CVE-2024-34397	353	glib2	Medium	Medium	Moderate
CVE-2024-34158	230	stdlib	Medium	High	Moderate
CVE-2024-34155	230	stdlib	Medium	Medium	Moderate
CVE-2024-30205	396	emacs-filesystem	Medium	Medium	Moderate	Ignorable
CVE-2024-30204	396	emacs-filesystem	Medium	Medium	Moderate	Ignorable
CVE-2024-30203	396	emacs-filesystem	Medium	Medium	Moderate	Ignorable
CVE-2024-29018	401	github.com/docker/docker	Medium		Moderate
CVE-2024-24791	297	git-lfs stdlib	Medium	High	Moderate
CVE-2024-24789	325	stdlib	Medium	Medium	Moderate
CVE-2024-24786	416	google.golang.org/protobuf	Medium	Medium	Moderate
CVE-2024-24785	416	stdlib	Medium	Medium	Moderate
CVE-2024-24784	416	stdlib	Medium	High	Moderate
CVE-2024-24783	416	stdlib	Medium	Medium	Moderate
CVE-2024-24557	449	github.com/docker/docker	Medium	Medium	Moderate
CVE-2024-23650	450	github.com/moby/buildkit	Medium	Medium	Moderate	False Positive
CVE-2024-21235	191	java-1.8.0-openjdk java-1.8.0-openjdk-devel java-1.8.0-openjdk-headless java-11-openjdk java-11-openjdk-devel java-11-openjdk-headless	Medium	Medium	Moderate
CVE-2024-21217	191	java-1.8.0-openjdk java-1.8.0-openjdk-devel java-1.8.0-openjdk-headless java-11-openjdk java-11-openjdk-devel java-11-openjdk-headless	Medium	Medium	Moderate
CVE-2024-21210	191	java-1.8.0-openjdk java-1.8.0-openjdk-devel java-1.8.0-openjdk-headless java-11-openjdk java-11-openjdk-devel java-11-openjdk-headless	Medium	Medium	Moderate
CVE-2024-21208	191	java-1.8.0-openjdk java-1.8.0-openjdk-devel java-1.8.0-openjdk-headless java-11-openjdk java-11-openjdk-devel java-11-openjdk-headless	Medium	Medium	Moderate
CVE-2024-12747	100	rsync	Medium	Medium	Moderate
CVE-2024-12243	74	gnutls	Medium	Medium	Moderate
CVE-2024-12133	74	libtasn1	Medium	Medium	Moderate
CVE-2024-12088	100	rsync	Medium	Medium	Moderate
CVE-2024-12087	100	rsync	Medium	Medium	Moderate
CVE-2024-12086	100	rsync	Medium	Medium	Moderate
CVE-2024-11168	163	platform-python python3-libs	Medium	Medium	Moderate
CVE-2024-10524	156	wget	Medium	Medium	Moderate
CVE-2024-10041	189	pam	Medium	Medium	Moderate
CVE-2024-9287	184	platform-python python3-libs	Medium	Medium	Moderate
CVE-2024-8508	203	python3-unbound unbound-libs	Medium	Medium	Moderate
CVE-2024-8184	192	jetty-server org.eclipse.jetty:jetty-server	Medium	Medium	Moderate
CVE-2024-8176	42	expat	Medium	Medium	Moderate
CVE-2024-8088	245	python36	Medium	Medium	Moderate
CVE-2024-7006	280	libtiff	Medium	Medium	Moderate
CVE-2024-6923	267	platform-python python3-libs	Medium	Medium	Moderate
CVE-2024-6763	192	jetty-http org.eclipse.jetty:jetty-http	Medium	Medium	Low
CVE-2024-6655	314	gtk-update-icon-cache gtk2 gtk3	Medium	Medium	Moderate
CVE-2024-6602	290	nss nss-softokn nss-softokn-freebl nss-sysinit nss-util	Medium	Medium	Moderate
CVE-2024-6232	233	platform-python python3-libs	Medium	Medium	Moderate
CVE-2024-2398	394	curl libcurl	Medium	Medium	Moderate
CVE-2023-52355	539	libtiff	Medium	Medium	Moderate
CVE-2023-51767	488	openssh openssh-clients	Medium	Medium	Moderate	Removable
CVE-2023-48795	494	golang.org/x/crypto	Medium	Medium	Moderate
CVE-2023-48161	520	java-1.8.0-openjdk java-1.8.0-openjdk-devel java-1.8.0-openjdk-headless java-11-openjdk java-11-openjdk-devel java-11-openjdk-headless	Medium	Medium	Moderate
CVE-2023-45290	416	stdlib	Medium	Medium	Moderate
CVE-2023-45289	416	stdlib	Medium	Medium	Moderate
CVE-2023-45284	532	stdlib	Medium
CVE-2023-44487	563	golang.org/x/net google.golang.org/grpc stdlib	Medium	High	Important
CVE-2023-41175	644	libtiff	Medium	Medium	Moderate
CVE-2023-40745	644	libtiff	Medium	Medium	Moderate
CVE-2023-40403	576	libxslt	Medium	Medium	Moderate
CVE-2023-39326	506	stdlib	Medium	Medium	Moderate
CVE-2023-39322	597	git-lfs	Medium	Medium	Moderate
CVE-2023-39321	597	git-lfs	Medium	Medium	Moderate
CVE-2023-39319	597	stdlib	Medium	Medium	Moderate
CVE-2023-39318	597	stdlib	Medium	Medium	Moderate
CVE-2023-30775	739	libtiff	Medium	Medium	Moderate
CVE-2023-30774	739	libtiff	Medium	Medium	Moderate
CVE-2023-30086	716	libtiff	Medium	Medium	Moderate
CVE-2023-28842	752	github.com/docker/docker	Medium	Medium	Moderate
CVE-2023-28841	752	github.com/docker/docker	Medium	Medium	Moderate
CVE-2023-28642	758	github.com/opencontainers/runc	Medium	Medium	Moderate
CVE-2023-26966	800	libtiff	Medium	Medium	Moderate
CVE-2023-26965	681	libtiff	Medium	Medium	Moderate
CVE-2023-25435	819	libtiff	Medium	Medium	Moderate
CVE-2023-25434	681	libtiff	Medium	Medium	Moderate
CVE-2023-25173	800	github.com/containerd/containerd	Medium	Medium	Moderate
CVE-2023-25153	800	github.com/containerd/containerd	Medium	Medium	Moderate
CVE-2023-7207	477	cpio	Medium	Medium	Moderate
CVE-2023-6277	540	libtiff	Medium	Medium	Moderate
CVE-2023-5455	470	krb5-libs	Medium	Medium	Moderate
CVE-2023-4504	582	cups-libs	Medium	Medium	Moderate
CVE-2023-3978	632	golang.org/x/net	Medium	Medium	Moderate
CVE-2023-3618	802	libtiff	Medium	Medium	Moderate
CVE-2023-3576	780	libtiff	Medium	Medium	Moderate
CVE-2023-3316	676	libtiff	Medium	Medium	Moderate
CVE-2023-3164	753	libtiff	Medium	Medium	Moderate
CVE-2023-0799	803	libtiff	Medium	Medium	Moderate
CVE-2023-0798	803	libtiff	Medium	Medium	Moderate
CVE-2023-0797	803	libtiff	Medium	Medium	Moderate
CVE-2023-0796	803	libtiff	Medium	Medium	Moderate
CVE-2023-0795	803	libtiff	Medium	Medium	Moderate
CVE-2023-0466	759	openssl openssl-libs	Medium	Medium	Moderate
CVE-2022-49043	89	libxml2 python3-libxml2	Medium	Medium	Moderate
CVE-2022-48338	794	emacs-filesystem	Medium	Medium	Moderate	Ignorable
CVE-2022-40090	977	libtiff	Medium	Medium	Moderate
CVE-2022-36109	953	github.com/docker/docker	Medium	Medium	Low
CVE-2022-31030	1050	github.com/containerd/containerd	Medium	Medium
CVE-2022-29162	1078	github.com/opencontainers/runc	Medium	Medium	Low
CVE-2022-24769	1129	github.com/docker/docker	Medium	Medium	Moderate
CVE-2022-23990	1185	expat	Medium	Medium	Moderate
CVE-2022-23471	869	github.com/containerd/containerd	Medium	Medium
CVE-2022-3599	1155	libtiff	Medium	Medium	Moderate
CVE-2022-3598	1047	libtiff	Medium	Medium	Moderate
CVE-2022-3570	1156	libtiff	Medium	Medium	Moderate
CVE-2022-3554	921	libX11 libX11-common	Medium	Medium	Moderate	Ignorable
CVE-2022-2963	1010	jasper-libs	Medium	Medium	Moderate
CVE-2021-45941	1210	libbpf	Medium	Medium	Moderate
CVE-2021-45940	1210	libbpf	Medium	Low	Low
CVE-2021-43784	1236	github.com/opencontainers/runc	Medium	Medium	Low
CVE-2021-41103	1299	github.com/containerd/containerd	Medium	Medium	Moderate
CVE-2021-41091	1299	github.com/docker/docker	Medium	Medium	Moderate
CVE-2021-36217	1388	avahi-libs	Medium		Moderate
CVE-2021-33294	647	elfutils-debuginfod-client elfutils-default-yama-scope elfutils-libelf elfutils-libs	Medium	Medium	Moderate
CVE-2021-32760	1376	github.com/containerd/containerd	Medium	Medium	Moderate
CVE-2021-31879	2030	wget	Medium	Medium	Moderate
CVE-2021-3733	1354	python36	Medium	Medium	Moderate
CVE-2021-3467	1515	jasper-libs	Medium	Medium	Moderate
CVE-2021-3443	1505	jasper-libs	Medium	Medium	Moderate
CVE-2020-36843	42	eddsa net.i2p.crypto:eddsa	Medium	Medium
CVE-2020-26154	1744	libproxy	Medium	Medium	Moderate
CVE-2020-25219	1689	libproxy	Medium	Medium	Moderate
CVE-2020-13790	1796	libjpeg-turbo	Medium	Medium	Moderate
CVE-2020-13645	1817	glib-networking	Medium	Medium	Moderate
CVE-2020-11023	1822	libgcc libgomp libstdc++	Medium	Medium	Moderate
CVE-2019-12900	160	bzip2 bzip2-libs	Medium	Medium	Moderate
CVE-2019-8905	2258	file file-libs	Medium	Medium	Moderate
CVE-2019-6462	2296	cairo cairo-gobject	Medium	Medium	Moderate
CVE-2019-6461	2296	cairo cairo-gobject	Medium	Medium	Moderate
CVE-2019-6128	2303	libtiff	Medium	Medium	Moderate
CVE-2019-6110	2352	openssh openssh-clients	Medium	Medium	Moderate	Removable
CVE-2019-2201	2121	libjpeg-turbo	Medium	Medium	Moderate
CVE-2018-1000021	2666	git git-core git-core-doc perl-Git	Medium	Medium	Moderate
CVE-2018-20839	2170	systemd systemd-libs systemd-pam systemd-udev	Medium	Medium	Moderate
CVE-2018-19217	2356	ncurses ncurses-base ncurses-libs	Medium	Medium	Moderate
CVE-2018-18064	2391	cairo cairo-gobject	Medium	Medium	Moderate
CVE-2018-16435	2447	lcms2	Medium	Medium	Moderate
CVE-2018-16335	2453	libtiff	Medium	Medium	Moderate
CVE-2018-15919	2432	openssh openssh-clients	Medium	Medium	Moderate	Removable
CVE-2018-10801	2545	libtiff	Medium	Medium	Moderate
CVE-2018-9252	2580	jasper-libs	Medium	Medium	Moderate
CVE-2018-9055	2587	jasper-libs	Medium	Medium	Moderate
CVE-2017-17095	2704	libtiff	Medium	Medium	Moderate
CVE-2017-5505	3078	jasper-libs	Medium	Medium	Moderate
CVE-2017-5504	3078	jasper-libs	Medium	Medium	Moderate
CVE-2017-5503	3078	jasper-libs	Medium	Medium	Moderate
CVE-2005-2541	7204	tar	Medium	Medium	Moderate	Ignorable
GHSA-vp35-85q5-9f25	896	github.com/docker/docker	Low	Low
GHSA-c9cp-9c75-9v8c	345	github.com/containerd/containerd	Low	Low
GHSA-77vh-xpmg-72qh	1253	github.com/opencontainers/image-spec	Low	Low
GHSA-5j5w-g665-5m35	1253	github.com/containerd/containerd	Low	Low
CVE-2025-32415	8	libxml2 python3-libxml2	Low	Low	Low
CVE-2025-27113	66	libxml2 python3-libxml2	Low	Low	Low
CVE-2025-3360	18	glib2	Low	Low	Low
CVE-2025-3198	21	gdb-gdbserver	Low	Low	Low
CVE-2025-1632	59	libarchive	Low	Low	Low
CVE-2025-1153	73	gdb-gdbserver	Low	Low	Low
CVE-2025-1152	73	gdb-gdbserver	Low	Low	Low
CVE-2025-1151	73	gdb-gdbserver	Low	Low	Low
CVE-2025-1150	73	gdb-gdbserver	Low	Low	Low
CVE-2025-0725	78	curl libcurl	Low	Low	Low
CVE-2024-57360	94	gdb-gdbserver	Low	Low	Low
CVE-2024-56433	120	shadow-utils	Low	Low	Low
CVE-2024-52006	100	git git-core git-core-doc perl-Git	Low	Low	Low
CVE-2024-51744	171	github.com/golang-jwt/jwt/v4	Low	Low	Low
CVE-2024-50349	100	git git-core git-core-doc perl-Git	Low	Low	Low
CVE-2024-47175	210	cups-libs	Low	High	Important
CVE-2024-43168	261	python3-unbound unbound-libs	Low	Low	Low
CVE-2024-43167	261	python3-unbound unbound-libs	Low	Low	Low
CVE-2024-41996	241	openssl openssl-libs	Low	Low	Low
CVE-2024-34459	352	libxml2 python3-libxml2	Low	Low	Low
CVE-2024-33655	351	python3-unbound unbound-libs	Low	Low	Low
CVE-2024-25260	430	elfutils-debuginfod-client elfutils-default-yama-scope elfutils-libelf elfutils-libs	Low	Low	Low
CVE-2024-7531	262	nss nss-softokn nss-softokn-freebl nss-sysinit nss-util	Low	Low	Low
CVE-2024-5535	302	openssl openssl-libs	Low	Low	Low
CVE-2024-4741	332	openssl openssl-libs	Low	Low	Low
CVE-2024-4032	312	platform-python python3-libs	Low	Low	Low
CVE-2024-2511	382	openssl openssl-libs	Low	Low	Low
CVE-2024-0727	459	openssl openssl-libs	Low	Low	Low
CVE-2024-0232	561	sqlite-libs	Low	Low	Low
CVE-2023-51257	467	jasper-libs	Low	Low	Low
CVE-2023-50495	500	ncurses ncurses-base ncurses-libs	Low	Low	Low
CVE-2023-45918	455	ncurses ncurses-base ncurses-libs	Low	Low	Low
CVE-2023-45322	611	libxml2 python3-libxml2	Low	Low	Low
CVE-2023-39804	501	tar	Low	Low	Low
CVE-2023-37920	640	ca-certificates	Low	Low	Low
CVE-2023-36191	672	sqlite-libs	Low	Low	Low
CVE-2023-32665	863	glib2	Low	Low	Low
CVE-2023-32636	863	glib2	Low	Low	Low
CVE-2023-32611	863	glib2	Low	Low	Low
CVE-2023-29499	863	glib2	Low	Low	Low
CVE-2023-27534	767	curl libcurl	Low	Low	Low
CVE-2023-25809	758	github.com/opencontainers/runc	Low	Low	Moderate
CVE-2023-24056	825	libpkgconf pkgconf pkgconf-m4 pkgconf-pkg-config	Low	Low	Low
CVE-2023-7216	445	cpio	Low	Low	Low
CVE-2023-2650	696	openssl openssl-libs	Low	Medium	Moderate
CVE-2023-1916	769	libtiff	Low	Low	Low
CVE-2023-0465	759	openssl openssl-libs	Low	Low	Low
CVE-2023-0464	765	openssl openssl-libs	Low	Low	Low
CVE-2022-47011	1042	gdb-gdbserver	Low	Low	Low
CVE-2022-47010	1042	gdb-gdbserver	Low	Low	Low
CVE-2022-47007	1044	gdb-gdbserver	Low	Low	Low
CVE-2022-40755	951	jasper-libs	Low	Low	Low
CVE-2022-27943	1126	libgcc libgomp libstdc++	Low	Low	Low
CVE-2022-3857	903	java-1.8.0-openjdk java-1.8.0-openjdk-devel java-1.8.0-openjdk-headless java-11-openjdk java-11-openjdk-devel java-11-openjdk-headless libpng	Low	Low	Low
CVE-2022-3606	930	libbpf	Low	Low	Low
CVE-2022-3555	921	libX11 libX11-common	Low	Low	Low	Ignorable
CVE-2022-1354	1109	libtiff	Low	Low	Low
CVE-2022-1056	1151	libtiff	Low	Low	Low
CVE-2022-0530	1180	unzip	Low	Low	Low
CVE-2022-0529	1187	unzip	Low	Low	Low
CVE-2021-41089	1299	github.com/docker/docker	Low	Low	Moderate
CVE-2021-39537	1725	ncurses ncurses-base ncurses-libs	Low	Low	Low
CVE-2021-25317	1457	cups-libs	Low	Low	Low
CVE-2021-20193	1559	tar	Low	Medium	Moderate
CVE-2021-4217	1197	unzip	Low	Low	Low
CVE-2021-4209	1220	gnutls	Low	Low	Low
CVE-2021-3997	1201	systemd systemd-libs systemd-pam systemd-udev	Low	Medium	Moderate
CVE-2021-3737	1355	python36	Low	Low	Low
CVE-2020-35538	1754	libjpeg-turbo	Low	Low	Low
CVE-2020-35512	1760	dbus dbus-common dbus-daemon dbus-libs dbus-tools	Low	Low	Low
CVE-2020-21674	1945	libarchive	Low	Medium	Moderate
CVE-2020-19190	2184	ncurses ncurses-base ncurses-libs	Low	Low	Low
CVE-2020-19189	2184	ncurses ncurses-base ncurses-libs	Low	Low	Low
CVE-2020-19188	2184	ncurses ncurses-base ncurses-libs	Low	Low	Low
CVE-2020-19187	2184	ncurses ncurses-base ncurses-libs	Low	Low	Low
CVE-2020-19186	2184	ncurses ncurses-base ncurses-libs	Low	Low	Low
CVE-2020-19185	2184	ncurses ncurses-base ncurses-libs	Low	Low	Low
CVE-2020-18768	2228	libtiff	Low	Low	Low
CVE-2020-12413	1689	nss nss-softokn nss-softokn-freebl nss-sysinit nss-util	Low	Low	Low
CVE-2019-19244	1981	sqlite-libs	Low	Low	Low
CVE-2019-16866	2031	python3-unbound unbound-libs	Low	Low	Low
CVE-2019-14250	2086	libgcc libgomp libstdc++	Low	Low	Low
CVE-2019-13118	2126	libxslt	Low	Low	Low
CVE-2019-13117	2126	libxslt	Low	Low	Low
CVE-2019-9937	2230	sqlite-libs	Low	Low	Low
CVE-2019-9936	2230	sqlite-libs	Low	Low	Low
CVE-2019-9923	2305	tar	Low	Low	Low
CVE-2019-9674	2237	platform-python python3-libs python36	Low	Low	Low
CVE-2019-8906	2304	file file-libs	Low	Low	Low
CVE-2019-7317	2282	libpng	Low	Low	Low
CVE-2018-1000880	2348	libarchive	Low	Low	Low
CVE-2018-1000879	2348	libarchive	Low	Low	Low
CVE-2018-1000654	2448	libtasn1	Low	Low	Low
CVE-2018-20657	2320	libgcc libgomp libstdc++	Low	Low	Low
CVE-2018-20622	2307	jasper-libs	Low	Low	Low
CVE-2018-20570	2310	jasper-libs	Low	Low	Low
CVE-2018-20225	1823	platform-python-pip python3-pip python3-pip-wheel	Low	Low	Low
CVE-2018-19876	2355	cairo cairo-gobject	Low	Low	Low
CVE-2018-19543	2478	jasper-libs	Low	Low	Low
CVE-2018-19542	2478	jasper-libs	Low	Low	Low
CVE-2018-19541	2478	jasper-libs	Low	Low	Low
CVE-2018-19540	2478	jasper-libs	Low	Low	Low
CVE-2018-19539	2478	jasper-libs	Low	Low	Low
CVE-2018-19211	2371	ncurses ncurses-base ncurses-libs	Low	Low	Low
CVE-2018-19210	2371	libtiff	Low	Low	Low
CVE-2018-19139	2359	jasper-libs	Low	Low	Low
CVE-2018-18873	2368	jasper-libs	Low	Low	Low
CVE-2018-17101	2413	libtiff	Low	Low	Low
CVE-2018-10779	2545	libtiff	Low	Low	Low
CVE-2018-5360	2660	libtiff	Low	Low	Low
CVE-2018-1121	2534	procps-ng	Low	Low	Low
CVE-2017-13745	2800	jasper-libs	Low	Low	Low
CVE-2017-9782	2872	jasper-libs	Low	Low	Low
CVE-2017-6519	3678	avahi-libs	Low	Low	Low
CVE-2017-5499	3101	jasper-libs	Low	Low	Low
CVE-2016-20012	3365	openssh openssh-clients	Low	Low	Low	Removable
CVE-2016-4074	3288	jq	Low	Low	Low
CVE-2024-34447	357	bcprov-jdk18on		Medium	Moderate
CVE-2024-29857	315	bcprov-jdk18on		Medium	Moderate
CVE-2024-30172	351	bcprov-jdk18on		Medium	Moderate
CVE-2024-30171	372	bcprov-jdk18on		Medium	Moderate
CVE-2024-28152	415	cloudbees-bitbucket-branch-source		Medium	Moderate
CVE-2024-39460	303	cloudbees-bitbucket-branch-source		Medium	Low
CVE-2024-29133	401	commons-configuration2		Medium	Low
CVE-2024-29131	401	commons-configuration2		Medium	Low
CVE-2021-37533	800	commons-net		Medium	Moderate
CVE-2024-47805	204	credentials		Medium
CVE-2024-11053	135	curl libcurl		Low	Low
CVE-2024-7264	268	curl libcurl		Low	Low
CVE-2022-0235	1197	dnf-plugin-subscription-manager python3-cloud-what python3-subscription-manager-rhsm python3-syspurpose subscription-manager		Medium	Moderate	False Positive
CVE-2023-2004	893	freetype java-11-openjdk java-11-openjdk-devel java-11-openjdk-headless		Negligible		Ignorable
CVE-2023-4156	676	gawk		Low	Low
CVE-2023-2222	865	gdb-gdbserver		Negligible		Ignorable
CVE-2022-41723	797	git-lfs		Medium	Moderate
CVE-2022-41724	800	git-lfs		Medium	Moderate
CVE-2022-41725	800	git-lfs		Medium	Moderate
CVE-2023-24534	752	git-lfs		Medium	Moderate
CVE-2023-24536	752	git-lfs		Medium	Moderate
CVE-2024-24788	352	git-lfs		Medium	Moderate
CVE-2024-9355	206	git-lfs		Medium	Moderate
CVE-2024-34146	358	git-server		Medium	Moderate
GHSA-mq39-4gv4-mvpx	400	github.com/docker/docker		Medium
CVE-2022-3219	953	gnupg2		Low	Low
CVE-2025-30258	37	gnupg2		Low	Low
CVE-2022-41404	926	ini4j		High	Moderate
CVE-2023-51775	421	jose4j		Medium	Moderate
CVE-2024-57699	79	json-smart		High	Important
CVE-2019-12904	2110	libgcrypt		Medium	Moderate
CVE-2024-2236	415	libgcrypt		Medium	Moderate
CVE-2022-4899	1013	libzstd		Medium	Moderate
CVE-2021-24032	1534	libzstd		Low	Low
CVE-2019-17543	2109	lz4-libs		Medium	Moderate
CVE-2019-19246	2082	oniguruma		Medium	Moderate
CVE-2024-13176	94	openssl openssl-libs		Low	Low
CVE-2022-41409	647	pcre2		Low	Low
CVE-2024-39459	303	plain-credentials		Medium	Moderate
CVE-2024-0397	312	platform-python python3-libs python36		Low	Low
CVE-2024-7592	249	platform-python python3-libs python36		Low	Low
CVE-2025-1795	55	platform-python python3-libs python36		Low	Low
CVE-2022-33070	1037	protobuf-c		Low	Low
CVE-2024-52549	162	script-security		Medium	Moderate
CVE-2024-54661	142	socat		Medium	Moderate
CVE-2025-3277	10	sqlite-libs		High	Important
CVE-2024-41909	256	sshd-common		High	Moderate
CVE-2022-45047	891	sshd-common		Critical	Important	False Positive
CVE-2023-35887	655	sshd-common		Medium	Moderate
CVE-2023-24531	?	stdlib		Critical
CVE-2023-39323	568	stdlib		High	Moderate
CVE-2023-45285	506	stdlib		High	Moderate
CVE-2024-24787	?	stdlib		Medium
CVE-2024-39458	303	structs		Low	Moderate
CVE-2025-29768	42	vim-minimal		Medium	Moderate
CVE-2018-20786	2314	vim-minimal		Low	Low
CVE-2020-20703	675	vim-minimal		Low	Low
CVE-2021-3236	1562	vim-minimal		Low	Low
CVE-2021-3927	1277	vim-minimal		Low	Low
CVE-2021-3974	1253	vim-minimal		Low	Low
CVE-2021-4166	1217	vim-minimal		Low	Low
CVE-2022-0351	1188	vim-minimal		Low	Low
CVE-2022-1619	1083	vim-minimal		Low	Low
CVE-2022-1720	1078	vim-minimal		Low	Low
CVE-2022-2124	1041	vim-minimal		Low	Low
CVE-2022-2125	1041	vim-minimal		Low	Low
CVE-2022-2126	1041	vim-minimal		Low	Low
CVE-2022-2129	1041	vim-minimal		Low	Low
CVE-2022-2175	1037	vim-minimal		Low	Low
CVE-2022-2182	1037	vim-minimal		Low	Low
CVE-2022-2183	1037	vim-minimal		Low	Low
CVE-2022-2206	1034	vim-minimal		Low	Low
CVE-2022-2207	1033	vim-minimal		Low	Low
CVE-2022-2208	1033	vim-minimal		Low	Low
CVE-2022-2210	1033	vim-minimal		Low	Low
CVE-2022-2284	1028	vim-minimal		Low	Low
CVE-2022-2285	1028	vim-minimal		Low	Low
CVE-2022-2286	1028	vim-minimal		Low	Low
CVE-2022-2287	1027	vim-minimal		Low	Low
CVE-2022-2343	1024	vim-minimal		Low	Low
CVE-2022-2344	1024	vim-minimal		Low	Low
CVE-2022-2345	1025	vim-minimal		Low	Low
CVE-2022-2522	1005	vim-minimal		Low	Low
CVE-2022-2819	984	vim-minimal		Low	Low
CVE-2022-2845	982	vim-minimal		Low	Low
CVE-2022-2849	982	vim-minimal		Low	Low
CVE-2022-2923	977	vim-minimal		Low	Low
CVE-2022-2946	976	vim-minimal		Low	Low
CVE-2022-2980	974	vim-minimal		Low	Low
CVE-2022-3037	969	vim-minimal		Low	Low
CVE-2022-3153	960	vim-minimal		Low	Low
CVE-2022-3234	950	vim-minimal		Low	Low
CVE-2022-3235	950	vim-minimal		Low	Low
CVE-2022-3256	946	vim-minimal		Low	Low
CVE-2022-3296	943	vim-minimal		Low	Low
CVE-2022-3352	939	vim-minimal		Low	Low
CVE-2022-3705	912	vim-minimal		Low	Low
CVE-2022-4292	875	vim-minimal		Low	Low
CVE-2022-4293	875	vim-minimal		Low	Low
CVE-2023-0049	842	vim-minimal		Low	Low
CVE-2023-0054	843	vim-minimal		Low	Low
CVE-2023-0288	834	vim-minimal		Low	Low
CVE-2023-0433	825	vim-minimal		Low	Low
CVE-2023-0512	816	vim-minimal		Low	Low
CVE-2023-1127	786	vim-minimal		Low	Low
CVE-2023-1170	783	vim-minimal		Low	Low
CVE-2023-1175	783	vim-minimal		Low	Low
CVE-2023-1264	780	vim-minimal		Low	Low
CVE-2023-2609	717	vim-minimal		Low	Low
CVE-2023-2610	716	vim-minimal		Low	Low
CVE-2023-46246	546	vim-minimal		Low	Low
CVE-2023-4733	599	vim-minimal		Low	Low
CVE-2023-4734	601	vim-minimal		Low	Low
CVE-2023-4735	601	vim-minimal		Low	Low
CVE-2023-4738	601	vim-minimal		Low	Low
CVE-2023-4750	599	vim-minimal		Low	Low
CVE-2023-4751	600	vim-minimal		Low	Low
CVE-2023-4752	599	vim-minimal		Low	Low
CVE-2023-4781	598	vim-minimal		Low	Low
CVE-2023-48231	526	vim-minimal		Low	Low
CVE-2023-48232	526	vim-minimal		Low	Low
CVE-2023-48233	526	vim-minimal		Low	Low
CVE-2023-48234	526	vim-minimal		Low	Low
CVE-2023-48235	526	vim-minimal		Low	Low
CVE-2023-48236	526	vim-minimal		Low	Low
CVE-2023-48237	526	vim-minimal		Low	Low
CVE-2023-48706	520	vim-minimal		Low	Low
CVE-2023-5344	571	vim-minimal		Low	Low
CVE-2023-5441	572	vim-minimal		Low	Low
CVE-2023-5535	563	vim-minimal		Low	Low
CVE-2024-22667	445	vim-minimal		Low	Low
CVE-2024-41965	266	vim-minimal		Low	Low
CVE-2024-43374	252	vim-minimal		Low	Low
CVE-2024-43802	241	vim-minimal		Low	Low
CVE-2024-45306	234	vim-minimal		Low	Low
CVE-2024-47814	199	vim-minimal		Low	Low
CVE-2025-1215	71	vim-minimal		Low	Low
CVE-2025-22134	101	vim-minimal		Low	Low
CVE-2025-24014	94	vim-minimal		Low	Low
CVE-2025-26603	65	vim-minimal		Low	Low
CVE-2024-52550	162	workflow-cps		High	Important

Security Advisory: CVE-2024-45337

Description:

Applications and libraries which misuse connection.serverAuthenticate (via callback field ServerConfig.PublicKeyCallback) may be susceptible to an authorization bypass. The documentation for ServerConfig.PublicKeyCallback says that "A call to this function does not guarantee that the key offered is in fact used to authenticate." Specifically, the SSH protocol allows clients to inquire about whether a public key is acceptable before proving control of the corresponding private key. PublicKeyCallback may be called with multiple keys, and the order in which the keys were provided cannot be used to infer which key the client successfully authenticated with, if any. Some applications, which store the key(s) passed to PublicKeyCallback (or derived information) and make security relevant determinations based on it once the connection is established, may make incorrect assumptions. For example, an attacker may send public keys A and B, and then authenticate with A. PublicKeyCallback would be called only twice, first with A and then with B. A vulnerable application may then make authorization decisions based on key B for which the attacker does not actually control the private key. Since this API is widely misused, as a partial mitigation golang.org/x/cry...@v0.31.0 enforces the property that, when successfully authenticating via public key, the last key passed to ServerConfig.PublicKeyCallback will be the key used to authenticate the connection. PublicKeyCallback will now be called multiple times with the same key, if necessary. Note that the client may still not control the last key passed to PublicKeyCallback if the connection is then authenticated with a different method, such as PasswordCallback, KeyboardInteractiveCallback, or NoClientAuth. Users should be using the Extensions field of the Permissions return value from the various authentication callbacks to record data associated with the authentication attempt instead of referencing external state. Once the connection is established the state corresponding to the successful authentication attempt can be retrieved via the ServerConn.Permissions field. Note that some third-party libraries misuse the Permissions type by sharing it across authentication attempts; users of third-party libraries should refer to the relevant projects for guidance.

Locations:

/usr/bin/oc
golang.org/x/crypto-v0.0.0-20220331220935-ae2d96664a29

References:

Security Advisory: CVE-2023-28840

Description:

Moby is an open source container framework developed by Docker Inc. that is distributed as Docker, Mirantis Container Runtime, and various other downstream projects/products. The Moby daemon component (`dockerd`), which is developed as moby/moby, is commonly referred to as *Docker*.
Swarm Mode, which is compiled in and delivered by default in dockerd and is thus present in most major Moby downstreams, is a simple, built-in container orchestrator that is implemented through a combination of SwarmKit and supporting network code.
The overlay network driver is a core feature of Swarm Mode, providing isolated virtual LANs that allow communication between containers and services across the cluster. This driver is an implementation/user of VXLAN, which encapsulates link-layer (Ethernet) frames in UDP datagrams that tag the frame with a VXLAN Network ID (VNI) that identifies the originating overlay network. In addition, the overlay network driver supports an optional, off-by-default encrypted mode, which is especially useful when VXLAN packets traverses an untrusted network between nodes.
Encrypted overlay networks function by encapsulating the VXLAN datagrams through the use of the IPsec Encapsulating Security Payload protocol in Transport mode. By deploying IPSec encapsulation, encrypted overlay networks gain the additional properties of source authentication through cryptographic proof, data integrity through check-summing, and confidentiality through encryption.
When setting an endpoint up on an encrypted overlay network, Moby installs three iptables (Linux kernel firewall) rules that enforce both incoming and outgoing IPSec. These rules rely on the u32 iptables extension provided by the xt_u32 kernel module to directly filter on a VXLAN packet's VNI field, so that IPSec guarantees can be enforced on encrypted overlay networks without interfering with other overlay networks or other users of VXLAN.
Two iptables rules serve to filter incoming VXLAN datagrams with a VNI that corresponds to an encrypted network and discards unencrypted datagrams. The rules are appended to the end of the INPUT filter chain, following any rules that have been previously set by the system administrator. Administrator-set rules take precedence over the rules Moby sets to discard unencrypted VXLAN datagrams, which can potentially admit unencrypted datagrams that should have been discarded.
The injection of arbitrary Ethernet frames can enable a Denial of Service attack. A sophisticated attacker may be able to establish a UDP or TCP connection by way of the container’s outbound gateway that would otherwise be blocked by a stateful firewall, or carry out other escalations beyond simple injection by smuggling packets into the overlay network.
Patches are available in Moby releases 23.0.3 and 20.10.24. As Mirantis Container Runtime's 20.10 releases are numbered differently, users of that platform should update to 20.10.16.
Some workarounds are available. Close the VXLAN port (by default, UDP port 4789) to incoming traffic at the Internet boundary to prevent all VXLAN packet injection, and/or ensure that the `xt_u32` kernel module is available on all nodes of the Swarm cluster.

Locations:

/usr/bin/oc
github.com/docker/docker-v20.10.3+incompatible

References:

Security Advisory: GHSA-jq35-85cj-fj4p

Description:

/sys/devices/virtual/powercap accessible by default to containers

Intel's RAPL (Running Average Power Limit) feature, introduced by the Sandy Bridge microarchitecture, provides software insights into hardware energy consumption. To facilitate this, Intel introduced the powercap framework in Linux kernel 3.13, which reads values via relevant MSRs (model specific registers) and provides unprivileged userspace access via sysfs. As RAPL is an interface to access a hardware feature, it is only available when running on bare metal with the module compiled into the kernel.

By 2019, it was realized that in some cases unprivileged access to RAPL readings could be exploited as a power-based side-channel against security features including AES-NI (potentially inside a SGX enclave) and KASLR (kernel address space layout randomization). Also known as the PLATYPUS attack, Intel assigned CVE-2020-8694 and CVE-2020-8695, and AMD assigned CVE-2020-12912.

Several mitigations were applied; Intel reduced the sampling resolution via a microcode update, and the Linux kernel prevents access by non-root users since 5.10. However, this kernel-based mitigation does not apply to many container-based scenarios: * Unless using user namespaces, root inside a container has the same level of privilege as root outside the container, but with a slightly more narrow view of the system * sysfs is mounted inside containers read-only; however only read access is needed to carry out this attack on an unpatched CPU

While this is not a direct vulnerability in container runtimes, defense in depth and safe defaults are valuable and preferred, especially as this poses a risk to multi-tenant container environments running directly on affected hardware. This is provided by masking /sys/devices/virtual/powercap in the default mount configuration, and adding an additional set of rules to deny it in the default AppArmor profile.

While sysfs is not the only way to read from the RAPL subsystem, other ways of accessing it require additional capabilities such as CAP_SYS_RAWIO which is not available to containers by default, or perf paranoia level less than 1, which is a non-default kernel tunable.

References

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-8694
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-8695
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-12912
https://platypusattack.com/
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=949dd0104c496fa7c14991a23c03c62e44637e71
https://web.eece.maine.edu/~vweaver/projects/rapl/

Locations:

/usr/bin/oc
github.com/docker/docker-v20.10.3+incompatible

References:

Security Advisory: GHSA-7ww5-4wqc-m92c

Description:

containerd allows RAPL to be accessible to a container

/sys/devices/virtual/powercap accessible by default to containers

While this is not a direct vulnerability in container runtimes, defense in depth and safe defaults are valuable and preferred, especially as this poses a risk to multi-tenant container environments. This is provided by masking /sys/devices/virtual/powercap in the default mount configuration, and adding an additional set of rules to deny it in the default AppArmor profile.

References

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-8694
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-8695
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-12912
https://platypusattack.com/
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=949dd0104c496fa7c14991a23c03c62e44637e71
https://web.eece.maine.edu/~vweaver/projects/rapl/

Locations:

/usr/bin/oc
github.com/containerd/containerd-v1.5.1

References:

Security Advisory: CVE-2025-30698

Description:

Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: 2D). Supported versions that are affected are Oracle Java SE: 8u441, 8u441-perf, 11.0.26, 17.0.14, 21.0.6, 24; Oracle GraalVM for JDK: 17.0.14, 21.0.6, 24; Oracle GraalVM Enterprise Edition: 20.3.17 and 21.3.13. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data as well as unauthorized read access to a subset of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data and unauthorized ability to cause a partial denial of service (partial DOS) of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability does not apply to Java deployments, typically in servers, that load and run only trusted code (e.g., code installed by an administrator). CVSS 3.1 Base Score 5.6 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:L).

Locations:

java-1.8.0-openjdk-1:1.8.0.422.b05-2.el8
java-1.8.0-openjdk-devel-1:1.8.0.422.b05-2.el8
java-1.8.0-openjdk-headless-1:1.8.0.422.b05-2.el8
java-11-openjdk-1:11.0.24.0.8-3.el8
java-11-openjdk-devel-1:11.0.24.0.8-3.el8
java-11-openjdk-headless-1:11.0.24.0.8-3.el8

References:

Security Advisory: CVE-2025-21587

Description:

Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: JSSE). Supported versions that are affected are Oracle Java SE:8u441, 8u441-perf, 11.0.26, 17.0.14, 21.0.6, 24; Oracle GraalVM for JDK:17.0.14, 21.0.6, 24; Oracle GraalVM Enterprise Edition:20.3.17 and 21.3.13. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition. Successful attacks of this vulnerability can result in unauthorized creation, deletion or modification access to critical data or all Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data as well as unauthorized access to critical data or complete access to all Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 7.4 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N).

Locations:

java-1.8.0-openjdk-1:1.8.0.422.b05-2.el8
java-1.8.0-openjdk-devel-1:1.8.0.422.b05-2.el8
java-1.8.0-openjdk-headless-1:1.8.0.422.b05-2.el8
java-11-openjdk-1:11.0.24.0.8-3.el8
java-11-openjdk-devel-1:11.0.24.0.8-3.el8
java-11-openjdk-headless-1:11.0.24.0.8-3.el8

References:

Security Advisory: CVE-2024-45310

Description:

runc is a CLI tool for spawning and running containers according to the OCI specification. runc 1.1.13 and earlier, as well as 1.2.0-rc2 and earlier, can be tricked into creating empty files or directories in arbitrary locations in the host filesystem by sharing a volume between two containers and exploiting a race with `os.MkdirAll`. While this could be used to create empty files, existing files would not be truncated. An attacker must have the ability to start containers using some kind of custom volume configuration. Containers using user namespaces are still affected, but the scope of places an attacker can create inodes can be significantly reduced. Sufficiently strict LSM policies (SELinux/Apparmor) can also in principle block this attack -- we suspect the industry standard SELinux policy may restrict this attack's scope but the exact scope of protection hasn't been analysed. This is exploitable using runc directly as well as through Docker and Kubernetes. The issue is fixed in runc v1.1.14 and v1.2.0-rc3.
Some workarounds are available. Using user namespaces restricts this attack fairly significantly such that the attacker can only create inodes in directories that the remapped root user/group has write access to. Unless the root user is remapped to an actual
user on the host (such as with rootless containers that don't use `/etc/sub[ug]id`), this in practice means that an attacker would only be able to create inodes in world-writable directories. A strict enough SELinux or AppArmor policy could in principle also restrict the scope if a specific label is applied to the runc runtime, though neither the extent to which the standard existing policies block this attack nor what exact policies are needed to sufficiently restrict this attack have been thoroughly tested.

Locations:

/usr/bin/oc
github.com/opencontainers/runc-v1.0.1

References:

Security Advisory: CVE-2024-29018

Description:

Moby is an open source container framework that is a key component of Docker Engine, Docker Desktop, and other distributions of container tooling or runtimes. Moby's networking implementation allows for many networks, each with their own IP address range and gateway, to be defined. This feature is frequently referred to as custom networks, as each network can have a different driver, set of parameters and thus behaviors. When creating a network, the `--internal` flag is used to designate a network as _internal_. The `internal` attribute in a docker-compose.yml file may also be used to mark a network _internal_, and other API clients may specify the `internal` parameter as well.
When containers with networking are created, they are assigned unique network interfaces and IP addresses. The host serves as a router for non-internal networks, with a gateway IP that provides SNAT/DNAT to/from container IPs.
Containers on an internal network may communicate between each other, but are precluded from communicating with any networks the host has access to (LAN or WAN) as no default route is configured, and firewall rules are set up to drop all outgoing traffic. Communication with the gateway IP address (and thus appropriately configured host services) is possible, and the host may communicate with any container IP directly.
In addition to configuring the Linux kernel's various networking features to enable container networking, `dockerd` directly provides some services to container networks. Principal among these is serving as a resolver, enabling service discovery, and resolution of names from an upstream resolver.
When a DNS request for a name that does not correspond to a container is received, the request is forwarded to the configured upstream resolver. This request is made from the container's network namespace: the level of access and routing of traffic is the same as if the request was made by the container itself.
As a consequence of this design, containers solely attached to an internal network will be unable to resolve names using the upstream resolver, as the container itself is unable to communicate with that nameserver. Only the names of containers also attached to the internal network are able to be resolved.
Many systems run a local forwarding DNS resolver. As the host and any containers have separate loopback devices, a consequence of the design described above is that containers are unable to resolve names from the host's configured resolver, as they cannot reach these addresses on the host loopback device. To bridge this gap, and to allow containers to properly resolve names even when a local forwarding resolver is used on a loopback address, `dockerd` detects this scenario and instead forward DNS requests from the host namework namespace. The loopback resolver then forwards the requests to its configured upstream resolvers, as expected.
Because `dockerd` forwards DNS requests to the host loopback device, bypassing the container network namespace's normal routing semantics entirely, internal networks can unexpectedly forward DNS requests to an external nameserver. By registering a domain for which they control the authoritative nameservers, an attacker could arrange for a compromised container to exfiltrate data by encoding it in DNS queries that will eventually be answered by their nameservers.
Docker Desktop is not affected, as Docker Desktop always runs an internal resolver on a RFC 1918 address.
Moby releases 26.0.0, 25.0.4, and 23.0.11 are patched to prevent forwarding any DNS requests from internal networks. As a workaround, run containers intended to be solely attached to internal networks with a custom upstream address, which will force all upstream DNS queries to be resolved from the container's network namespace.

Locations:

github.com/docker/docker-v20.10.3+incompatible

References:

Security Advisory: CVE-2023-28842

Description:

Moby) is an open source container framework developed by Docker Inc. that is distributed as Docker, Mirantis Container Runtime, and various other downstream projects/products. The Moby daemon component (`dockerd`), which is developed as moby/moby is commonly referred to as *Docker*.
Swarm Mode, which is compiled in and delivered by default in `dockerd` and is thus present in most major Moby downstreams, is a simple, built-in container orchestrator that is implemented through a combination of SwarmKit and supporting network code.
The `overlay` network driver is a core feature of Swarm Mode, providing isolated virtual LANs that allow communication between containers and services across the cluster. This driver is an implementation/user of VXLAN, which encapsulates link-layer (Ethernet) frames in UDP datagrams that tag the frame with the VXLAN metadata, including a VXLAN Network ID (VNI) that identifies the originating overlay network. In addition, the overlay network driver supports an optional, off-by-default encrypted mode, which is especially useful when VXLAN packets traverses an untrusted network between nodes.
Encrypted overlay networks function by encapsulating the VXLAN datagrams through the use of the IPsec Encapsulating Security Payload protocol in Transport mode. By deploying IPSec encapsulation, encrypted overlay networks gain the additional properties of source authentication through cryptographic proof, data integrity through check-summing, and confidentiality through encryption.
When setting an endpoint up on an encrypted overlay network, Moby installs three iptables (Linux kernel firewall) rules that enforce both incoming and outgoing IPSec. These rules rely on the `u32` iptables extension provided by the `xt_u32` kernel module to directly filter on a VXLAN packet's VNI field, so that IPSec guarantees can be enforced on encrypted overlay networks without interfering with other overlay networks or other users of VXLAN.
The `overlay` driver dynamically and lazily defines the kernel configuration for the VXLAN network on each node as containers are attached and detached. Routes and encryption parameters are only defined for destination nodes that participate in the network. The iptables rules that prevent encrypted overlay networks from accepting unencrypted packets are not created until a peer is available with which to communicate.
Encrypted overlay networks silently accept cleartext VXLAN datagrams that are tagged with the VNI of an encrypted overlay network. As a result, it is possible to inject arbitrary Ethernet frames into the encrypted overlay network by encapsulating them in VXLAN datagrams. The implications of this can be quite dire, and GHSA-vwm3-crmr-xfxw should be referenced for a deeper exploration.
Patches are available in Moby releases 23.0.3, and 20.10.24. As Mirantis Container Runtime's 20.10 releases are numbered differently, users of that platform should update to 20.10.16.
Some workarounds are available. In multi-node clusters, deploy a global ‘pause’ container for each encrypted overlay network, on every node. For a single-node cluster, do not use overlay networks of any sort. Bridge networks provide the same connectivity on a single node and have no multi-node features. The Swarm ingress feature is implemented using an overlay network, but can be disabled by publishing ports in `host` mode instead of `ingress` mode (allowing the use of an external load balancer), and removing the `ingress` network. If encrypted overlay networks are in exclusive use, block UDP port 4789 from traffic that has not been validated by IPSec.

Locations:

/usr/bin/oc
github.com/docker/docker-v20.10.3+incompatible

References:

Security Advisory: CVE-2023-28841

Description:

Moby is an open source container framework developed by Docker Inc. that is distributed as Docker, Mirantis Container Runtime, and various other downstream projects/products. The Moby daemon component (`dockerd`), which is developed as moby/moby is commonly referred to as *Docker*.
Swarm Mode, which is compiled in and delivered by default in `dockerd` and is thus present in most major Moby downstreams, is a simple, built-in container orchestrator that is implemented through a combination of SwarmKit and supporting network code.
The `overlay` network driver is a core feature of Swarm Mode, providing isolated virtual LANs that allow communication between containers and services across the cluster. This driver is an implementation/user of VXLAN, which encapsulates link-layer (Ethernet) frames in UDP datagrams that tag the frame with the VXLAN metadata, including a VXLAN Network ID (VNI) that identifies the originating overlay network. In addition, the overlay network driver supports an optional, off-by-default encrypted mode, which is especially useful when VXLAN packets traverses an untrusted network between nodes.
Encrypted overlay networks function by encapsulating the VXLAN datagrams through the use of the IPsec Encapsulating Security Payload protocol in Transport mode. By deploying IPSec encapsulation, encrypted overlay networks gain the additional properties of source authentication through cryptographic proof, data integrity through check-summing, and confidentiality through encryption.
When setting an endpoint up on an encrypted overlay network, Moby installs three iptables (Linux kernel firewall) rules that enforce both incoming and outgoing IPSec. These rules rely on the `u32` iptables extension provided by the `xt_u32` kernel module to directly filter on a VXLAN packet's VNI field, so that IPSec guarantees can be enforced on encrypted overlay networks without interfering with other overlay networks or other users of VXLAN.
An iptables rule designates outgoing VXLAN datagrams with a VNI that corresponds to an encrypted overlay network for IPsec encapsulation.
Encrypted overlay networks on affected platforms silently transmit unencrypted data. As a result, `overlay` networks may appear to be functional, passing traffic as expected, but without any of the expected confidentiality or data integrity guarantees.
It is possible for an attacker sitting in a trusted position on the network to read all of the application traffic that is moving across the overlay network, resulting in unexpected secrets or user data disclosure. Thus, because many database protocols, internal APIs, etc. are not protected by a second layer of encryption, a user may use Swarm encrypted overlay networks to provide confidentiality, which due to this vulnerability this is no longer guaranteed.
Patches are available in Moby releases 23.0.3, and 20.10.24. As Mirantis Container Runtime's 20.10 releases are numbered differently, users of that platform should update to 20.10.16.
Some workarounds are available. Close the VXLAN port (by default, UDP port 4789) to outgoing traffic at the Internet boundary in order to prevent unintentionally leaking unencrypted traffic over the Internet, and/or ensure that the `xt_u32` kernel module is available on all nodes of the Swarm cluster.

Locations:

/usr/bin/oc
github.com/docker/docker-v20.10.3+incompatible

References:

Security Advisory: GHSA-vp35-85q5-9f25

Description:

Container build can leak any path on the host into the container

Description

Moby is the open source Linux container runtime and set of components used to build a variety of downstream container runtimes, including Docker CE, Mirantis Container Runtime (formerly Docker EE), and Docker Desktop. Moby allows for building container images using a set of build instructions (usually named and referred to as a "Dockerfile"), and a build context, which is not unlike the CWD in which the Dockerfile instructions are executed.

Containers may be built using a variety of tools and build backends available in the Moby ecosystem; in all cases, builds may not include files outside of the build context (such as using absolute or relative-parent paths). This is enforced through both checks in the build backends, and the containerization of the build process itself.

Versions of Git where CVE-2022-39253 is present and exploited by a malicious repository, when used in combination with Moby, are subject to an unexpected inclusion of arbitrary filesystem paths in the build context, without any visible warning to the user.

This issue was originally reported by Wenxiang Qian of Tencent Blade Team, and the root-cause analysis was performed by Cory Snider of Mirantis, with assistance from Bjorn Neergaard of the same. The issue was then reported to the Git project, and Taylor Blau led the process resolving the root issue in Git.

Impact

This vulnerability originates in Git, but can be used to violate assumptions that may have security implications for users of Moby and related components. Users may rely on the fact that a build context ensures that outside files cannot be referenced or incorporated using multiple enforcement mechanisms, or expect a warning if this does not hold true. A maliciously crafted Git repository exploiting CVE-2022-39253 can violate this assumption, and potentially include sensitive files that are subsequently uploaded to a container image repository, or disclosed by code inside the resulting container image.

As this issue cannot be triggered remotely, except by users who already have full control over the daemon through the API, and it requires exploiting a vulnerability in Git by convincing a user to build a maliciously crafted repository, the impact in Moby is considered low.

Patches

Moby 20.10.20, and Mirantis Container Runtime (formerly Docker Enterprise Edition) 20.10.14 will contain mitigations for CVE-2022-39253 when a Git clone is performed by Moby components (on either the daemon or API client side). However, as these mitigations only apply to certain scenarios (build of git+<protocol>://... URL contexts) and cannot protect against a malicious repository already on disk, users should update to a version of Git containing patches for CVE-2022-39253 on all their systems running both API clients and daemons.

Specifically, patches in Moby (including patches incorporated from BuildKit) protect against the following:

docker build with the legacy builder (e.g. DOCKER_BUILDKIT unset or set to 0) of a Git URL context. Note that depending on available API versions and the CLI version, the Git clone operation can take place on either the client or the daemon side. Both must be updated (or have Git updated) to fully protect this build method.
docker build with the BuildKit builder (e.g. DOCKER_BUILDKIT=1) of a Git URL context.
docker buildx build with BUILDKIT_CONTEXT_KEEP_GIT_DIR=1 of a Git URL context.

Patches in BuildKit incorporated into Docker Compose protect against CVE-2022-39253 during Compose-driven builds of Git URL contexts.

Patches in Moby and related projects such as BuildKit, the Docker CLI, and Docker Compose cannot fully protect against CVE-2022-39253, as it may be triggered by a malicious repository already on disk that a unpatched Git client has interacted with (specifically, commands that check out submodules such as git clone --recursive, git submodule update, etc. may have already triggered the Git vulnerability).

Workarounds

While this behavior is unexpected and undesirable, and has resulted in this security advisory, users should keep in mind that building a container entails arbitrary code execution. Users should not build a repository/build context they do not trust, as containerization cannot protect against all possible attacks.

When building with BuildKit (e.g. docker buildx build or docker build with DOCKER_BUILDKIT=1), this issue cannot be exploited unless --build-arg BUILDKIT_CONTEXT_KEEP_GIT_DIR=1 was also passed, as by default BuildKit will discard the .git directory of a Git URL context immediately after cloning and checking out the repository.

For more information

If you have any questions or comments about this advisory:

Open an issue
Email us at security@docker.com

Locations:

/usr/bin/oc
github.com/docker/docker-v20.10.3+incompatible

References:

Security Advisory: GHSA-c9cp-9c75-9v8c

Description:

containerd started with non-empty inheritable Linux process capabilities

Impact

A bug was found in containerd where containers were incorrectly started with non-empty inheritable Linux process capabilities, creating an atypical Linux environment and enabling programs with inheritable file capabilities to elevate those capabilities to the permitted set during execve(2). Normally, when executable programs have specified permitted file capabilities, otherwise unprivileged users and processes can execute those programs and gain the specified file capabilities up to the bounding set. Due to this bug, containers which included executable programs with inheritable file capabilities allowed otherwise unprivileged users and processes to additionally gain these inheritable file capabilities up to the container's bounding set. Containers which use Linux users and groups to perform privilege separation inside the container are most directly impacted.

This bug did not affect the container security sandbox as the inheritable set never contained more capabilities than were included in the container's bounding set.

Patches

This bug has been fixed in containerd 1.5.11 and 1.6.2. Users should update to these versions as soon as possible. Running containers should be stopped, deleted, and recreated for the inheritable capabilities to be reset.

This fix changes containerd behavior such that containers are started with a more typical Linux environment. Refer to capabilities(7) for a description of how capabilities work. Note that permitted file capabilities continue to allow for privileges to be raised up to the container's bounding set and that processes may add capabilities to their own inheritable set up to the container's bounding set per the rules described in the manual page. In all cases the container's bounding set provides an upper bound on the capabilities that can be assumed and provides for the container security sandbox.

Workarounds

The entrypoint of a container can be modified to use a utility like capsh(1) to drop inheritable capabilities prior to the primary process starting.

For more information

If you have any questions or comments about this advisory:

Open an issue
Email us at security@containerd.io if you think you’ve found a security bug

Locations:

/usr/bin/oc
github.com/containerd/containerd-v1.5.1

References:

Security Advisory: GHSA-5j5w-g665-5m35

Description:

Ambiguous OCI manifest parsing

Impact

In the OCI Distribution Specification version 1.0.0 and prior and in the OCI Image Specification version 1.0.1 and prior, manifest and index documents are ambiguous without an accompanying Content-Type HTTP header. Versions of containerd prior to 1.4.12 and 1.5.8 treat the Content-Type header as trusted and deserialize the document according to that header. If the Content-Type header changed between pulls of the same ambiguous document (with the same digest), the document may be interpreted differently, meaning that the digest alone is insufficient to unambiguously identify the content of the image.

Patches

This issue has been fixed in containerd 1.4.12 and 1.5.8. Image pulls for manifests that contain a “manifests” field or indices which contain a “layers” field are rejected.

Workarounds

Ensure you only pull images from trusted sources.

References

https://github.com/opencontainers/distribution-spec/security/advisories/GHSA-mc8v-mgrf-8f4m https://github.com/opencontainers/image-spec/security/advisories/GHSA-77vh-xpmg-72qh

For more information

If you have any questions or comments about this advisory: * Open an issue in containerd * Email us at security@containerd.io

Locations:

/usr/bin/oc
github.com/containerd/containerd-v1.5.1

References:

Security Advisory: CVE-2024-51744

Description:

golang-jwt is a Go implementation of JSON Web Tokens. Unclear documentation of the error behavior in `ParseWithClaims` can lead to situation where users are potentially not checking errors in the way they should be. Especially, if a token is both expired and invalid, the errors returned by `ParseWithClaims` return both error codes. If users only check for the `jwt.ErrTokenExpired ` using `error.Is`, they will ignore the embedded `jwt.ErrTokenSignatureInvalid` and thus potentially accept invalid tokens. A fix has been back-ported with the error handling logic from the `v5` branch to the `v4` branch. In this logic, the `ParseWithClaims` function will immediately return in "dangerous" situations (e.g., an invalid signature), limiting the combined errors only to situations where the signature is valid, but further validation failed (e.g., if the signature is valid, but is expired AND has the wrong audience). This fix is part of the 4.5.1 release. We are aware that this changes the behaviour of an established function and is not 100 % backwards compatible, so updating to 4.5.1 might break your code. In case you cannot update to 4.5.0, please make sure that you are properly checking for all errors ("dangerous" ones first), so that you are not running in the case detailed above.

Locations:

/usr/bin/oc
github.com/golang-jwt/jwt/v4-v4.2.0

References:

Security Advisory: CVE-2022-41725

Description:

A denial of service is possible from excessive resource consumption in net/http and mime/multipart. Multipart form parsing with mime/multipart.Reader.ReadForm can consume largely unlimited amounts of memory and disk files. This also affects form parsing in the net/http package with the Request methods FormFile, FormValue, ParseMultipartForm, and PostFormValue. ReadForm takes a maxMemory parameter, and is documented as storing "up to maxMemory bytes +10MB (reserved for non-file parts) in memory". File parts which cannot be stored in memory are stored on disk in temporary files. The unconfigurable 10MB reserved for non-file parts is excessively large and can potentially open a denial of service vector on its own. However, ReadForm did not properly account for all memory consumed by a parsed form, such as map entry overhead, part names, and MIME headers, permitting a maliciously crafted form to consume well over 10MB. In addition, ReadForm contained no limit on the number of disk files created, permitting a relatively small request body to create a large number of disk temporary files. With fix, ReadForm now properly accounts for various forms of memory overhead, and should now stay within its documented limit of 10MB + maxMemory bytes of memory consumption. Users should still be aware that this limit is high and may still be hazardous. In addition, ReadForm now creates at most one on-disk temporary file, combining multiple form parts into a single temporary file. The mime/multipart.File interface type's documentation states, "If stored on disk, the File's underlying concrete type will be an *os.File.". This is no longer the case when a form contains more than one file part, due to this coalescing of parts into a single file. The previous behavior of using distinct files for each form part may be reenabled with the environment variable GODEBUG=multipartfiles=distinct. Users should be aware that multipart.ReadForm and the http.Request methods that call it do not limit the amount of disk consumed by temporary files. Callers can limit the size of form data with http.MaxBytesReader.

Locations:

git-lfs-3.4.1-2.el8_10

References:

Security Advisory: CVE-2023-24536

Description:

Multipart form parsing can consume large amounts of CPU and memory when processing form inputs containing very large numbers of parts. This stems from several causes: 1. mime/multipart.Reader.ReadForm limits the total memory a parsed multipart form can consume. ReadForm can undercount the amount of memory consumed, leading it to accept larger inputs than intended. 2. Limiting total memory does not account for increased pressure on the garbage collector from large numbers of small allocations in forms with many parts. 3. ReadForm can allocate a large number of short-lived buffers, further increasing pressure on the garbage collector. The combination of these factors can permit an attacker to cause an program that parses multipart forms to consume large amounts of CPU and memory, potentially resulting in a denial of service. This affects programs that use mime/multipart.Reader.ReadForm, as well as form parsing in the net/http package with the Request methods FormFile, FormValue, ParseMultipartForm, and PostFormValue. With fix, ReadForm now does a better job of estimating the memory consumption of parsed forms, and performs many fewer short-lived allocations. In addition, the fixed mime/multipart.Reader imposes the following limits on the size of parsed forms: 1. Forms parsed with ReadForm may contain no more than 1000 parts. This limit may be adjusted with the environment variable GODEBUG=multipartmaxparts=. 2. Form parts parsed with NextPart and NextRawPart may contain no more than 10,000 header fields. In addition, forms parsed with ReadForm may contain no more than 10,000 header fields across all parts. This limit may be adjusted with the environment variable GODEBUG=multipartmaxheaders=.

Locations:

git-lfs-3.4.1-2.el8_10

References:

Security Advisory: GHSA-mq39-4gv4-mvpx

Description:

Moby's external DNS requests from 'internal' networks could lead to data exfiltration

Moby is an open source container framework originally developed by Docker Inc. as Docker. It is a key component of Docker Engine, Docker Desktop, and other distributions of container tooling or runtimes. As a batteries-included container runtime, Moby comes with a built-in networking implementation that enables communication between containers, and between containers and external resources.

Moby's networking implementation allows for creating and using many networks, each with their own subnet and gateway. This feature is frequently referred to as custom networks, as each network can have a different driver, set of parameters, and thus behaviors. When creating a network, the --internal flag is used to designate a network as internal. The internal attribute in a docker-compose.yml file may also be used to mark a network internal, and other API clients may specify the internal parameter as well.

When containers with networking are created, they are assigned unique network interfaces and IP addresses (typically from a non-routable RFC 1918 subnet). The root network namespace (hereafter referred to as the 'host') serves as a router for non-internal networks, with a gateway IP that provides SNAT/DNAT to/from container IPs.

Containers on an internal network may communicate between each other, but are precluded from communicating with any networks the host has access to (LAN or WAN) as no default route is configured, and firewall rules are set up to drop all outgoing traffic. Communication with the gateway IP address (and thus appropriately configured host services) is possible, and the host may communicate with any container IP directly.

In addition to configuring the Linux kernel's various networking features to enable container networking, dockerd directly provides some services to container networks. Principal among these is serving as a resolver, enabling service discovery (looking up other containers on the network by name), and resolution of names from an upstream resolver.

When a DNS request for a name that does not correspond to a container is received, the request is forwarded to the configured upstream resolver (by default, the host's configured resolver). This request is made from the container network namespace: the level of access and routing of traffic is the same as if the request was made by the container itself.

As a consequence of this design, containers solely attached to internal network(s) will be unable to resolve names using the upstream resolver, as the container itself is unable to communicate with that nameserver. Only the names of containers also attached to the internal network are able to be resolved.

Many systems will run a local forwarding DNS resolver, typically present on a loopback address (127.0.0.0/8), such as systemd-resolved or dnsmasq. Common loopback address examples include 127.0.0.1 or 127.0.0.53. As the host and any containers have separate loopback devices, a consequence of the design described above is that containers are unable to resolve names from the host's configured resolver, as they cannot reach these addresses on the host loopback device.

To bridge this gap, and to allow containers to properly resolve names even when a local forwarding resolver is used on a loopback address, dockerd will detect this scenario and instead forward DNS requests from the host/root network namespace. The loopback resolver will then forward the requests to its configured upstream resolvers, as expected.

Impact

Because dockerd will forward DNS requests to the host loopback device, bypassing the container network namespace's normal routing semantics entirely, internal networks can unexpectedly forward DNS requests to an external nameserver.

By registering a domain for which they control the authoritative nameservers, an attacker could arrange for a compromised container to exfiltrate data by encoding it in DNS queries that will eventually be answered by their nameservers. For example, if the domain evil.example was registered, the authoritative nameserver(s) for that domain could (eventually and indirectly) receive a request for this-is-a-secret.evil.example.

Docker Desktop is not affected, as Docker Desktop always runs an internal resolver on a RFC 1918 address.

Patches

Moby releases 26.0.0-rc3, 25.0.5 (released) and 23.0.11 (to be released) are patched to prevent forwarding DNS requests from internal networks.

Workarounds

Run containers intended to be solely attached to internal networks with a custom upstream address (--dns argument to docker run, or API equivalent), which will force all upstream DNS queries to be resolved from the container network namespace.

Background

yair zak originally reported this issue to the Docker security team.
PR https://github.com/moby/moby/pull/46609 was opened in public to fix this issue, as it was not originally considered to have a security implication.
The official documentation claims that "the --internal flag that will completely isolate containers on a network from any communications external to that network," which necessitated this advisory and CVE.

Locations:

/usr/bin/oc