N/A

CVSS Score

Basic Information

CVE ID

CVE-2025-58356

GHSA ID

GHSA-hq76-6gh2-5g4q

EPSS Score

CWE

CWE-552

Published

10/27/2025

Updated

10/27/2025

KEV Status

Technology

Concerned about an active attack path?

Talk to our security experts and see Miggo in action.

Miggo Vulnerability Database

→

CVE-2025-58356

CVE-2025-58356: Constellation has insecure LUKS2 persistent storage partitions which may be opened and used

Summary

A malicious host may provide a crafted LUKS2 volume to a confidential computing guest that is using the OpenCryptDevice feature. The guest will open the volume and write secret data using a volume key known to the attacker. The attacker can also pre-load data on the device, which could potentially compromise guest execution.

LUKS2 volume metadata is not authenticated and 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)
Contains arbitrary data chosen by the attacker

Details

The Constellation CVM image uses LUKS2-encrypted volumes for persistent storage. When opening an encrypted storage device, the CVM uses the libcryptsetup function crypt_activate_by_passhrase. If the VM is successful in opening the partition with the disk encryption key, it treats the volume as confidential. However, due to the unsafe handling of null keyslot algorithms in the cryptsetup 2.8.1, it is possible that the opened volume is not encrypted at all.

Cryptsetup prior to version 2.8.1 does not report an error when processing LUKS2-formatted disks that use the cipher_null-ecb algorithm in the keyslot encryption field.

Impact

A LUKS2 disk encrypted with a master key, which is in turn encrypted with user passwords stored in some number of keyslots. By creating a malicious disk which sets the keyslot encryption algorithm to ”crypto_null-ecb”, an attacker can construct a disk such that keyslot decryption does not depend in any way on the enclave-held secret data. When a confidential guest opens such a device using cryptsetup open, the mapped disk is created without error, and any further writes to the disk are encrypted using an attacker-controlled key.

Patches

To protect against this and similar attacks, Constellation now performs detached reading of LUKS headers. The header is copied into the encrypted memory of the CVM and then verified. The verified header is then used to open the encrypted LUKS device in detached header mode. This was implemented in https://github.com/edgelesssys/constellation/pull/3927 and release as part of Constellation v2.24.0.

(GitHub Advisory)

N/A

CVSS Score

Basic Information

CVE ID

CVE-2025-58356

GHSA ID

GHSA-hq76-6gh2-5g4q

EPSS Score

CWE

CWE-552

Published

10/27/2025

Updated

10/27/2025

KEV Status

Technology

Technical Details

CVSS Vector

Package Name	Ecosystem	Vulnerable Versions	First Patched Version
github.com/edgelesssys/constellation/v2	go	<= 2.23.1	2.24.0

Vulnerability Intelligence
Miggo AI

Root Cause Analysis

The vulnerability lies in the insecure handling of LUKS2 volumes, where a crafted volume with a malicious header could be opened by a guest, leading to data compromise. The root cause was the lack of validation of the LUKS2 header before its use, specifically allowing insecure cipher algorithms like cipher_null-ecb.

The patch addresses this by introducing a 'detached header' mechanism. Before opening a device, the LUKS2 header is now copied into a separate file, and a loopback device is created for it. This detached header is then parsed and rigorously verified by the newly added verifyLUKS2Header function in internal/cryptsetup/cryptsetup_cgo.go. This function checks various fields in the header metadata, including the encryption algorithm, key size, KDF, and more, to ensure they conform to expected secure values. Only after successful verification is the actual device opened using the verified header.

The primary vulnerable functions identified are internal/cryptsetup.CryptSetup.Init and internal/cryptsetup.CryptSetup.InitByName, as they are the public API endpoints in the cryptsetup package that were modified to incorporate this new secure initialization flow. Before the patch, these functions would proceed with device initialization without any header validation.

Additionally, cryptmapper.cryptMapper.OpenCryptDevice is identified as a key runtime indicator. As mentioned in the security advisory, this is the higher-level function that calls the vulnerable Init function, making it a crucial part of the exploitation path. Any runtime profile of the exploitation would likely show a call to OpenCryptDevice followed by Init.

Vulnerable functions

internal/cryptsetup.CryptSetup.Init

internal/cryptsetup/cryptsetup.go

This function initializes a crypt device from a given path. Before the patch, it did not perform any verification of the LUKS2 header, allowing a malicious header to be used. The patch introduces a new initialization flow where the header is detached, verified by the new `verifyLUKS2Header` function, and then used. The `verifyLUKS2Header` function checks for insecure configurations, such as the `cipher_null-ecb` algorithm mentioned in the advisory.

internal/cryptsetup.CryptSetup.InitByName

internal/cryptsetup/cryptsetup.go

This function initializes a crypt device by its name. It was vulnerable for the same reasons as `Init`, as it did not verify the LUKS2 header before use. The patch applies the same mitigation of detaching and verifying the header.

cryptmapper.cryptMapper.OpenCryptDevice

csi/cryptmapper/cryptmapper.go

This function is a higher-level API that orchestrates the opening of an encrypted device. It uses the vulnerable `cryptsetup.Init` function. An attacker could exploit this by providing a crafted device path, leading to the use of a malicious LUKS2 header. Although this file was not modified in the patch, the underlying call to `cryptsetup.Init` is now secure.

internal/cryptsetup.verifyLUKS2Header

internal/cryptsetup/cryptsetup_cgo.go

This function is not vulnerable itself, but it is the core of the mitigation. It was introduced by the patch to validate the LUKS2 header. One of its checks, `slot.Area.Encryption != "aes-xts-plain64"`, directly prevents the usage of insecure ciphers like `cipher_null-ecb` which was the root cause of the vulnerability. Its presence in a runtime profile would indicate the patched version is in use.

WAF Protection Rules

WAF Rule

### Summ*ry * m*li*ious *ost m*y provi** * *r**t** LUKS* volum* to * *on*i**nti*l *omputin* *u*st t**t is usin* t** [Op*n*rypt**vi**](*ttps://*it*u*.*om/****l*sssys/*onst*ll*tion/*lo*/****************************************/*si/*ryptm*pp*r/*ryptm*pp

Reasoning

T** vuln*r**ility li*s in t** ins**ur* **n*lin* o* LUKS* volum*s, w**r* * *r**t** volum* wit* * m*li*ious *****r *oul* ** op*n** *y * *u*st, l***in* to **t* *ompromis*. T** root **us* w*s t** l**k o* v*li**tion o* t** LUKS* *****r ***or* its us*, sp*

N/A

Basic Information

Concerned about an active attack path?

CVE-2025-58356: Constellation has insecure LUKS2 persistent storage partitions which may be opened and used

Summary

Details

Impact

Patches

N/A

Basic Information

Technical Details

Vulnerability IntelligenceMiggo AI

Root Cause Analysis

Vulnerable functions

WAF Protection Rules

WAF Rule

Reasoning

Vulnerability Intelligence
Miggo AI