Critical: Updated Container Images: HawtIO 4.4.1 for Red Hat build of Apache Camel 4 Release and security update.

Critical: redhat-ds:11 security, bug fix, and enhancement update

Critical: redhat-ds:11 security, bug fix, and enhancement update

Critical: 389-ds:1.4 security, bug fix, and enhancement update

Critical: 389-ds-base security, bug fix, and enhancement update

Critical: redhat-ds:12 security, bug fix, and enhancement update

Critical: redhat-ds:12 security, bug fix, and enhancement update

Critical: 389-ds-base security, bug fix, and enhancement update

Critical: 389-ds:1.4 security, bug fix, and enhancement update

Critical: 389-ds-base security, bug fix, and enhancement update

Critical: Red Hat Update Infrastructure 5.3 Technology Preview security update

Critical: Red Hat build of Keycloak 26.6.6 Security Update

Critical: Red Hat build of Keycloak 26.6.6 Images Security Update

Critical: Red Hat build of Keycloak 26.4.15 Security Update

Critical: Red Hat build of Keycloak 26.4.15 Images Security Update

Critical: Multicluster Global Hub 1.4.8 security update

Critical: Multicluster Global Hub 1.5.7 security update

Critical: Multicluster Global Hub 1.6.5 security update

OpenShift Container Platform 4.16.68 bug fix and security update

A flaw was found in multicloud-integrations, a component of Red Hat Advanced Cluster Management (RHACM). This vulnerability allows an authenticated user, referred to as a tenant, to manipulate the GitOpsCluster controller. By exploiting this, a tenant can redirect sensitive spoke cluster bearer tokens from secure locations to a namespace they control. This unauthorized access to tokens can lead to the disclosure of critical information and bypass security policies within ArgoCD AppProjects.

A flaw was found in the multicloud-integrations component of Red Hat Advanced Cluster Management (RHACM). The Application propagation controller takes the tenant-controlled ocm-managed-cluster annotation verbatim from an Application CR and uses it as the ManifestWork namespace without authorization checks. The only validation is a bare existence check on the target ManagedCluster. A tenant with Application create permissions in any hub namespace can generate ManifestWorks targeting arbitrary managed clusters, resulting in spoke cluster-admin ArgoCD syncing attacker-controlled manifests.

Upstream repo: https://github.com/stolostron/multicloud-integrations Audited commit: d88a168 Jira tracker: ACM-38643

A flaw was found in the multicloud-operators-subscription component of Red Hat Advanced Cluster Management (RHACM). The application-manager addon's ClusterRole grants apiGroups: resources: verbs: (plus nonResourceURLs:) and is bound to the application-manager ServiceAccount on every managed cluster via the addon framework. This wildcard RBAC is the root enabler for multiple confused-deputy attacks where a namespace-admin tenant can create Subscription CRs that deploy arbitrary cluster-scoped resources using this privileged SA. A least-privilege variant exists in addon/manifests/permission/role.yaml but is not used by default.

Upstream repo: https://github.com/stolostron/multicloud-operators-subscription Audited commit: 48ae4defaa5b719e0664e1de7413c96029c938bc Jira tracker: ACM-38624

Release of RHOAI 3.3.6 provides these changes:

Release of RHOAI 3.4.3 provides these changes:

Release of RHOAI 2.25.10 provides these changes:

Critical: Multicluster Global Hub 1.7.2 security update

Critical: Multicluster Global Hub 1.8.1 security update

OpenShift Container Platform 4.17.56 bug fix and security update

A flaw was found in the Keycloak reset-credentials authentication flow. The vulnerability exists in the way the flow state is managed, allowing an unauthenticated remote attacker to bypass the email verification requirement. By sending a specially crafted request to the reset-credentials endpoint, an attacker can transition the authentication session directly to the password update phase without possessing the required action token typically sent via email. Successful exploitation allows an attacker to perform a complete account takeover of any user, including administrative accounts, by resetting their password.

A flaw was found in 389 Directory Server (389-ds-base). During SASL PLAIN authentication, the idssaslcanonuser() function writes the resolved bind DN into a Cyrus SASL auxiliary property (propset) on every canonicalization attempt, including failed ones. A failed one-shot PLAIN exchange does not trigger SASL-context recreation in idssaslcheckbind() -- that only happens when CONNFLAGSASLCOMPLETE or continuing is already set. A subsequent successful SASL bind on the same connection retrieves the auxiliary property via propgetnames() and unconditionally trusts only the first stored value (dnval[0].values[0]), with no check on which SASL mechanism completed the second exchange and no check that the value corresponds to the identity actually just authenticated.

An unprivileged remote attacker can exploit this with zero valid credentials: first send a SASL PLAIN bind as cn=Directory Manager with an incorrect password (fails as expected, but leaves the Directory Manager DN in slot 0 of the auxiliary property), then complete a SASL ANONYMOUS bind on the same connection. The server installs the stale Directory Manager identity instead of the anonymous identity, granting full Directory Manager authority. This was independently confirmed by Red Hat Product Security in an isolated, network-disconnected sandbox against 389-ds-base-2.9.0: "Who Am I?" returned "cn=directory manager", and the Directory-Manager-only cn=config attribute nsslapd-rootdn became readable. The same stale-identity mechanism also allows escalation via a valid low-privileged account's own successful second bind (originally reported variant, requiring one valid account), independently reproduced against the reporter's own PoC.

Root cause: ldap/servers/slapd/saslbind.c, idssaslcanonuser() (identity write, unconditional per mechanism) and idssaslcheckbind() (identity read-back and installation, no mechanism check, no freshness check). Verified directly against commit 33c0e0115c03017ba94ee02f144383704de32a25; unchanged since a September 2024 logging-format cleanup.