ghcr.io/ubi-micro-dev/ubi9-micro-dev-nodejs-20:latest

With RPM updates as of

Show kernel-headers

ID	Age	Component	Trivy Severity	Grype Severity	Red Hat Severity	ubi-micro-dev Opinion
CVE-2023-38552	928	nodejs npm	Medium	Medium	Moderate
CVE-2025-59464	102	nodejs npm	Medium	Medium	Moderate
CVE-2025-62408	145	nodejs npm	Medium	Medium	Moderate
CVE-2025-64118	184	nodejs npm	Medium	Medium	Moderate
CVE-2025-64756	166	glob nodejs npm	Medium	High	Important
CVE-2026-2100	37	p11-kit-trust	Medium	Medium	Moderate	False Positive
CVE-2026-4046	33	glibc glibc-common glibc-langpack-en glibc-minimal-langpack	Medium	Medium	Moderate	False Positive
CVE-2026-4437	43	glibc glibc-common glibc-langpack-en glibc-minimal-langpack	Medium	Medium	Moderate	False Positive
CVE-2026-5435	5	glibc glibc-common glibc-langpack-en glibc-minimal-langpack	Medium	Medium	Moderate
CVE-2026-5450	12	glibc glibc-common glibc-langpack-en glibc-minimal-langpack	Medium	Medium	Moderate
CVE-2026-5928	12	glibc glibc-common glibc-langpack-en glibc-minimal-langpack	Medium	Medium	Moderate
CVE-2026-21712	33	nodejs npm	Medium	Medium	Moderate
CVE-2026-21713	33	nodejs npm	Medium	Medium	Moderate
CVE-2026-21714	33	nodejs npm	Medium	Medium	Moderate
CVE-2026-21717	33	nodejs npm	Medium	Medium	Moderate
CVE-2026-25547	87	nodejs npm	Medium	Medium	Moderate
CVE-2026-27903	65	minimatch nodejs npm	Medium	High	Moderate
CVE-2026-28386	25	openssl openssl-libs	Medium		Moderate
CVE-2026-28390	25	openssl openssl-libs	Medium	Medium	Moderate
CVE-2026-31790	25	openssl openssl-libs	Medium	Medium	Moderate
CVE-2026-33750	37	brace-expansion nodejs npm	Medium	Medium	Moderate
CVE-2022-27943	1499	libgcc libstdc++	Low	Low	Low	False Positive
CVE-2022-41409	1019	pcre2 pcre2-syntax	Low	Low	Low	False Positive
CVE-2023-45143	933	nodejs npm	Low	Low	Low
CVE-2023-50495	872	ncurses-libs	Low	Low	Low	False Positive
CVE-2024-13176	467	openssl openssl-libs	Low	Low	Low
CVE-2024-21538	541	cross-spawn nodejs npm	Low	High	Low
CVE-2024-41996	615	openssl openssl-libs	Low	Low	Low
CVE-2025-5889	327	brace-expansion nodejs npm	Low	Low	Low
CVE-2025-9232	214	openssl openssl-libs	Low	Low	Low
CVE-2025-13151	115	libtasn1	Low	Low	Low
CVE-2026-2673	50	openssl openssl-fips-provider openssl-fips-provider-so openssl-libs	Low	Low	Low
CVE-2026-4438	43	glibc glibc-common glibc-langpack-en glibc-minimal-langpack	Low	Low	Low	False Positive
CVE-2026-21715	33	nodejs npm	Low	Low	Low
CVE-2026-21716	33	nodejs npm	Low	Low	Low
CVE-2026-27171	74	zlib	Low	Low	Low	Ignorable
CVE-2026-28387	25	openssl openssl-libs	Low		Low
CVE-2026-28388	25	openssl openssl-libs	Low	Low	Low
CVE-2026-28389	25	openssl openssl-libs	Low	Low	Low
CVE-2026-31789	25	openssl openssl-libs	Low	Low	Low
CVE-2026-24001	108	diff		Low	Important

Security Advisory: CVE-2026-27903

Description:

