ubi-micro-dev

ID	Age	Component	Trivy Severity	Grype Severity	Red Hat Severity	ubi-micro-dev Opinion
CVE-2025-66293	196	java-1.8.0-openjdk-headless	High	High	Important	False Positive
CVE-2026-22020	?	java-1.8.0-openjdk-headless	High			False Positive
CVE-2026-25646	127	java-1.8.0-openjdk-headless	High	High	Important	False Positive
CVE-2025-21502	512	java-1.8.0-openjdk-headless	Medium	Medium	Moderate	False Positive
CVE-2025-28164	141	java-1.8.0-openjdk-headless	Medium	Medium	Moderate	False Positive
CVE-2025-64505	205	java-1.8.0-openjdk-headless	Medium	Medium	Moderate	False Positive
CVE-2025-64506	205	java-1.8.0-openjdk-headless	Medium	Medium	Moderate	False Positive
CVE-2026-5435	50	glibc glibc-common glibc-langpack-en glibc-minimal-langpack	Medium	Medium	Moderate
CVE-2026-5450	58	glibc glibc-common glibc-langpack-en glibc-minimal-langpack	Medium	Medium	Moderate	Ignorable
CVE-2026-5928	58	glibc glibc-common glibc-langpack-en glibc-minimal-langpack	Medium	Medium	Moderate	Ignorable
CVE-2026-5958	58	sed	Medium	Medium	Moderate
CVE-2026-6238	50	glibc glibc-common glibc-langpack-en glibc-minimal-langpack	Medium		Moderate
CVE-2026-22695	156	java-1.8.0-openjdk-headless	Medium	Medium	Moderate	False Positive
CVE-2026-22801	156	java-1.8.0-openjdk-headless	Medium	Medium	Moderate	False Positive
CVE-2026-33416	83	java-1.8.0-openjdk-headless	Medium	Medium	Moderate	False Positive
CVE-2026-33636	83	java-1.8.0-openjdk-headless	Medium	Medium	Moderate	False Positive
CVE-2026-34757	69	java-1.8.0-openjdk-headless	Medium	Medium	Moderate	False Positive
CVE-2026-41254	60	java-1.8.0-openjdk-headless	Medium	Medium	Moderate
CVE-2021-46195	1615	libgcc	Low	Low	Low
CVE-2022-27943	1544	libgcc	Low	Low	Low	False Positive
CVE-2022-41409	1065	pcre2 pcre2-syntax	Low	Low	Low	False Positive
CVE-2023-50495	918	ncurses-libs	Low	Low	Low	False Positive
CVE-2025-13151	161	libtasn1	Low	Low	Low
CVE-2026-27171	119	java-1.8.0-openjdk-headless	Low	Low	Low	False Positive
CVE-2022-3857	1322	java-1.8.0-openjdk-headless		Low	Low	Ignorable

Security Advisory: CVE-2025-66293

ubi-micro-dev Opinion:

This is a false positive. The vulnerable code from `libpng` only exists in `libsplashscreen.so`, which is not part of any `java-*-openjdk-headless` package. The vulnerable library is distributed in `java-*-openjdk`, which is not installed in this container image. Red Hat has confirmed this, noting that "java-*-openjdk-headless packages do not contain libsplashscreen.so, hence are not affected."

Description:

LIBPNG is a reference library for use in applications that read, create, and manipulate PNG (Portable Network Graphics) raster image files. Prior to 1.6.52, an out-of-bounds read vulnerability in libpng's simplified API allows reading up to 1012 bytes beyond the png_sRGB_base[512] array when processing valid palette PNG images with partial transparency and gamma correction. The PNG files that trigger this vulnerability are valid per the PNG specification; the bug is in libpng's internal state management. Upgrade to libpng 1.6.52 or later.

Locations:

java-1.8.0-openjdk-headless-1:1.8.0.492.b09-2.el9

References:

Security Advisory: CVE-2026-5928

ubi-micro-dev Opinion:

This vulnerability requires calling ungetwc() on a wide-character stream with specific overlapping single-byte and multi-byte encodings. None of the runtimes in these container images use glibc's ungetwc function: the JVM handles character encoding via its own converters, Node.js uses V8/libuv, and Python uses its own codec system. Container inspection confirms no shared library in the image links against ungetwc. Additionally, the ungetwc symbol can be localized in libc.so.6 via ELF .dynsym patching to prevent any future dynamic linking without breaking glibc internals.

Description:

Calling the ungetwc function on a FILE stream with wide characters encoded in a character set that has overlaps between its single byte and multi-byte character encodings, in the GNU C Library version 2.43 or earlier, may result in an attempt to read bytes before an allocated buffer, potentially resulting in unintentional disclosure of neighboring data in the heap, or a program crash.
A bug in the wide character pushback implementation (_IO_wdefault_pbackfail in libio/wgenops.c) causes ungetwc() to operate on the regular character buffer (fp->_IO_read_ptr) instead of the actual wide-stream read pointer (fp->_wide_data->_IO_read_ptr). The program crash may happen in cases where fp->_IO_read_ptr is not initialized and hence points to NULL. The buffer under-read requires a special situation where the input character encoding is such that there are overlaps between single byte representations and multibyte representations in that encoding, resulting in spurious matches. The spurious match case is not possible in the standard Unicode character sets.

