ghcr.io/ubi-micro-dev/ubi9-micro-dev-python-3.12:latest

With RPM updates as of

Show kernel-headers

ID	Age	Component	Trivy Severity	Grype Severity	Red Hat Severity	ubi-micro-dev Opinion
CVE-2025-4516	260	python3.12 python3.12-libs	Medium	Medium	Moderate
CVE-2025-6069	227	python3.12 python3.12-libs	Medium	Medium	Moderate
CVE-2025-11468	10	python3.12 python3.12-libs	Medium	Medium	Moderate
CVE-2025-12781	9	python3.12 python3.12-libs	Medium	Medium	Moderate
CVE-2025-13837	60	python3.12 python3.12-libs	Medium	Medium	Moderate
CVE-2025-14104	56	libuuid	Medium	Medium	Moderate
CVE-2025-15282	10	python3.12 python3.12-libs	Medium	Medium	Moderate
CVE-2025-15366	10	python3.12 python3.12-libs	Medium	Medium	Moderate
CVE-2025-15367	10	python3.12 python3.12-libs	Medium	Medium	Moderate
CVE-2025-50181	226	python3.12-pip-wheel	Medium	Medium	Moderate
CVE-2025-50182	226	python3.12-pip-wheel	Medium	Medium	Moderate	False Positive
CVE-2026-0672	10	python3.12 python3.12-libs	Medium	Medium	Moderate
CVE-2026-0865	10	python3.12 python3.12-libs	Medium	Medium	Moderate
CVE-2026-0915	15	glibc glibc-common glibc-langpack-en glibc-minimal-langpack	Medium	Medium	Moderate
CVE-2026-1299	7	python3.12 python3.12-libs	Medium	Medium	Moderate
CVE-2022-27943	1406	libgcc	Low	Low	Low	False Positive
CVE-2022-41409	927	pcre2 pcre2-syntax	Low	Low	Low	False Positive
CVE-2023-50495	780	ncurses-libs	Low	Low	Low	False Positive
CVE-2024-13176	375	openssl-libs	Low	Low	Low
CVE-2024-41996	523	openssl-libs	Low	Low	Low
CVE-2025-6075	91	python3.12 python3.12-libs	Low	Low	Low
CVE-2025-9232	122	openssl-libs	Low	Low	Low
CVE-2025-13151	23	libtasn1	Low	Low	Low
CVE-2025-15281	10	glibc glibc-common glibc-langpack-en glibc-minimal-langpack	Low	Low	Low
CVE-2025-66382	63	expat	Low	Low	Low
CVE-2026-0861	16	glibc glibc-common glibc-langpack-en glibc-minimal-langpack	Low	Low	Low
CVE-2026-24515	7	expat	Low	Low	Low

Security Advisory: CVE-2025-12781

Description:

When passing data to the b64decode(), standard_b64decode(), and urlsafe_b64decode() functions in the "base64" module the characters "+/" will always be accepted, regardless of the value of "altchars" parameter, typically used to establish an "alternative base64 alphabet" such as the URL safe alphabet. This behavior matches what is recommended in earlier base64 RFCs, but newer RFCs now recommend either dropping characters outside the specified base64 alphabet or raising an error. The old behavior has the possibility of causing data integrity issues.
This behavior can only be insecure if your application uses an alternate base64 alphabet (without "+/"). If your application does not use the "altchars" parameter or the urlsafe_b64decode() function, then your application does not use an alternative base64 alphabet.
The attached patches DOES NOT make the base64-decode behavior raise an error, as this would be a change in behavior and break existing programs. Instead, the patch deprecates the behavior which will be replaced with the newly recommended behavior in a future version of Python. Users are recommended to mitigate by verifying user-controlled inputs match the base64
alphabet they are expecting or verify that their application would not be
affected if the b64decode() functions accepted "+" or "/" outside of altchars.

Locations:

python3.12-3.12.12-4.el9_7
python3.12-libs-3.12.12-4.el9_7

References:

Security Advisory: CVE-2025-9232

Description:

Issue summary: An application using the OpenSSL HTTP client API functions may
trigger an out-of-bounds read if the 'no_proxy' environment variable is set and
the host portion of the authority component of the HTTP URL is an IPv6 address.
Impact summary: An out-of-bounds read can trigger a crash which leads to
Denial of Service for an application.
The OpenSSL HTTP client API functions can be used directly by applications
but they are also used by the OCSP client functions and CMP (Certificate
Management Protocol) client implementation in OpenSSL. However the URLs used
by these implementations are unlikely to be controlled by an attacker.
In this vulnerable code the out of bounds read can only trigger a crash.
Furthermore the vulnerability requires an attacker-controlled URL to be
passed from an application to the OpenSSL function and the user has to have
a 'no_proxy' environment variable set. For the aforementioned reasons the
issue was assessed as Low severity.
The vulnerable code was introduced in the following patch releases:
3.0.16, 3.1.8, 3.2.4, 3.3.3, 3.4.0 and 3.5.0.
The FIPS modules in 3.5, 3.4, 3.3, 3.2, 3.1 and 3.0 are not affected by this
issue, as the HTTP client implementation is outside the OpenSSL FIPS module
boundary.

Locations:

openssl-libs-1:3.5.1-7.el9_7

References:

Security Advisory: CVE-2026-0861

Description:

Passing too large an alignment to the memalign suite of functions (memalign, posix_memalign, aligned_alloc) in the GNU C Library version 2.30 to 2.42 may result in an integer overflow, which could consequently result in a heap corruption.
Note that the attacker must have control over both, the size as well as the alignment arguments of the memalign function to be able to exploit this. The size parameter must be close enough to PTRDIFF_MAX so as to overflow size_t along with the large alignment argument. This limits the malicious inputs for the alignment for memalign to the range [1<<62+ 1, 1<<63] and exactly 1<<63 for posix_memalign and aligned_alloc.
Typically the alignment argument passed to such functions is a known constrained quantity (e.g. page size, block size, struct sizes) and is not attacker controlled, because of which this may not be easily exploitable in practice. An application bug could potentially result in the input alignment being too large, e.g. due to a different buffer overflow or integer overflow in the application or its dependent libraries, but that is again an uncommon usage pattern given typical sources of alignments.

Locations:

glibc-2.34-231.el9_7.2
glibc-common-2.34-231.el9_7.2
glibc-langpack-en-2.34-231.el9_7.2
glibc-minimal-langpack-2.34-231.el9_7.2