Executive Summary
CVE-2025-51679 has been published for the OpenRISC OR1200 processor core, a widely reused open-source soft-CPU design found in FPGA and ASIC projects. According to NVD, the issue was discovered "in openRISC OR1200 commit 83ac6b," where a mismatch between the RTL (register-transfer level) design and the synthesized netlist can lead to unexpected behavior. NVD lists a CVSS score of 9.1.
CVSS Score: 9.1 (Critical)
Unlike a typical software CVE, this is a hardware design-integrity flaw: it means the logic that gets verified at the RTL stage is not guaranteed to be what actually ends up running in silicon or on an FPGA fabric after synthesis. That gap is significant for any team that trusts RTL-level simulation and formal verification as proof of correct, secure hardware behavior.
Vulnerability Overview
| Attribute | Value |
|---|---|
| CVE ID | CVE-2025-51679 |
| CVSS Score | 9.1 (Critical) |
| Component | OpenRISC OR1200 CPU core |
| Affected Commit | 83ac6b |
| Type | RTL-to-netlist equivalence / synthesis-stage mismatch |
| Source | NVD |
Why an RTL/Netlist Mismatch Matters
Hardware design flows typically move through three trusted stages:
- RTL (Verilog/VHDL) — the human-reviewed, formally verified source of truth for a chip's logic
- Synthesis — automated tooling translates RTL into a gate-level netlist
- Place-and-route / fabrication — the netlist becomes a physical FPGA bitstream or ASIC layout
Security review, formal verification, and code audits are almost always performed against the RTL, on the assumption that synthesis faithfully preserves that logic. When RTL and netlist diverge, everything downstream of synthesis — simulation results, formal proofs, and manual review — can pass cleanly while the actual deployed hardware behaves differently.
This class of bug is closely related to the "golden reference" problem studied in recent RTL-fuzzing and synthesis-verification research: attackers or buggy toolchains can introduce subtle logic changes during synthesis that evade RTL-level review entirely, since nobody re-audits the netlist by hand.
Practical Risk
| Risk | Description |
|---|---|
| Silent logic drift | Deployed core does not match reviewed/verified RTL |
| Undermined verification | RTL-level formal proofs and simulation no longer guarantee correctness of the built hardware |
| Supply-chain exposure | Any downstream project (FPGA SoC, embedded controller, academic tapeout) reusing this OR1200 commit inherits the mismatch |
| Debug/exception path risk | Prior public research on OR1200 has flagged mismatches specifically around load/store and debug-unit interactions — a pattern consistent with this class of issue |
Affected Projects
| Component | Affected State |
|---|---|
| OpenRISC OR1200 core | Commit 83ac6b and any build synthesized from it without re-verification |
| Downstream SoCs/FPGA images | Any project that vendored or forked this commit |
At the time of writing, no proof-of-concept exploit or in-the-wild abuse has been publicly reported — the NVD entry documents the design flaw itself rather than a demonstrated attack chain. Given the CVSS 9.1 rating and the nature of the flaw, treat it as high priority for any team building on this core.
Recommended Actions
- Identify usage — check whether any FPGA/ASIC project you maintain or depend on vendors the OR1200 core at or before commit 83ac6b.
- Re-verify post-synthesis — do not rely solely on RTL-level simulation and formal verification; run gate-level (netlist) simulation and equivalence checking (e.g., formal LEC tools) against the RTL to confirm no drift.
- Track upstream fixes — monitor the OpenRISC OR1200 repository for a corrected commit and rebase downstream forks once available.
- Re-synthesize with a trusted toolchain — where possible, regenerate netlists with a vetted synthesis flow and diff the result against previously shipped bitstreams/gate lists.
- Flag in hardware supply-chain audits — treat RTL/netlist equivalence checking as a standing requirement for any reused open-source core, not a one-time check.