Antony Di Scala

**Name of the Vulnerable Software and Affected Versions** KServe ModelMesh container images (affected versions not specified) **Description** A container privilege escalation flaw exists due to the /etc/passwd file being created with group-writable permissions during the build process. An attacker with the ability to execute commands within an affected container, even as a non-root user, can exploit their root group membership to modify the /etc/passwd file. This allows the addition of a new user with an arbitrary UID, potentially including UID 0, resulting in full root privileges within the container. **Recommendations** At the moment, there is no information about a newer version that contains a fix for this vulnerability.

Name of the Vulnerable Software and Affected Versions: mirror-registry (affected versions not specified) Description: The mirror-registry does not properly sanitize the host header HTTP header in received HTTP requests, which allows an attacker to perform malicious redirects to attacker-controlled domains or phishing campaigns. Recommendations: At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** Operator-SDK versions prior to 0.15.2 **Description** Early versions of Operator-SDK included an insecure method for operator containers to run in environments utilizing a random UID. A script, `user setup`, modified the permissions of the `/etc/passwd` file to 664 during build time. An attacker executing commands within an affected container, even as a non-root user, could leverage root group membership to modify the `/etc/passwd` file. This could allow the addition of a new user with an arbitrary UID, potentially including UID 0, resulting in full root privileges within the container. **Recommendations** Update to Operator-SDK version 0.15.2 or later. If using an older version, ensure the insecure `user setup` script is not used during container image builds.

**Name of the Vulnerable Software and Affected Versions** OpenShift Mirror Registry (affected versions not specified) **Description** A flaw was found in the Mirror Registry. The quay-app container shipped as part of the Mirror Registry for OpenShift has write access to the `/etc/passwd` file. This flaw allows a malicious actor with access to the container to modify the passwd file and elevate their privileges to the root user within that pod. **Recommendations** At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** OpenShift Service Mesh versions 2.5.6 through 2.6.3 **Description** A flaw was found in OpenShift Service Mesh due to improper HTTP header sanitization in Envoy. This may lead to rate-limiter avoidance, access-control bypass, CPU and memory exhaustion, and replay attacks. **Recommendations** For versions 2.5.6 and 2.6.3, consider disabling the Envoy HTTP header handling functionality until a patch is available. Restrict access to the Envoy module to minimize the risk of exploitation. Avoid using unsanitized HTTP headers in the affected API endpoints until the issue is resolved.

**Name of the Vulnerable Software and Affected Versions** OpenShift Service Mesh versions 2.5.6 through 2.6.3 **Description** The issue occurs due to improper sanitization of HTTP headers by Envoy, particularly the `x-forwarded-for` header. This lack of sanitization can allow attackers to inject malicious payloads into service mesh logs, leading to log injection and spoofing attacks. Such injections can mislead logging mechanisms, enabling attackers to manipulate log entries or execute reflected cross-site scripting (XSS) attacks. **Recommendations** For OpenShift Service Mesh version 2.5.6, update to a version that properly sanitizes HTTP headers. For OpenShift Service Mesh version 2.6.3, update to a version that properly sanitizes HTTP headers. As a temporary workaround, consider restricting access to the `x-forwarded-for` header to minimize the risk of exploitation.