UEFI Firmware Parser has a stack out-of-bounds write in tiano decompressor MakeTableGHSA-2689-5p89-6j3j
CRITICALFix: theopolis/uefi-firmware-parser#145GHSA-2689-5p89-6j3j 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-2689-5p89-6j3j.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
How urgent is this, really
GHSA-2689-5p89-6j3j by exploitation likelihood (EPSS) against impact (CVSS). Outside the shaded patch-first corner.
Where this sits among everything scored
Of 384,189 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 stack out-of-bounds write vulnerability in the native tiano/EFI decompressor. in uefi_firmware/compression/Tiano/Decompress.c, MakeTable() does not validate that bit-length values read from the compressed bitstream are within the expected range (0..16). a crafted firmware blob can supply bit lengths greater than 16, causing out-of-bounds writes to the stack-allocated Count[17] array and related decode tables.
reachability is through the normal parsing path: CompressedSection.process() -> efi_compressor.TianoDecompress() -> TianoDecompress() -> ReadPTLen() -> MakeTable().
Minimum impact is a deterministic crash; depending on build/runtime details, the stack 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.
References:
- 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-2689-5p89-6j3j 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-2689-5p89-6j3j in your dependencies?
Find it across PyPI, including transitive dependencies.