minimatch is a minimal matching utility for converting glob expressions into JavaScript RegExp objects. Prior to version 10.2.3, 9.0.7, 8.0.6, 7.4.8, 6.2.2, 5.1.8, 4.2.5, and 3.1.3, `matchOne()` performs unbounded recursive backtracking when a glob pattern contains multiple non-adjacent `**` (GLOBSTAR) segments and the input path does not match. The time complexity is O(C(n, k)) -- binomial -- where `n` is the number of path segments and `k` is the number of globstars. With k=11 and n=30, a call to the default `minimatch()` API stalls for roughly 5 seconds. With k=13, it exceeds 15 seconds. No memoization or call budget exists to bound this behavior. Any application where an attacker can influence the glob pattern passed to `minimatch()` is vulnerable. The realistic attack surface includes build tools and task runners that accept user-supplied glob arguments (ESLint, Webpack, Rollup config), multi-tenant systems where one tenant configures glob-based rules that run in a shared process, admin or developer interfaces that accept ignore-rule or filter configuration as globs, and CI/CD pipelines that evaluate user-submitted config files containing glob patterns. An attacker who can place a crafted pattern into any of these paths can stall the Node.js event loop for tens of seconds per invocation. The pattern is 56 bytes for a 5-second stall and does not require authentication in contexts where pattern input is part of the feature. Versions 10.2.3, 9.0.7, 8.0.6, 7.4.8, 6.2.2, 5.1.8, 4.2.5, and 3.1.3 fix the issue.

Locations:

/usr/lib/node_modules/npm/node_modules/minimatch/package.json
nodejs-1:20.20.2-1.module+el9.7.0+24193+41b7b572
npm-1:10.8.2-1.20.20.2.1.module+el9.7.0+24193+41b7b572

References:

Security Advisory: CVE-2026-2673

Description:

