| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Applications and libraries which misuse connection.serverAuthenticate (via callback field ServerConfig.PublicKeyCallback) may be susceptible to an authorization bypass. The documentation for ServerConfig.PublicKeyCallback says that "A call to this function does not guarantee that the key offered is in fact used to authenticate." Specifically, the SSH protocol allows clients to inquire about whether a public key is acceptable before proving control of the corresponding private key. PublicKeyCallback may be called with multiple keys, and the order in which the keys were provided cannot be used to infer which key the client successfully authenticated with, if any. Some applications, which store the key(s) passed to PublicKeyCallback (or derived information) and make security relevant determinations based on it once the connection is established, may make incorrect assumptions. For example, an attacker may send public keys A and B, and then authenticate with A. PublicKeyCallback would be called only twice, first with A and then with B. A vulnerable application may then make authorization decisions based on key B for which the attacker does not actually control the private key. Since this API is widely misused, as a partial mitigation golang.org/x/cry...@v0.31.0 enforces the property that, when successfully authenticating via public key, the last key passed to ServerConfig.PublicKeyCallback will be the key used to authenticate the connection. PublicKeyCallback will now be called multiple times with the same key, if necessary. Note that the client may still not control the last key passed to PublicKeyCallback if the connection is then authenticated with a different method, such as PasswordCallback, KeyboardInteractiveCallback, or NoClientAuth. Users should be using the Extensions field of the Permissions return value from the various authentication callbacks to record data associated with the authentication attempt instead of referencing external state. Once the connection is established the state corresponding to the successful authentication attempt can be retrieved via the ServerConn.Permissions field. Note that some third-party libraries misuse the Permissions type by sharing it across authentication attempts; users of third-party libraries should refer to the relevant projects for guidance. |
| DISPUTE NOTE: this issue does not pose a security risk as it (according to analysis by the original software developer, NLnet Labs) falls within the expected functionality and security controls of the application. Red Hat has made a claim that there is a security risk within Red Hat products. NLnet Labs has no further information about the claim, and suggests that affected Red Hat customers refer to available Red Hat documentation or support channels. ORIGINAL DESCRIPTION: A heap-buffer-overflow flaw was found in the cfg_mark_ports function within Unbound's config_file.c, which can lead to memory corruption. This issue could allow an attacker with local access to provide specially crafted input, potentially causing the application to crash or allowing arbitrary code execution. This could result in a denial of service or unauthorized actions on the system. |
| Async <= 2.6.4 and <= 3.2.5 are vulnerable to ReDoS (Regular Expression Denial of Service) while parsing function in autoinject function. NOTE: this is disputed by the supplier because there is no realistic threat model: regular expressions are not used with untrusted input. |
| gorilla/schema converts structs to and from form values. Prior to version 1.4.1 Running `schema.Decoder.Decode()` on a struct that has a field of type `[]struct{...}` opens it up to malicious attacks regarding memory allocations, taking advantage of the sparse slice functionality. Any use of `schema.Decoder.Decode()` on a struct with arrays of other structs could be vulnerable to this memory exhaustion vulnerability. Version 1.4.1 contains a patch for the issue. |
| The Bare Metal Operator (BMO) implements a Kubernetes API for managing bare metal hosts in Metal3. Baremetal Operator enables users to load Secret from arbitrary namespaces upon deployment of the namespace scoped Custom Resource `BMCEventSubscription`. Prior to versions 0.8.1 and 0.9.1, an adversary Kubernetes account with only namespace level roles (e.g. a tenant controlling a namespace) may create a `BMCEventSubscription` in his authorized namespace and then load Secrets from his unauthorized namespaces to his authorized namespace via the Baremetal Operator, causing Secret Leakage. The patch makes BMO refuse to read Secrets from other namespace than where the corresponding BMH resource is. The patch does not change the `BMCEventSubscription` API in BMO, but stricter validation will fail the request at admission time. It will also prevent the controller reading such Secrets, in case the BMCES CR has already been deployed. The issue exists for all versions of BMO, and is patched in BMO releases v0.9.1 and v0.8.1. Prior upgrading to patched BMO version, duplicate any existing Secret pointed to by `BMCEventSubscription`'s `httpHeadersRef` to the same namespace where the corresponding BMH exists. After upgrade, remove the old Secrets. As a workaround, the operator can configure BMO RBAC to be namespace scoped, instead of cluster scoped, to prevent BMO from accessing Secrets from other namespaces, and/or use `WATCH_NAMESPACE` configuration option to limit BMO to single namespace. |
| Expr is an expression language and expression evaluation for Go. Prior to version 1.17.0, if the Expr expression parser is given an unbounded input string, it will attempt to compile the entire string and generate an Abstract Syntax Tree (AST) node for each part of the expression. In scenarios where input size isn’t limited, a malicious or inadvertent extremely large expression can consume excessive memory as the parser builds a huge AST. This can ultimately lead to*excessive memory usage and an Out-Of-Memory (OOM) crash of the process. This issue is relatively uncommon and will only manifest when there are no restrictions on the input size, i.e. the expression length is allowed to grow arbitrarily large. In typical use cases where inputs are bounded or validated, this problem would not occur. The problem has been patched in the latest versions of the Expr library. The fix introduces compile-time limits on the number of AST nodes and memory usage during parsing, preventing any single expression from exhausting resources. Users should upgrade to Expr version 1.17.0 or later, as this release includes the new node budget and memory limit safeguards. Upgrading to v1.17.0 ensures that extremely deep or large expressions are detected and safely aborted during compilation, avoiding the OOM condition. For users who cannot immediately upgrade, the recommended workaround is to impose an input size restriction before parsing. In practice, this means validating or limiting the length of expression strings that your application will accept. For example, set a maximum allowable number of characters (or nodes) for any expression and reject or truncate inputs that exceed this limit. By ensuring no unbounded-length expression is ever fed into the parser, one can prevent the parser from constructing a pathologically large AST and avoid potential memory exhaustion. In short, pre-validate and cap input size as a safeguard in the absence of the patch. |
| A flaw was found in OpenShift Console. A Server Side Request Forgery (SSRF) attack can happen if an attacker supplies all or part of a URL to the server to query. The server is considered to be in a privileged network position and can often reach exposed services that aren't readily available to clients due to network filtering. Leveraging such an attack vector, the attacker can have an impact on other services and potentially disclose information or have other nefarious effects on the system.
The /api/dev-console/proxy/internet endpoint on the OpenShift Console allows authenticated users to have the console's pod perform arbitrary and fully controlled HTTP(s) requests. The full response to these requests is returned by the endpoint.
While the name of this endpoint suggests the requests are only bound to the internet, no such checks are in place. An authenticated user can therefore ask the console to perform arbitrary HTTP requests from outside the cluster to a service inside the cluster. |
| In MIT Kerberos 5 (aka krb5) before 1.22 (with incremental propagation), there is an integer overflow for a large update size to resize() in kdb_log.c. An authenticated attacker can cause an out-of-bounds write and kadmind daemon crash. |
| A security issue was discovered in Kubernetes clusters with Windows nodes where BUILTIN\Users may be able to read container logs and NT AUTHORITY\Authenticated Users may be able to modify container logs. |
| The Bare Metal Operator (BMO) implements a Kubernetes API for managing bare metal hosts in Metal3. The `BareMetalHost` (BMH) CRD allows the `userData`, `metaData`, and `networkData` for the provisioned host to be specified as links to Kubernetes Secrets. There are fields for both the `Name` and `Namespace` of the Secret, meaning that versions of the baremetal-operator prior to 0.8.0, 0.6.2, and 0.5.2 will read a `Secret` from any namespace. A user with access to create or edit a `BareMetalHost` can thus exfiltrate a `Secret` from another namespace by using it as e.g. the `userData` for provisioning some host (note that this need not be a real host, it could be a VM somewhere).
BMO will only read a key with the name `value` (or `userData`, `metaData`, or `networkData`), so that limits the exposure somewhat. `value` is probably a pretty common key though. Secrets used by _other_ `BareMetalHost`s in different namespaces are always vulnerable. It is probably relatively unusual for anyone other than cluster administrators to have RBAC access to create/edit a `BareMetalHost`. This vulnerability is only meaningful, if the cluster has users other than administrators and users' privileges are limited to their respective namespaces.
The patch prevents BMO from accepting links to Secrets from other namespaces as BMH input. Any BMH configuration is only read from the same namespace only. The problem is patched in BMO releases v0.7.0, v0.6.2 and v0.5.2 and users should upgrade to those versions. Prior upgrading, duplicate the BMC Secrets to the namespace where the corresponding BMH is. After upgrade, remove the old Secrets. As a workaround, an operator can configure BMO RBAC to be namespace scoped for Secrets, instead of cluster scoped, to prevent BMO from accessing Secrets from other namespaces. |
| Calling Parse on a "// +build" build tag line with deeply nested expressions can cause a panic due to stack exhaustion. |
| Calling Decoder.Decode on a message which contains deeply nested structures can cause a panic due to stack exhaustion. This is a follow-up to CVE-2022-30635. |
| A flaw was found in kube-controller-manager. This issue occurs when the initial application of a HPA config YAML lacking a .spec.behavior.scaleUp block causes a denial of service due to KCM pods going into restart churn. |
| A flaw was found in CIRCL's implementation of the FourQ elliptic curve. This vulnerability allows an attacker to compromise session security via low-order point injection and incorrect point validation during Diffie-Hellman key exchange. |
| A flaw was found in Hibernate Reactive. When an HTTP endpoint is exposed to perform database operations, a remote client can prematurely close the HTTP connection. This action may lead to leaking connections from the database connection pool, potentially causing a Denial of Service (DoS) by exhausting available database connections. |
| Improper finite state machines (FSMs) in hardware logic in some Intel(R) Processors may allow an privileged user to potentially enable a denial of service via local access. |
| A flaw was found in QEMU in the uefi-vars virtual device. When the guest writes to register UEFI_VARS_REG_BUFFER_SIZE, the .write callback `uefi_vars_write` is invoked. The function allocates a heap buffer without zeroing the memory, leaving the buffer filled with residual data from prior allocations. When the guest later reads from register UEFI_VARS_REG_PIO_BUFFER_TRANSFER, the .read callback `uefi_vars_read` returns leftover metadata or other sensitive process memory from the previously allocated buffer, leading to an information disclosure vulnerability. |
| golang-jwt is a Go implementation of JSON Web Tokens. Starting in version 3.2.0 and prior to versions 5.2.2 and 4.5.2, the function parse.ParseUnverified splits (via a call to strings.Split) its argument (which is untrusted data) on periods. As a result, in the face of a malicious request whose Authorization header consists of Bearer followed by many period characters, a call to that function incurs allocations to the tune of O(n) bytes (where n stands for the length of the function's argument), with a constant factor of about 16. This issue is fixed in 5.2.2 and 4.5.2. |
| There's a vulnerability in the CRI-O application where when container is launched with securityContext.runAsUser specifying a non-existent user, CRI-O attempts to create the user, reading the container's entire /etc/passwd file into memory. If this file is excessively large, it can cause the a high memory consumption leading applications to be killed due to out-of-memory. As a result a denial-of-service can be achieved, possibly disrupting other pods and services running in the same host. |
| An incomplete fix was shipped for the Rapid Reset (CVE-2023-44487/CVE-2023-39325) vulnerability for an OpenShift Containers. |
