Summary: Possible DOS in SPDY streaming code, used for attach, exec and port forwarding.
Requirements To Exploit: Access to the kubelet's endpoint (granted through nodes/proxy) or access to any of portforward, exec, or attach to pods. These all can be represented by the cluster roles
pods/portforward (create)
pods/exec (create)
pods/attach (create)
nodes/proxy (get/create)
Component Affected: Kubelet, CRI-O, kube-apiserver
Version Affected: Openshift 4.21.4 and below
Patch Available: yes
Version Fixed: none yet
Cvss: (Based on [https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator]). Please note that only the Base Score Metrics are required by the incident response team.
Impact: Based on the https://access.redhat.com/security/updates/classification , what do you think would be the impact and why? This helps a lot the analyst to understand why such a report must be or not considered Moderate/Important or even Critical.
Steps To Reproduce: apply:
— apiVersion: v1 kind: ServiceAccount metadata: name: poc-sa-portforward namespace: default — apiVersion: [rbac.authorization.k8s.io/v1:(http://rbac.authorization.k8s.io/v1)(http://rbac.authorization.k8s.io/v1)] kind: Role metadata: name: poc-role-portforward namespace: default rules:
apiGroups: [""] resources: ["pods/portforward"] verbs: ["create"] — apiVersion: [rbac.authorization.k8s.io/v1:(http://rbac.authorization.k8s.io/v1)(http://rbac.authorization.k8s.io/v1)] kind: RoleBinding metadata: name: poc-rb-portforward namespace: default subjects:
kind: ServiceAccount name: poc-sa-portforward namespace: default roleRef: kind: Role name: poc-role-portforward apiGroup: rbac.authorization.k8s.io — apiVersion: v1 kind: Pod metadata: name: poc-target namespace: default spec: containers:
name: nginx image: nginx:alpine
set env:
export APISERVER=$(kubectl config view --minify -o jsonpath='{.clusters[0].cluster.server}' | sed 's|https://||')
export TOKEN=$(kubectl create token poc-sa-portforward)
export POD=poc-target
run attached pocportforward.py
Mitigation: disable the above cluster roles from untrusted users.
Embargo Reason: Coordination with three upstream communities: containerd, CRI-O, kubernetes
Original Report: https://github.com/moby/spdystream/security/advisories/GHSA-pc3f-x583-g7j2
End of life: 12/31/2027, End of support: 12/31/2026, Latest version: 4.22.9
The Route OpenShift resource allows to define routes to make pods reachable at a subdomain through HAProxy. These Routes are managed by the openshift-ingress/router-default pods. One of the features of Routes is their ability to match a URI's path and replace it, this is expressed in the Route by the spec.path and metadata.annotations"[haproxy.router.openshift.io/rewrite-target YAML stanzas in a Route document which are in turn (after various checks and sanitization) used as parameters to a HAProxy configuration template. This configuration template is expressed in plaintext, thus the templating engine cannot automatically escape values to enforce the document structure, escaping has to be performed on the values before the template's evaluation.
By default the Developer role can create Routes to expose their services.
It was found that the checks performed on the Routes spec.path was insufficient and could allow a controlled injection of the HAProxy configuration.
The ability to specify a custom host name is governed by the "custom-host" permission, which is granted by default to all project administrators[1]. It is possible for the cluster administrator to revoke this permission. Then, the OpenShift API admission checks should prohibit project administrators from setting a custom host name on ingress and route objects. The problem is that the admission checks do not enforce this prohibition for ingress objects under some circumstances.
End of life: 4/21/2027, End of support: 5/3/2026, Latest version: 4.20.35
End of life: 8/3/2027, End of support: 9/9/2026, Latest version: 4.21.30
there is a content spoofing flaw in OpenShift's OAuth endpoint (https://oauth.openshift.apps.HOSTNAME.com) and spoofing an errordescription query param results in seeing the error message come back in the OpenShift response JSON. For example, this URL:
https://oauth-openshift.apps.jmazziteos4.lab.upshift.rdu2.redhat.com/errordescription=An%20error%20occurred,%20to%20correct%20please%20visit%20http://dr.evil.com%20or%20call%20the%20number%20081337
is shown an error message which includes text which has been injected by the attacker "An error occurred, to correct please visit http://dr.evil.com or call the number 081337"
This release of the Red Hat OpenShift distributed tracing platform (Jaeger) provides security improvements.Breaking changes: Nothing Deprecations: Nothing Technology Preview features: Nothing Enhancements: Nothing Bug fixes: https://access.redhat.com/security/cve/CVE-2025-4373 https://access.redhat.com/security/cve/CVE-2024-34397 https://access.redhat.com/security/cve/CVE-2024-52533 Known issues: Nothing
End of life: 12/17/2026, End of support: 1/21/2026, Latest version: 4.19.43
Moderate: Release of OpenShift Serverless Logic 1.36.0 security update & enhancements
Important: Red Hat OpenShift GitOps 1.16.1 security release
Errata Advisory for Red Hat OpenShift GitOps v1.14.4 security release.Security Fix(es): openshift-gitops-argocd-container: Improper URL Sanitization in Argo CD Repository Page Allows Cross-Site Scripting (XSS) gitops-1.14 openshift-gitops-1/gitops-operator-bundle: Improper URL Sanitization in Argo CD Repository Page Allows Cross-Site Scripting (XSS) gitops-1.14 openshift-gitops-1/argocd-rhel9: Improper URL Sanitization in Argo CD Repository Page Allows Cross-Site Scripting (XSS) gitops-1.14 openshift-gitops-operator-container: Namespace Isolation Break gitops-1.14 openshift-gitops-dex-container: Unexpected memory consumption during token parsing in golang.org/x/oauth2 gitops-1.14 openshift-gitops-container: Potential denial of service in golang.org/x/crypto gitops-1.14 openshift-gitops-argo-rollouts-container: net/http, x/net/http2: unlimited number of CONTINUATION frames causes DoS gitops-1.14 openshift-gitops-argocd-container: jwt-go allows excessive memory allocation during header parsing gitops-1.14 openshift-gitops-argocd-rhel9-container: jwt-go allows excessive memory allocation during header parsing gitops-1.14 openshift-gitops-argocd-container: Prototype Pollution in redoc gitops-1.14 openshift-gitops-argocd-rhel9-container: Prototype Pollution in redoc gitops-1.14
Errata Advisory for Red Hat OpenShift GitOps 1.15.3 security release.Security Fix(es): openshift-gitops-argocd-container: Improper URL Sanitization in Argo CD Repository Page Allows Cross-Site Scripting (XSS) gitops-1.15 openshift-gitops-1/argocd-rhel9: Improper URL Sanitization in Argo CD Repository Page Allows Cross-Site Scripting (XSS) gitops-1.15 openshift-gitops-1/gitops-operator-bundle: Improper URL Sanitization in Argo CD Repository Page Allows Cross-Site Scripting (XSS) gitops-1.15
Errata Advisory for Red Hat OpenShift GitOps v1.16.1 security release.Security Fix(es): openshift-gitops-argocd-container: Improper URL Sanitization in Argo CD Repository Page Allows Cross-Site Scripting (XSS) gitops-1.16 openshift-gitops-1/gitops-operator-bundle: Improper URL Sanitization in Argo CD Repository Page Allows Cross-Site Scripting (XSS) gitops-1.16
Errata Advisory for Red Hat OpenShift GitOps 1.15.2 release<br>Security Fix(es):<br><li> openshift-gitops-operator-container: Namespace Isolation Break gitops-1.15 </li> <li> openshift-gitops-argocd-container: Go JOSE's Parsing Vulnerable to Denial of Service gitops-1.15 </li> <li> openshift-gitops-argocd-rhel9-container: Go JOSE's Parsing Vulnerable to Denial of Service gitops-1.15 </li> <li> openshift-gitops-dex-container: Go JOSE's Parsing Vulnerable to Denial of Service gitops-1.15 </li> <li> openshift-gitops-operator-bundle-container: Go JOSE's Parsing Vulnerable to Denial of Service gitops-1.15 </li> <li> openshift-gitops-container: Potential denial of service in golang.org/x/crypto gitops-1.15 </li> <li> openshift-gitops-argo-rollouts-container: net/http, x/net/http2: unlimited number of CONTINUATION frames causes DoS gitops-1.15 </li> <li> openshift-gitops-argocd-container: Memory Exhaustion in Expr Parser with Unrestricted Input gitops-1.15 </li> <li> openshift-gitops-argocd-rhel9-container: Memory Exhaustion in Expr Parser with Unrestricted Input gitops-1.15 </li> <li> openshift-gitops-argocd-container: jwt-go allows excessive memory allocation during header parsing gitops-1.15 </li> <li> openshift-gitops-argocd-rhel9-container: jwt-go allows excessive memory allocation during header parsing gitops-1.15 </li> <li> openshift-gitops-operator-bundle-container: jwt-go allows excessive memory allocation during header parsing gitops-1.15 </li> <li> openshift-gitops-argocd-container: Prototype Pollution in redoc gitops-1.15 </li> <li> openshift-gitops-argocd-rhel9-container: Prototype Pollution in redoc gitops-1.15 </li> <li> openshift-gitops-dex-container: Unexpected memory consumption during token parsing in golang.org/x/oauth2 gitops-1.15</li> For more details about the security issue(s), including the impact, a CVSS<br>score, acknowledgments, and other related information, refer to the CVE page(s)<br>listed in the References section.
A user can create a project named "myProject", use that project for a while and then delete it. After the original project is deleted, another user can create a project called "myProject". Since the subjectaccessreview will now pass for this second user, they will be able to access metrics from the original project.
The deployment script in the unsupported "OpenShift Extras" set of add-on scripts, in Red Hat Openshift 1, installs a default public key in the root user's authorizedkeys file.
In Red Hat Openshift 1, weak default permissions are applied to the /etc/openshift/serverpriv.pem file on the broker server, which could allow users with local access to the broker to read this file.
Description of the problem: The response header has not enabled X-FRAME-OPTIONS, Which helps prevents against Clickjacking attack. Clickjacking, also known as a 'UI redress attack', is when an attacker uses multiple transparent or opaque layers to trick a user into clicking on a button or link on another page when they were intending to click on the top level page. Thus, the attacker is 'hijacking' clicks meant for their page and routing them to other another page, most likely owned by another application, domain, or both.
Release version: 2.4.4
Operator snapshot version: Unknown
OCP version: 4.9
Browser Info: Unknown
Steps to reproduce: 1. Login into the application Using "admin1" user 2. Navigate to search >> filter 3. Intercept the request using a proxy tool 4. Apply attack value in parameter Parameter: filters Attack Value: [{"property":"kind","values":["test"]},{"property":"'b) OR (1","values":["1'"]}
Actual results:
Expected results:
Additional info:
A flaw was found in Openshift. A pod with a DNSPolicy of "ClusterFirst" may incorrectly resolve the hostname based on a service provided. This flaw allows an attacker to supply an incorrect name with the DNS search policy, affecting confidentiality and availability.
Description of problem: HTTP Strict Transport Security (HSTS) is an opt-in security enhancement that is specified by a web application through the use of a special response header. Once a supported browser receives this header, it will prevent communications from being sent over HTTP to the specified domain and will instead send all communications over HTTPS. It also prevents HTTPS click through prompts on browsers.
Version-Release number of selected component (if applicable): 4.9
How reproducible:
Steps to Reproduce: 1. 2. 3.
Actual results:
Expected results: All data that is shared between windows must have explicit origins to avoid eavesdropping. It is recommended to avoid using "" for the "targetOrigin" in order to prevent a broadcast of the information. It is also important to validate any message that is received from another window.
Additional info:
Moderate: Red Hat OpenShift Service Mesh Containers for 2.5.10
IBM Robotic Process Automation for Cloud Pak 20.12 through 21.0.3 is vulnerable to broken access control. A user is not correctly redirected to the platform log out screen when logging out of IBM RPA for Cloud Pak. IBM X-Force ID: 239081.
IBM Robotic Process Automation 20.12 through 21.0.6 could allow an attacker with physical access to the system to obtain highly sensitive information from system memory. IBM X-Force ID: 238053.
IBM Robotic Process Automation 20.12 through 21.0.6 is vulnerable to exposure of the name and email for the creator/modifier of platform level objects. IBM X-Force ID: 238678.
The Birthday attack against 64-bit block ciphers (CVE-2016-2183) was reported for the health checks port (9979) on the etcd grpc-proxy component. Even though the CVE-2016-2183 has been fixed in the etcd components, to enable periodic health checks from kubelet, it was necessary to open up a new port (9979) on etcd grpc-proxy. Therefore, this port might still be considered vulnerable to the same type of attack. The health checks on etcd grpc-proxy do not contain sensitive data, only metrics data. The potential impact related to this vulnerability is minimal. The CVE-2023-0296 has been assigned to this issue to track the permanent fix in the etcd component.
IBM Robotic Process Automation 20.12.0 through 21.0.2 defaults to HTTP in some RPA commands when the prefix is not explicitly specified in the URL. This could allow an attacker to obtain sensitive information using man in the middle techniques. IBM X-Force ID: 244109.
IBM Robotic Process Automation for Cloud Pak 20.12.0 through 21.0.4 is vulnerable to cross-site scripting. This vulnerability allows users to embed arbitrary JavaScript code in the Web UI thus altering the intended functionality potentially leading to credentials disclosure within a trusted session. IBM X-Force ID: 244075.
IBM Robotic Process Automation for Cloud Pak 21.0.1 through 21.0.4 could allow a local user to perform unauthorized actions due to insufficient permission settings. IBM X-Force ID: 244073.
A flaw was found in github.com/openshift/apiserver-library-go, used in OpenShift 4.12 and 4.11, that contains an issue that can allow low-privileged users to set the seccomp profile for pods they control to "unconfined." By default, the seccomp profile used in the restricted-v2 Security Context Constraint (SCC) is "runtime/default," allowing users to disable seccomp for pods they can create and modify.