Issue summary: An OpenSSL TLS 1.3 server may fail to negotiate the expected
preferred key exchange group when its key exchange group configuration includes
the default by using the 'DEFAULT' keyword.
Impact summary: A less preferred key exchange may be used even when a more
preferred group is supported by both client and server, if the group
was not included among the client's initial predicated keyshares.
This will sometimes be the case with the new hybrid post-quantum groups,
if the client chooses to defer their use until specifically requested by
the server.
If an OpenSSL TLS 1.3 server's configuration uses the 'DEFAULT' keyword to
interpolate the built-in default group list into its own configuration, perhaps
adding or removing specific elements, then an implementation defect causes the
'DEFAULT' list to lose its 'tuple' structure, and all server-supported groups
were treated as a single sufficiently secure 'tuple', with the server not
sending a Hello Retry Request (HRR) even when a group in a more preferred tuple
was mutually supported.
As a result, the client and server might fail to negotiate a mutually supported
post-quantum key agreement group, such as 'X25519MLKEM768', if the client's
configuration results in only 'classical' groups (such as 'X25519' being the
only ones in the client's initial keyshare prediction).
OpenSSL 3.5 and later support a new syntax for selecting the most preferred TLS
1.3 key agreement group on TLS servers. The old syntax had a single 'flat'
list of groups, and treated all the supported groups as sufficiently secure.
If any of the keyshares predicted by the client were supported by the server
the most preferred among these was selected, even if other groups supported by
the client, but not included in the list of predicted keyshares would have been
more preferred, if included.
The new syntax partitions the groups into distinct 'tuples' of roughly
equivalent security. Within each tuple the most preferred group included among
the client's predicted keyshares is chosen, but if the client supports a group
from a more preferred tuple, but did not predict any corresponding keyshares,
the server will ask the client to retry the ClientHello (by issuing a Hello
Retry Request or HRR) with the most preferred mutually supported group.
The above works as expected when the server's configuration uses the built-in
default group list, or explicitly defines its own list by directly defining the
various desired groups and group 'tuples'.
No OpenSSL FIPS modules are affected by this issue, the code in question lies
outside the FIPS boundary.
OpenSSL 3.6 and 3.5 are vulnerable to this issue.
OpenSSL 3.6 users should upgrade to OpenSSL 3.6.2 once it is released.
OpenSSL 3.5 users should upgrade to OpenSSL 3.5.6 once it is released.
OpenSSL 3.4, 3.3, 3.0, 1.0.2 and 1.1.1 are not affected by this issue.

Locations:

openssl-1:3.5.1-7.el9_7
openssl-fips-provider-3.0.7-8.el9
openssl-fips-provider-so-3.0.7-8.el9
openssl-libs-1:3.5.1-7.el9_7

References:

Security Advisory: CVE-2026-28388

Description:

Issue summary: When a delta CRL that contains a Delta CRL Indicator extension
is processed a NULL pointer dereference might happen if the required CRL
Number extension is missing.
Impact summary: A NULL pointer dereference can trigger a crash which
leads to a Denial of Service for an application.
When CRL processing and delta CRL processing is enabled during X.509
certificate verification, the delta CRL processing does not check
whether the CRL Number extension is NULL before dereferencing it.
When a malformed delta CRL file is being processed, this parameter
can be NULL, causing a NULL pointer dereference.
Exploiting this issue requires the X509_V_FLAG_USE_DELTAS flag to be enabled in
the verification context, the certificate being verified to contain a
freshestCRL extension or the base CRL to have the EXFLAG_FRESHEST flag set, and
an attacker to provide a malformed CRL to an application that processes it.
The vulnerability is limited to Denial of Service and cannot be escalated to
achieve code execution or memory disclosure. For that reason the issue was
assessed as Low severity according to our Security Policy.
The FIPS modules in 3.6, 3.5, 3.4, 3.3 and 3.0 are not affected by this issue,
as the affected code is outside the OpenSSL FIPS module boundary.

Locations:

openssl-1:3.5.1-7.el9_7
openssl-libs-1:3.5.1-7.el9_7

References:

Security Advisory: CVE-2026-31789

Description:

Issue summary: Converting an excessively large OCTET STRING value to
a hexadecimal string leads to a heap buffer overflow on 32 bit platforms.
Impact summary: A heap buffer overflow may lead to a crash or possibly
an attacker controlled code execution or other undefined behavior.
If an attacker can supply a crafted X.509 certificate with an excessively
large OCTET STRING value in extensions such as the Subject Key Identifier
(SKID) or Authority Key Identifier (AKID) which are being converted to hex,
the size of the buffer needed for the result is calculated as multiplication
of the input length by 3. On 32 bit platforms, this multiplication may overflow
resulting in the allocation of a smaller buffer and a heap buffer overflow.
Applications and services that print or log contents of untrusted X.509
certificates are vulnerable to this issue. As the certificates would have
to have sizes of over 1 Gigabyte, printing or logging such certificates
is a fairly unlikely operation and only 32 bit platforms are affected,
this issue was assigned Low severity.
The FIPS modules in 3.6, 3.5, 3.4, 3.3 and 3.0 are not affected by this
issue, as the affected code is outside the OpenSSL FIPS module boundary.

Locations:

openssl-1:3.5.1-7.el9_7
openssl-libs-1:3.5.1-7.el9_7

References:

Security Advisory: CVE-2026-24001

Description:

jsdiff is a JavaScript text differencing implementation. Prior to versions 8.0.3, 5.2.2, 4.0.4, and 3.5.1, attempting to parse a patch whose filename headers contain the line break characters `\r`, `\u2028`, or `\u2029` can cause the `parsePatch` method to enter an infinite loop. It then consumes memory without limit until the process crashes due to running out of memory. Applications are therefore likely to be vulnerable to a denial-of-service attack if they call `parsePatch` with a user-provided patch as input. A large payload is not needed to trigger the vulnerability, so size limits on user input do not provide any protection. Furthermore, some applications may be vulnerable even when calling `parsePatch` on a patch generated by the application itself if the user is nonetheless able to control the filename headers (e.g. by directly providing the filenames of the files to be diffed). The `applyPatch` method is similarly affected if (and only if) called with a string representation of a patch as an argument, since under the hood it parses that string using `parsePatch`. Other methods of the library are unaffected. Finally, a second and lesser interdependent bug - a ReDOS - also exhibits when those same line break characters are present in a patch's *patch* header (also known as its "leading garbage"). A maliciously-crafted patch header of length *n* can take `parsePatch` O(*n*³) time to parse. Versions 8.0.3, 5.2.2, 4.0.4, and 3.5.1 contain a fix. As a workaround, do not attempt to parse patches that contain any of these characters: `\r`, `\u2028`, or `\u2029`.

Locations:

/usr/lib/node_modules/npm/node_modules/diff/package.json