Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
🐹 Go

CVE-2023-43630

HIGH

CVE-2023-43630 is a high-severity (CVSS 8.8) CWE-328 vulnerability in github.com/lf-edge/eve. O3 Security confirms whether CVE-2023-43630 is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.

Config Partition Not Measured From 2 Fronts

Also known asGHSA-phcg-h58r-gmcqGO-2026-4430
Published
Sep 20, 2023
Updated
Jul 31, 2026
Affected
1 pkg
Patched
1 / 1
Exploits
None indexed

Blast Radius

1 pkg affected
🐹github.com/lf-edge/eve

Real-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

PCR14 is not in the list of PCRs that seal/unseal the “vault” key, but due to the change that was implemented in commit “7638364bc0acf8b5c481b5ce5fea11ad44ad7fd4”, fixing this issue alone would not solve the problem of the config partition not being measured correctly.

Also, the “vault” key is sealed/unsealed with SHA1 PCRs instead of SHA256. This issue was somewhat mitigated due to all of the PCR extend functions updating both the values of SHA256 and SHA1 for a given PCR ID.

However, due to the change that was implemented in commit “7638364bc0acf8b5c481b5ce5fea11ad44ad7fd4”, this is no longer the case for PCR14, as the code in “measurefs.go” explicitly updates only the SHA256 instance of PCR14, which means that even if PCR14 were to be added to the list of PCRs sealing/unsealing the “vault” key, changes to the config partition would still not be measured.

An attacker could modify the config partition without triggering the measured boot, this could result in the attacker gaining full control over the device with full access to the contents of the encrypted “vault”

Affected Packages

1 total 1 fixed
EcosystemPackageVulnerable rangeFix
🐹Gogithub.com/lf-edge/eveall versions0.0.0-20230126065759-d9383a7ee4e1

Detection & mitigation playbook

Open-source dependency
  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/lf-edge/eve. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.

  2. Fix

    Update github.com/lf-edge/eve to 0.0.0-20230126065759-d9383a7ee4e1 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2023-43630 is resolved across your whole dependency graph.

  3. 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.

  4. How O3 protects you

    O3 pinpoints whether CVE-2023-43630 is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.

Tailored to CVE-2023-43630. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.

Frequently Asked Questions

PCR14 is not in the list of PCRs that seal/unseal the “vault” key, but due to the change that was implemented in commit “7638364bc0acf8b5c481b5ce5fea11ad44ad7fd4”, fixing this issue alone would not solve the problem of the config partition not being measured correctly. Also, the “vault” key is sealed/unsealed with SHA1 PCRs instead of SHA256. This issue was somewhat mitigated due to all of the PCR extend functions updating both the values of SHA256 and SHA1 for a given PCR ID. However, due to the change that was implemented in commit “7638364bc0acf8b5c481b5ce5fea11ad44ad7fd4”, this is no lo
O3 Security · Impact-Aware SCA

Is CVE-2023-43630 in your dependencies?

O3 detects CVE-2023-43630 across Go dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.