A flaw was found in Red Hat Openshift AI Service. A low-privileged attacker with access to an authenticated account, for example as a data scientist using a standard Jupyter notebook, can escalate their privileges to a full cluster administrator. This allows for the complete compromise of the cluster's confidentiality, integrity, and availability. The attacker can steal sensitive data, disrupt all services, and take control of the underlying infrastructure, leading to a total breach of the platform and all applications hosted on it.

A flaw was found in odh-dashboard in Red Hat Openshift AI. This vulnerability in the odh-dashboard component of Red Hat OpenShift AI (RHOAI) allows for the disclosure of Kubernetes Service Account tokens through a NodeJS endpoint. This could enable an attacker to gain unauthorized access to Kubernetes resources.

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

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.

In Jboss Application Server as shipped with Red Hat Enterprise Application Platform 5.2, it was found that the doFilter method in the ReadOnlyAccessFilter of the HTTP Invoker does not restrict classes for which it performs deserialization and thus allowing an attacker to execute arbitrary code via crafted serialized data.

Red Hat JBoss RichFaces Framework contains an expression language injection vulnerability via the UserResource resource. A remote, unauthenticated attacker could exploit this vulnerability to execute malicious code using a chain of Java serialized objects via org.ajax4jsf.resource.UserResource$UriData.

A missing authorization vulnerability was found in EDA (Event-Driven Ansible). The websocket endpoint at /api/eda/ws/ansible-rulebook does not verify that the authenticated user has permission to access the specified activation. The handleworkers() method in consumers.py performs a direct database lookup by activationid without permission filtering. Any authenticated user, even with zero EDA permissions, can send a forged Worker message with any activationid and receive plaintext credentials including AAP Controller OAuth tokens, vault passwords, SSH private keys, and TLS certificates.

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 AAP Controller's HashiCorp Vault credential integration. When a HashiCorp Vault Secret Lookup credential is configured with kubernetesrole authentication, the credential test endpoint (POST /api/controller/v2/credentials/{id}/test/) triggers the kubernetesauth() function which reads the controller pod's Kubernetes service account token from /var/run/secrets/kubernetes.io/serviceaccount/token and POSTs it as {"jwt": "<satoken>", "role": "<role>"} to the user-supplied vault URL. There is no validation or restriction on the vault URL target. An authenticated attacker with credential-creation privileges can set the vault URL to an attacker-controlled server and capture the SA token. The exfiltrated token (system:serviceaccount:ansible-automation-platform:automation-controller) has broad Kubernetes RBAC permissions including: full pod CRUD (get,list,watch,create,update,patch,delete) in both ansible-automation-job and ansible-automation-platform namespaces, and individual secret access (get,create,delete) in both namespaces. This allows the attacker to read database credentials, the Django SECRETKEY, and access all 31+ pods in the AAP platform namespace. In AAP Cloud (managed service) environments, this constitutes a tenant-to-infrastructure escape as the control plane is managed by Red Hat. The token has an approximately 1-year lifetime.

Upstream: https://github.com/ansible/awx (awxplugins/credentials/hashivault.py) Affected function: kubernetesauth() at hashivault.py:462-468 Reporter: Chris Meyers (internal — cmeyers) Tested against: platform.cus-0616.aws.ansiblecloud.com (AAP Cloud, ROSA)

Care Everywhere Gateway 14.3.10 contains a hard-coded credentials vulnerability in the bundled WildFly 8.2.0.Final management interface that allows unauthenticated remote attackers to gain administrative access by using default credentials identical across all installations. Attackers can authenticate to the exposed WildFly management console on port 20990 and deploy a malicious Web Application Archive file through the Deployments interface to achieve remote code execution as the Windows machine account. Version 14.x.x was declared end-of-life (EOL) in 2017 and future releases have addressed the vulnerable finding.

A vulnerability was found in Quarkus in the quarkus-security-webauthn module. The Quarkus WebAuthn module publishes default REST endpoints for registering and logging users in while allowing developers to provide custom REST endpoints. When developers provide custom REST endpoints, the default endpoints remain accessible, potentially allowing attackers to obtain a login cookie that has no corresponding user in the Quarkus application or, depending on how the application is written, could correspond to an existing user that has no relation with the current attacker, allowing anyone to log in as an existing user by just knowing that user's user name.

A flaw was found in OpenShift GitOps. Namespace admins can create ArgoCD Custom Resources (CRs) that trick the system into granting them elevated permissions in other namespaces, including privileged namespaces. An authenticated attacker can then use these elevated permissions to create privileged workloads that run on master nodes, effectively giving them root access to the entire cluster.

A flaw was found in Undertow. This vulnerability allows a remote attacker to construct specially crafted requests where header names are parsed differently by Undertow compared to upstream proxies. This discrepancy in header interpretation can be exploited to launch request smuggling attacks, potentially bypassing security controls and accessing unauthorized resources.

A flaw was found in Undertow. A remote attacker can exploit this vulnerability by sending \r\r\r as a header block terminator. This can be used for request smuggling with certain proxy servers, such as older versions of Apache Traffic Server and Google Cloud Classic Application Load Balancer, potentially leading to unauthorized access or manipulation of web requests.

Podman Desktop is a graphical tool for developing on containers and Kubernetes. Prior to 1.26.2, an unauthenticated HTTP server exposed by Podman Desktop allows any network attacker to remotely trigger denial-of-service conditions and extract sensitive information. By abusing missing connection limits and timeouts, an attacker can exhaust file descriptors and kernel memory, leading to application crash or full host freeze. Additionally, verbose error responses disclose internal paths and system details (including usernames on Windows), aiding further exploitation. The issue requires no authentication or user interaction and is exploitable over the network. This vulnerability is fixed in 1.26.2.

A flaw was found in the SAML metadata import functionality of the keycloak-services component, which is the core engine for identity brokering in Red Hat Build of Keycloak. When importing identity provider metadata that lacks specific usage attributes for keys, the system incorrectly disables signature validation for SAML responses even if a signing certificate is provided. This issue allows an unauthenticated attacker to forge a SAML response and gain unauthorized access to a user account by knowing their external identifier.

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.

Critical: Red Hat Advanced Cluster Management 2.9.2 security and bug fix container updates

Critical: OpenShift Container Platform 4.14.11 security and extras update

Critical: OpenShift Container Platform 4.14.11 bug fix and security update

Critical: Red Hat Advanced Cluster Management 2.7.11 security and bug fix container update

Critical: OpenShift Container Platform 4.14.12 bug fix and security update

Critical: OpenShift Container Platform 4.13.33 security and extras update

Critical: OpenShift Container Platform 4.13.33 bug fix and security update

Critical: Red Hat Advanced Cluster Management 2.8.5 security and bug fix container updates

Critical: Release of OpenShift Serverless 1.31.1

Critical: Release of OpenShift Serverless Client kn 1.31.1 security update

Critical: OpenShift Container Platform 4.12.50 security and extras update

Critical: OpenShift Container Platform 4.13.34 security update