Locations:

glibc-2.34-270.el9_8
glibc-common-2.34-270.el9_8
glibc-langpack-en-2.34-270.el9_8
glibc-minimal-langpack-2.34-270.el9_8

References:

Security Advisory: CVE-2026-33416

ubi-micro-dev Opinion:

This is a false positive. The vulnerable code from libpng only exists in libsplashscreen.so, which is not part of any java-*-openjdk-headless package. The vulnerable library is distributed in java-*-openjdk, which is not installed in this container image. Container inspection confirms no libsplashscreen.so or system libpng RPM is present in any ubi-micro-dev Java headless image (UBI 8/9, JDK 8/17/21). Scanners flag these CVEs because the OpenJDK SRPM bundles libpng source code, but the headless binary subpackage does not compile or ship the vulnerable library.

Description:

LIBPNG is a reference library for use in applications that read, create, and manipulate PNG (Portable Network Graphics) raster image files. In versions 1.2.1 through 1.6.55, `png_set_tRNS` and `png_set_PLTE` each alias a heap-allocated buffer between `png_struct` and `png_info`, sharing a single allocation across two structs with independent lifetimes. The `trans_alpha` aliasing has been present since at least libpng 1.0, and the `palette` aliasing since at least 1.2.1. Both affect all prior release lines `png_set_tRNS` sets `png_ptr->trans_alpha = info_ptr->trans_alpha` (256-byte buffer) and `png_set_PLTE` sets `info_ptr->palette = png_ptr->palette` (768-byte buffer). In both cases, calling `png_free_data` (with `PNG_FREE_TRNS` or `PNG_FREE_PLTE`) frees the buffer through `info_ptr` while the corresponding `png_ptr` pointer remains dangling. Subsequent row-transform functions dereference and, in some code paths, write to the freed memory. A second call to `png_set_tRNS` or `png_set_PLTE` has the same effect, because both functions call `png_free_data` internally before reallocating the `info_ptr` buffer. Version 1.6.56 fixes the issue.

Locations:

java-1.8.0-openjdk-headless-1:1.8.0.492.b09-2.el9

References:

Security Advisory: CVE-2026-33636

ubi-micro-dev Opinion:

This is a false positive. The vulnerable code from libpng only exists in libsplashscreen.so, which is not part of any java-*-openjdk-headless package. The vulnerable library is distributed in java-*-openjdk, which is not installed in this container image. Container inspection confirms no libsplashscreen.so or system libpng RPM is present in any ubi-micro-dev Java headless image (UBI 8/9, JDK 8/17/21). Scanners flag these CVEs because the OpenJDK SRPM bundles libpng source code, but the headless binary subpackage does not compile or ship the vulnerable library.

Description:

LIBPNG is a reference library for use in applications that read, create, and manipulate PNG (Portable Network Graphics) raster image files. In versions 1.6.36 through 1.6.55, an out-of-bounds read and write exists in libpng's ARM/AArch64 Neon-optimized palette expansion path. When expanding 8-bit paletted rows to RGB or RGBA, the Neon loop processes a final partial chunk without verifying that enough input pixels remain. Because the implementation works backward from the end of the row, the final iteration dereferences pointers before the start of the row buffer (OOB read) and writes expanded pixel data to the same underflowed positions (OOB write). This is reachable via normal decoding of attacker-controlled PNG input if Neon is enabled. Version 1.6.56 fixes the issue.

Locations:

java-1.8.0-openjdk-headless-1:1.8.0.492.b09-2.el9

References:

Security Advisory: CVE-2026-34757

ubi-micro-dev Opinion:

This is a false positive. The vulnerable code from libpng only exists in libsplashscreen.so, which is not part of any java-*-openjdk-headless package. The vulnerable library is distributed in java-*-openjdk, which is not installed in this container image. Container inspection confirms no libsplashscreen.so or system libpng RPM is present in any ubi-micro-dev Java headless image (UBI 8/9, JDK 8/17/21). Scanners flag these CVEs because the OpenJDK SRPM bundles libpng source code, but the headless binary subpackage does not compile or ship the vulnerable library.

Description:

LIBPNG is a reference library for use in applications that read, create, and manipulate PNG (Portable Network Graphics) raster image files. From 1.0.9 to before 1.6.57, passing a pointer obtained from png_get_PLTE, png_get_tRNS, or png_get_hIST back into the corresponding setter on the same png_struct/png_info pair causes the setter to read from freed memory and copy its contents into the replacement buffer. The setter frees the internal buffer before copying from the caller-supplied pointer, which now dangles. The freed region may contain stale data (producing silently corrupted chunk metadata) or data from subsequent heap allocations (leaking unrelated heap contents into the chunk struct). This vulnerability is fixed in 1.6.57.

Locations:

java-1.8.0-openjdk-headless-1:1.8.0.492.b09-2.el9

ghcr.io/ubi-micro-dev/ubi9-micro-dev-openjdk-8:latest

With RPM updates as of