Skip to main content
CVE Vulnerability Database
Vulnerability Database/CVE-2025-54429

CVE-2025-54429: Polkadot Frontier Privilege Escalation

CVE-2025-54429 is a privilege escalation vulnerability in Polkadot Frontier's EVM compatibility layer that misclassifies contract addresses as externally owned accounts. This article covers technical details, impact, and fixes.

Published:

CVE-2025-54429 Overview

Polkadot Frontier is an Ethereum Virtual Machine (EVM) compatibility layer for Polkadot and Substrate-based blockchains. CVE-2025-54429 is a type confusion vulnerability in the CallableByContract access-control mechanism that governs which account types can invoke EVM precompiled contracts. The implementation incorrectly classified contract addresses executing under CREATE or CREATE2 opcodes as AddressType::EOA instead of AddressType::Contract. This misclassification allows smart contracts to reach precompiles that should only be callable by externally owned accounts (EOAs). The flaw is fixed in commit 0822030.

Critical Impact

Custom precompile implementations that rely on AddressType::EOA and AddressType::Contract for access-control decisions may permit contract-originated calls that were intended to be restricted, weakening safety guarantees on chains built with Frontier.

Affected Products

  • Polkadot Frontier (polkadot-evm/frontier) prior to commit 0822030
  • Substrate-based chains integrating Frontier's EVM pallet with custom precompiles
  • Downstream runtimes distributing pre-0822030 Frontier builds

Discovery Timeline

  • 2025-07-28 - CVE-2025-54429 published to the National Vulnerability Database
  • 2026-06-17 - Last updated in NVD database

Technical Details for CVE-2025-54429

Vulnerability Analysis

Frontier categorizes EVM callers into distinct address types so that runtime authors can restrict sensitive precompiles to specific origins. Precompiles intended for contract use must be explicitly marked CallableByContract; otherwise, contract-originated calls should be rejected. The underlying helper that returned the AddressType returned an incorrect value when the caller was a contract executing inside a CREATE or CREATE2 frame.

Because of this incorrect return value, addresses that are in fact contracts were reported as EOAs. Access-control logic in custom precompiles that branches on AddressType::EOA versus AddressType::Contract therefore reaches an unintended path. The issue is classified as [CWE-704] Incorrect Type Conversion or Cast. The predefined precompiles shipped with Frontier do not use this API in a way that is directly exploitable, so the practical impact is limited to runtimes that ship custom precompile implementations depending on the address-type distinction.

Root Cause

The CallableByContract implementation resolved the caller's address type by examining runtime state that did not yet reflect the code being deployed. Within a CREATE or CREATE2 execution frame, the target address has no deployed code at the moment of the check, so the caller was treated as AddressType::EOA even though the frame was initiated by a contract. The check conflated "has code now" with "is an EOA," producing an incorrect type classification.

Attack Vector

An attacker deploys a malicious contract using CREATE or CREATE2 and, within the constructor, calls a custom precompile that gates behavior on AddressType::EOA. The precompile observes the caller as an EOA and executes the restricted code path. Exploitation requires the target chain to ship a custom precompile that trusts the EOA distinction for authorization or safety. No authentication is required beyond the ability to submit an EVM transaction.

The vulnerability manifests in the Frontier CallableByContract implementation. See the GitHub Security Advisory GHSA-fr62-ppwc-mc2h and the Frontier SRLabs Report for the full technical write-up.

Detection Methods for CVE-2025-54429

Indicators of Compromise

  • EVM transactions that deploy contracts via CREATE or CREATE2 and, from within their constructor, invoke a custom precompile address.
  • Precompile invocations whose caller address contains bytecode after the enclosing transaction completes, contradicting an EOA-only access assumption.
  • State changes in precompile-managed storage attributable to contract-originated calls where policy expected EOA-only writes.

Detection Strategies

  • Audit each custom precompile for branches conditioned on AddressType::EOA and identify calls where the caller subsequently became a contract.
  • Instrument the runtime to log the raw caller and the resolved AddressType for every precompile invocation, then reconcile against post-transaction state.
  • Replay historical blocks against a patched Frontier build and compare AddressType classifications to flag divergent decisions.

Monitoring Recommendations

  • Track deployment transactions that touch privileged precompile addresses during construction and alert on any match.
  • Monitor Frontier release channels and the polkadot-evm/frontier repository for version bumps in downstream runtimes.
  • Correlate on-chain telemetry with runtime upgrade events to confirm the fix is active on validators and RPC nodes.

How to Mitigate CVE-2025-54429

Immediate Actions Required

  • Upgrade Frontier to a build that includes commit 0822030 or later and coordinate a runtime upgrade for affected parachains.
  • Inventory all custom precompiles and identify any that rely on AddressType::EOA versus AddressType::Contract for access control.
  • Disable or gate at the runtime level any custom precompile whose safety depends on the EOA distinction until the patched build is deployed.

Patch Information

The fix is merged in Pull Request #1655 and corresponds to commit 0822030 in the polkadot-evm/frontier repository. The patch corrects the AddressType resolution so that callers executing within a CREATE or CREATE2 frame are reported as AddressType::Contract. Full advisory details are published as GHSA-fr62-ppwc-mc2h.

Workarounds

  • Rewrite custom precompiles to avoid trusting the caller's address type for security decisions, using explicit allowlists or capability checks instead.
  • Restrict access to sensitive precompiles at the runtime configuration layer until the patched Frontier commit is integrated.
  • Reject calls from addresses whose code size is zero only when accompanied by an independent check that the caller is not in a CREATE frame.

Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

Default Legacy - Prefooter | Experience the World’s Most Advanced Cybersecurity Platform

Experience the Most Advanced Cybersecurity Platform

See how the world’s most intelligent, autonomous cybersecurity platform can protect your organization today and into the future.