Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
9 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
ciphertextContainer.UnmarshalJSON decodes the third :-separated component of a vault:vX:base64... ciphertext and then unconditionally takes a 12-byte prefix slice for the AES-GCM nonce: c.nonce = fullCiphertext[:aesGCMNonceSize]. If the decoded blob is shorter than 12 bytes, the slice expression panics. The panic happens before any cryptographic operation, while the JSON body of the request is still being parsed inside the request handler. Because the handler is invoked from net/http's standard handler goroutine, the panic is recovered to a 500 response, but the request handler aborts mid-execution and the recovered panic appears in the Coordinator's logs. An authenticated workload that holds a valid mesh certificate for any WorkloadSecretID can trigger the panic at will, producing log spam, request-failure metrics, and a slow but cheap denial of service against the transit-engine endpoint. Details the panicking slice coordinator/internal/transitengineapi/crypto.go:64-88:…
Recommended action: Upgrade to 1.21.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Config.registryFor selected a per-registry credential / CA / mirror block by checking strings.HasSuffix(name, fqdn) after stripping a single trailing dot. The match has no boundary between the configured FQDN and any preceding characters in the request hostname. A registry configured as [registries."ghcr.io."] is therefore also applied to any image pulled from a host whose name happens to end in the literal byte sequence ghcr.io, including attacker-registered domains such as evilghcr.io. The imagepuller would then send the configured Authorization header (basic auth, registry token, or identity token), trust the configured custom CA bundle, follow the configured mirror, or honour insecure-skip-verify, on requests to that hostname. Prerequisites For this to be applicable, an image or layer must be pulled from a "sibling" domain ending in one of the FQDNs configured in the imagepuller config. This may occur due to malicious intent or coincidentally. Impact - Authentication…
Recommended action: Upgrade to 1.21.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact The Kata agent policies generated by the Contrast CLI had an issue in the CopyFile verification, which allowed arbitrary writes to the guest root filesytem. A malicious process on the host with the capability to connect to the Kata agent VSOCK could connect to the agent and issue a series of CopyFile requests to overwrite security-critical files or trick the workload into disclosing sensitive data, which effectively amounts to a full guest takeover. Patches This issue has been patched in Contrast v1.19.1. Note that this fix does not change the fact that host-provided content is generally not trustworthy, as documented. Workarounds If upgrading is not possible, users can implement the fix in rego and pass it to contrast generate --policy. The rego-only fix is a bit trickier than the patch, because the data to check is binary. See the references for details. Resources Upstream GHSA: https://github.com/kata-containers/kata-containers/security/advisories/GHSA-q49m-57vm-c8cc…
Recommended action: Upgrade to 1.19.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
BadAML BadAML is an AML injection attack that exploits the ACPI interface and allows arbitrary code execution in a confidential VM. The attack was first published in 2024: - <https://blackhat.com/eu-24/briefings/schedule/#aml-injection-attacks-on-confidential-vms-42723 - <https://dl.acm.org/doi/pdf/10.1145/3719027.3765123 Impact An attacker with control over the host (which is assumed in the attacker model of Contrast) can execute malicious AML code to gain arbitrary code execution within the confidential guest. AML is byte code embedded in ACPI tables that are passed from the host (QEMU) to the guest firmware (OVMF), and then passed from OVMF to the Linux kernel. The Linux kernel has an interpreter that executes the AML code. An attacker can craft a table with malicious AML code and the kernel will execute it. AML is Turing-complete and the interpreter has access to the full guest memory, including private pages. See the paper for a detailed description and background of the attack.…
Recommended action: Upgrade to 1.18.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A malicious host may provide a crafted LUKS2 volume to a Contrast pod VM that uses the secure persistent volume feature. The guest will open the volume and write secret data using a volume key known to the attacker. LUKS2 volume metadata is (a) not authenticated and (b) supports null key-encryption algorithms, allowing an attacker to create a volume such that the volume: - Opens (cryptsetup open) without error using any passphrase or token - Records all writes in plaintext (or ciphertext with an attacker-known key) Details Contrast uses cryptsetup to setup secure persistent volumes, using the secret seed as key for the cryptsetup encryption. To do so the Contrast Initializer will invoke the cryptsetup CLI. If the device provided by Kubernetes is a identified as cryptsetup device, the Initializer assumes a pod restart happened and the device was previously encrypted with the secret seed. The Initializer will try to open the device, and assume it is protected if the operation…
Recommended action: Upgrade to 1.12.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/edgelesssys/contrast >= 1.9.0, <= 1.12.1
Fixed in
1.12.2· Vendor fix available
Issue
This is the same vulnerability as https://github.com/edgelesssys/contrast/security/advisories/GHSA-h5f8-crrq-4pw8. The original vulnerability had been fixed for release v1.8.1, but the fix was not ported to the main branch and thus not present in releases v1.9.0 ff. Below is a brief repetition of the relevant sections from the first GHSA, where you can find the full details. Impact Workload secrets are visible to Kubernetes users with get or list permission on pods/logs, and thus need to be considered compromised. Since workload secrets are used for encrypted storage and Vault integration, those need to be considered compromised, too. Patches Patches: https://github.com/edgelesssys/contrast/commit/5a5512c4af63c17bb66331e7bd2768a863b2f225 https://github.com/edgelesssys/contrast/commit/cf58026b30c43fe7df91eac5322da02e1725d554 The patches are released with v1.12.2 and v1.13.0 (not yet published). Since the secrets are compromised, Contrast needs to be initialized from scratch.…
Recommended action: Upgrade to 1.12.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Background The VOLUME directive in Dockerfiles, or the config.volumes field in OCI image descriptors, indicates filesystem paths "where the process is likely to write data". While these paths have special semantics in Docker, they are only hints in the OCI spec and are not treated specially by Kubernetes. However, containered implements the specified conversion logic and adds a mount point if there is none set by Kubernetes. Unfortunately, the specification leaves it open whether the mount point is populated with any and what data, so the runtime needs to be able to push arbitrary data to the Kata agent. However, this is almost always not what the user wants: 1. A declared VOLUME location is usually important to the app's core functionality, which is usually at odds with the data in that location being untrusted. 2. VOLUME declarations are often used by image vendors to indicate "mount your persistence here" to the user. They are rarely useful without a real volume mounted there.…
Recommended action: Upgrade to 1.9.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact When the Contrast initializer is configured with a CONTRASTLOGLEVEL of info or debug, the workload secret is logged to stderr and written to Kubernetes logs. Since info is the default setting, this affects all Contrast installations that don't customize their initializers' log level. The following audiences are intended to have access to workload secrets (see https://docs.edgeless.systems/contrast/1.7/architecture/secrets#workload-secrets): Contrast Coordinator (can derive all workload secrets) Contrast Initializer (obtains only the secret configured in the manifest) Seedshare owner (can derive all workload secrets) Workload owner (can update manifests to obtain secrets) This vulnerability allows the following parties unintended access to workload secrets issued by a Coordinator: Kubernetes users with get or list permission on pods/logs. Others with read access to the Kubernetes log storage (most notably, the cloud provider). This vulnerability does not affect scenarios where…
Recommended action: Upgrade to 1.8.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Recovering coordinators do not verify the seed provided by the recovering party. This allows an attacker to set up a coordinator with a manifest that passes validation, but with a secret seed controlled by the attacker. If network traffic is redirected from the legitimate coordinator to the attacker's coordinator, a workload owner is susceptible to impersonation if either they set a new manifest and don't compare the root CA cert with the existing one (this is the default of the contrast CLI) or they verify the coordinator and don't compare the root CA cert with a trusted reference. Under these circumstances, the attacker can: Issue certificates that chain back to the attacker coordinator's root CA. Recover arbitrary workload secrets of workloads deployed after the attack. This issue does not affect the following: secrets of the legitimate coordinator (seed, workload secrets, CA) integrity of workloads, even when used with the rogue coordinator certificates chaining back to…
Recommended action: Upgrade to 1.4.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.