GHSA-hq76-6gh2-5g4q — v2
Fix: edgelesssys/constellation#3927GHSA-hq76-6gh2-5g4q is a CWE-347 vulnerability in github.com/edgelesssys/constellation/v2. A fix is available for github.com/edgelesssys/constellation/v2 — see the affected versions and patch details below.
Constellation has insecure LUKS2 persistent storage partitions which may be opened and used
Exploitation Status
No confirmed exploitation observed yet
- CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.
Exploitation and automatability from CISA’s SSVC triage for GHSA-hq76-6gh2-5g4q.
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
Real-World Exposure
github.com/edgelesssys/constellation/v2Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.
Description
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.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | github.com/edgelesssys/constellation/v2 | all versions | 2.24.0go get github.com/edgelesssys/constellation/v2@v2.24.0 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/edgelesssys/constellation/v2, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update github.com/edgelesssys/constellation/v2 to 2.24.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-hq76-6gh2-5g4q is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 Security's impact-aware SCA analyses which vulnerable code paths your application actually calls, so a match like GHSA-hq76-6gh2-5g4q can be triaged on real exposure rather than presence alone.
Tailored to GHSA-hq76-6gh2-5g4q. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-hq76-6gh2-5g4q in your dependencies?
O3 Security finds GHSA-hq76-6gh2-5g4q across Go dependencies, including transitive ones, and its impact-aware SCA ranks findings by whether your code actually calls the vulnerable path.