UEFI Firmware Parser has a heap out-of-bounds write in tiano decompressor ReadCLenGHSA-hm2w-vr2p-hq7w
CRITICALFix: theopolis/uefi-firmware-parser#145GHSA-hm2w-vr2p-hq7w is a critical-severity (CVSS 9.8) Out-of-bounds Write vulnerability in uefi-firmware. No vendor fix is recorded yet; mitigation options are listed below.
Exploitation Status
No confirmed exploitation observed yet
- CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.
- A successful exploit gives an attacker total control of the affected component, not partial access.
- 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-hm2w-vr2p-hq7w.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
How urgent is this, really
GHSA-hm2w-vr2p-hq7w by exploitation likelihood (EPSS) against impact (CVSS). Outside the shaded patch-first corner.
Where this sits among everything scored
Of 383,485 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Counts from FIRST.org, log-scaled.
Real-World Exposure
uefi-firmwareReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects PyPI packages — download data is not available via public APIs for these ecosystems.
Description
uefi-firmware contains a heap out-of-bounds write vulnerability in the native tiano/EFI decompressor. in uefi_firmware/compression/Tiano/Decompress.c, ReadCLen() reads Number = GetBits(Sd, CBIT) with CBIT = 9, so Number can be as large as 511, while the destination array Sd->mCLen has NC = 510 elements. the loop writes while Index < Number without enforcing Index < NC. additionally, the CharC == 2 run-length path performs GetBits(Sd, 9) + 20, allowing up to 531 zero writes through Sd->mCLen[Index++] = 0.
Reachability is through the normal parsing path: CompressedSection.process() -> efi_compressor.TianoDecompress() -> TianoDecompress() -> DecodeC() -> ReadCLen().
Minimum impact is a deterministic crash; depending on build/runtime details, the heap memory corruption may be exploitable for code execution in the context of the parsing process. this project shipped its own copy of the decompressor without the upstream EDK2 hardening for this bug class.
- PR: https://github.com/theopolis/uefi-firmware-parser/pull/145
- fix commit: https://github.com/theopolis/uefi-firmware-parser/commit/bf3dfaa8a05675bae6ea0cbfa082ddcebfcde23e
- upstream related fixes: CVE-2017-5731, CVE-2017-5732, CVE-2017-5733, CVE-2017-5734, CVE-2017-5735
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐍PyPI | uefi-firmware | all versions | No fix |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for uefi-firmware, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Remediation status
No patched version of uefi-firmware has shipped for GHSA-hm2w-vr2p-hq7w yet. Where your build allows, override or pin the dependency away from the vulnerable range, and apply any maintainer-recommended mitigation.
Mitigate without a patch
Stop feeding it untrusted input: reject or quarantine files and payloads from unverified sources until you can upgrade, restrict accepted formats to the ones you actually need, and run the parsing or decoding step in a least-privileged sandbox or short-lived worker so a crash or corrupted read cannot reach the rest of the process.
Frequently Asked Questions
Is GHSA-hm2w-vr2p-hq7w in your dependencies?
Find it across PyPI, including transitive dependencies.