CVE Vulnerability Catalog

vm2 before 3.12.2 does not apply its Buffer backing-store ownership invariant (byteOffset === 0 and buffer.byteLength === length) to Buffers returned from host builtin modules. When an application exposes Node's zlib module through NodeVM's builtin allowlist, zlib.deflateSync can return a Buffer backed by Node's shared small-buffer pool whose .buffer is the entire pool. Untrusted guest code can construct a full-width view of that ArrayBuffer to read and modify bytes belonging to unrelated host buffers.

vm2 before 3.12.2 does not apply host-side Promise rejection handling in the sandbox-to-host construct trap. In BaseHandler, the apply trap calls markHostPromiseHandled() on the returned value, but the adjacent construct path returns the result of Reflect.construct without the same sanitization. If an embedder exposes a constructable host function whose constructor returns a native rejected Promise, an untrusted script executed via VM.run can invoke it with `new` and ignore the result; the rejected host Promise crosses the bridge unhandled and, under Node's strict unhandled-rejection policy, is promoted to an uncaught exception that terminates the host process.

A vulnerability in vm2 before 3.12.2 allows an authorization bypass in the NodeVM external-module resolver. When an embedder configures `require.external` with a custom resolver and `context: 'host'`, guest code can require an allowlisted module and then an absolute path of a non-allowlisted sibling sharing the resolved prefix. This leads to a sandbox escape and arbitrary code execution in the host process.

Contrast versions before 1.4.1 — a recovering Coordinator does not verify the seed supplied by the recovering party. An attacker can stand up a rogue Coordinator whose manifest passes validation but whose secret seed is attacker-controlled. If network traffic is redirected from the legitimate Coordinator to the attacker's Coordinator, a workload owner can be impersonated when they set a new manifest without comparing the returned root CA certificate against the existing one or verify the Coordinator without comparing the root CA certificate against a trusted reference.

Contrast (Edgeless Systems) before 1.8.1 logs the workload secret to stderr, and thus to Kubernetes logs, when the Contrast initializer is configured with CONTRAST_LOG_LEVEL set to info or debug. Because info is the default, all installations that do not customize the initializer log level are affected. This exposes workload secrets to Kubernetes users with get or list permission on pods/logs and to anyone with read access to the Kubernetes log storage, such as the cloud provider.

Contrast, Edgeless Systems' runtime for confidential containers on Kubernetes, is affected in versions up to and including 1.9.0. The VOLUME directive in a Dockerfile (config.volumes in the OCI image configuration) is only a hint and is not handled specially by Kubernetes, but containerd adds a mount point for it when Kubernetes sets none, requiring the runtime to be able to push arbitrary data to the Kata agent. As a result, on bare-metal Contrast deployments (AKS deployments are not affected) that run an image declaring at least one VOLUME for which no Kubernetes mount exists at that path, the untrusted host can write arbitrary file trees below that mount point inside the confidential container, compromising the integrity of a directory that is typically important to the application's core functionality.

Edgelesssys Contrast is a confidential-computing runtime for Kubernetes. In versions 1.9.0 before 1.12.2, the initializer logs the full NewMeshCert response — which contains the workload secret — to standard output at INFO level. As a result, workload secrets are exposed to any Kubernetes user with get or list permission on pods/logs. Because workload secrets are used for encrypted storage and Vault integration, those must also be considered compromised.

Contrast, a Kubernetes runtime for confidential containers, before version 1.12.1 has a vulnerability in the secure persistent volume feature. A malicious host can supply a crafted LUKS2 volume to a pod VM. LUKS2 volume metadata is not authenticated and, with cryptsetup versions prior to 2.8.1, a header specifying the null keyslot encryption algorithm (cipher_null-ecb) is accepted without error. Because the Contrast Initializer assumes a device is protected if `cryptsetup open` succeeds with the secret seed, the guest will open the attacker-supplied volume and write secret data in plaintext, or under a volume key known to the attacker, allowing the host to read confidential data that should have been encrypted.

A vulnerability in D-Link DIR-895L A1_102b07 affects the tunnel_set_params function in tunnel.c of the L2TP Control Channel Parser component. Manipulation results in an out-of-bounds write. The attack can be initiated remotely, and the exploit is now public.

A SQL injection vulnerability was detected in CloudClassroom-PHP-Project in the viewresult.php file, triggered by manipulating the seno argument. The flaw can be exploited remotely and a public exploit is already available. The product follows a rolling release model, so no specific version details are provided, and the vendor did not respond to the disclosure.

Uncontrolled resource consumption (CWE-400) in Elasticsearch can lead to denial of service via excessive allocation (CAPEC-130).

Uncontrolled resource consumption (CWE-400) in Kibana can lead to denial of service via excessive allocation (CAPEC-130).

Uncontrolled resource consumption (CWE-400) in Elasticsearch can lead to denial of service via excessive allocation (CAPEC-130).

Uncontrolled resource consumption (CWE-400) in Elasticsearch can lead to denial of service via excessive allocation (CAPEC-130).

Uncontrolled resource consumption (CWE-400) in Elasticsearch can lead to denial of service via excessive allocation (CAPEC-130).

Uncontrolled resource consumption (CWE-400) in Elasticsearch can lead to denial of service via excessive allocation (CAPEC-130).

Uncontrolled resource consumption (CWE-400) in Elasticsearch can lead to denial of service via excessive allocation (CAPEC-130).

Uncontrolled resource consumption (CWE-400) in Elasticsearch can lead to denial of service via excessive allocation (CAPEC-130).

Missing authorization (CWE-862) in Kibana can lead to unauthorized deletion of data via exploiting incorrectly configured access control security levels (CAPEC-180). An authenticated user holding Synthetics privileges scoped to a single Kibana space could permanently delete Synthetics monitors that are shared into spaces they have no access to. Where a monitor is associated with a private location, the same operation also destroys the underlying Elastic Agent integration configuration without the authorization checks that Fleet would otherwise apply.

Kibana Agent Builder is affected by a Confused Deputy vulnerability (CWE-441) that can lead to privilege escalation. A non-administrative user able to edit a shared agent could cause privileged operations to be performed under the identity of a higher-privileged user. If the same user can also author workflows, this can extend to full administrative control of Kibana and the Elasticsearch cluster.