Adam Korczynski

A flaw was found in the OIDC logout endpoint of the keycloak-services component, which handles user session termination in Red Hat Build of Keycloak. The issue occurs because the system sets a session cookie based on an unvalidated token hint before completing security checks. An attacker can use this flaw to fix a session ID in a victim's browser, allowing them to hijack the victim's subsequent login and gain full control over their account.

Improper validation of RunEndEncoded arrays in the ArrayData interface allows reading data beyond the bounds of the child values array. This occurs during the validation of RunEndEncoded arrays via the `ArrayData::validate values` function, which can lead to an out-of-bounds read when accessing the last value through APIs such as `TypedRunArray::value`.

Docker Engine classifies a registry hostname as insecure using an any-match DNS check. The `loadInsecureRegistries()` function injects 127.0.0.0/8 and ::1/128 as insecure CIDRs by default. The `isCIDRMatch()` function resolves all addresses for a hostname and returns true if any single address is within the insecure CIDR list. Since the transport re-dials the hostname instead of the specific CIDR-matching address, a DNS response containing both a loopback IP and an attacker-controlled IP disables certificate verification and enables HTTP fallback for the registry connection. This allows an attacker who can influence DNS to skip TLS certificate verification and force a fallback to HTTP, potentially exposing registry credentials and enabling image substitution.

An issue exists where the software fails to parse Markdown autolinks containing unmatched trailing closing parentheses in linear time. This allows an authenticated user with permissions to create posts to cause excessive server CPU consumption and degrade service availability for other users by submitting specially crafted post or message attachment content.

An authenticated attacker can cause a denial of service by uploading a specially crafted animated GIF as a custom emoji. This occurs because the system fails to limit the number of frames and does not enforce the file size cap during the upload process.

When deserializing untrusted or corrupted data, it is possible for a reader to consume memory beyond the allowed constraints and thus lead to out of memory on the system. This issue affects Java applications using Apache Avro Java SDK. An unauthenticated attacker can expose assets in the environment susceptible to exploitation, with no impact to confidentiality, no impact to integrity, high impact to availability, and requires no user interaction.

An attacker who has compromised a registry can cause users to verify the wrong artifact. This issue allows an attacker to lead a user into verifying the wrong artifact if they control or compromise a registry.

An attacker who has compromised a registry and added a high number of signatures to an artifact can cause denial of service of services on the machine, if a user runs `notation verify` command on the same machine. This issue can be exploited by making the registry serve an infinite number of signatures for the artifact. The `maxSignatureAttempts` in `notation verify` enables this endless data attack.

The issue causes excessive memory consumption when verifying signatures, leading to application crashes and impacting availability. Users can review their trust policy file for the identity string containing `=#` and ensure only trusted certificates are in their trust stores with `authenticity` validation set to `enforce`.

The issue is related to the import of OCI images in containerd, where there was no limit on the number of bytes read for certain files. A maliciously crafted image with a large file could cause a denial of service.

The issue is related to the ParseAcceptLanguage function, which can be exploited to cause a denial of service by crafting a specific Accept-Language header. This header can cause the function to take significant time to parse, leading to a denial of service. The problem is due to the quadratic time complexity of the BCP 47 tag parser, which is exposed to untrusted user input. The estimated number of potentially affected devices worldwide is not available. There is no information about real-world incidents where this issue was exploited.

Programs that compile regular expressions from untrusted sources may be vulnerable to memory exhaustion or denial of service. The parsed regexp representation is linear in the size of the input, but in some cases, the constant factor can be as high as 40,000, making relatively small regexps consume much larger amounts of memory. After the fix, each regexp being parsed is limited to a 256 MB memory footprint. Regular expressions whose representation would use more space than that are rejected. Normal use of regular expressions is unaffected.

The issue is related to the Reader.Read function not setting a limit on the maximum size of file headers. A maliciously crafted archive could cause Reader.Read to allocate unbounded amounts of memory, potentially causing resource exhaustion or panics. After the fix, Reader.Read limits the maximum size of header blocks to 1 MiB.

The issue is a cross-site scripting (XSS) bug that could allow an attacker to inject arbitrary JavaScript in the "/auth/callback" page in a victim's browser. This vulnerability only affects Argo CD instances with single sign-on (SSO) enabled. The exploit requires the attacker to have access to the API server's encryption key, a method to add a cookie to the victim's browser, and the ability to convince the victim to visit a malicious "/auth/callback" link. The vulnerability is classified as low severity because access to the API server's encryption key already grants a high level of access.

The issue is related to an improper certificate validation bug in Argo CD, which could cause it to trust a malicious OpenID Connect (OIDC) provider. This bug affects connections to OIDC providers and can be exploited by an attacker to conduct spoofing attacks. The vulnerability is related to the skipping of certificate verification when communicating with the OIDC provider, which opens Argo CD to various risks, such as a machine-in-the-middle attack.

The CloudCore Router in KubeEdge does not impose a limit on the size of responses to requests made by the REST handler, allowing an attacker to make a request that will return an HTTP response with a large body and cause a denial of service. This can occur when the `router` module is enabled in the config file `cloudcore.yaml`. Only an authenticated user of the cloud can make an attack. The consequence of the exhaustion is that CloudCore will be in a denial of service.

A large response received by the viaduct WSClient can cause a denial of service (DoS) from memory exhaustion. The entire body of the response is being read into memory, which could allow an attacker to send a request that returns a response with a large body. The consequence of the exhaustion is that the process which invokes a WSClient will be in a denial of service. This issue affects users who are authenticated to the edge side and connect to `cloudhub` from the edge side through WebSocket protocol.

The ServiceBus server on the edge side may be susceptible to a DoS attack if an HTTP request containing a very large Body is sent to it. It is possible for the node to be exhausted of memory, causing a denial of service for other services on the node, such as other containers. This issue can be exploited by malicious apps that have access to send HTTP requests to localhost, but only when the `ServiceBus` module is enabled in the config file `edgecore.yaml`.

KubeEdge is an open source system for extending native containerized application orchestration capabilities to hosts at Edge. Several endpoints in the Cloud AdmissionController, including "/devicemodels", "/rules", "/ruleendpoints", and "/offlinemigration", may be susceptible to a DoS attack if an HTTP request containing a very large Body is sent to it. The consequence of the exhaustion is that the Cloud AdmissionController will be in denial of service. Only an authenticated user can cause this issue.

EdgeCore may be susceptible to a DoS attack on CloudHub if an attacker sends a well-crafted HTTP request to "/edge.crt". If the request has a very large body, it can crash the HTTP service through a memory exhaustion vector. The request body is being read into memory, and a body larger than the available memory can lead to a successful attack. Only authorized users can perform this attack, as the request must pass through authorization. The consequence of the exhaustion is that CloudHub will be in denial of service. This issue affects KubeEdge only when the CloudHub module is enabled in the file `cloudcore.yaml`.