Raw transaction replay-protection middleware can be bypassed with extra positional params

[Kewe63]

Bug Description

RejectUnprotectedTxsMiddleware is intended to reject pre-EIP-155 / replay-unprotected legacy transactions submitted through public JSON-RPC when allow_unprotected_txs is false. However, the positional parameter parser currently extracts raw transaction bytes with an exact one-element tuple parse:

req.params().parse::<(Bytes,)>().ok().map(|(bytes,)| bytes)

A JSON-RPC request with a valid legacy raw transaction plus an extra positional parameter can make this middleware extraction fail. The middleware then treats the request as unparseable/malformed and forwards it to the inner RPC handler instead of applying Arc's replay-protection rejection.

If the downstream JSON-RPC method ignores the extra positional parameter and consumes the first raw transaction argument, this bypasses Arc's public RPC policy and allows pre-EIP-155 raw transaction submissions despite the default rejection setting.

Affected methods:

• eth_sendRawTransaction
• eth_sendRawTransactionSync

Code Evidence

crates/evm-node/src/rpc_middleware.rs:

fn error_if_unprotected_send_raw_tx<'a>(req: &Request<'a>) -> Result<(), ErrorObject<'a>> {
    if !is_raw_transaction_submission(req.method_name()) {
        return Ok(());
    }
    let Some(bytes) = extract_raw_tx_bytes(req) else {
        return Ok(());
    };
    let Ok(envelope) = TxEnvelope::decode_2718_exact(bytes.as_ref()) else {
        return Ok(());
    };
    if envelope.is_replay_protected() {
        return Ok(());
    }
    Err(ErrorObjectOwned::owned::<()>(
        UNPROTECTED_TX_ERROR_CODE,
        UNPROTECTED_TX_ERROR_MSG,
        None,
    ))
}

extract_raw_tx_bytes handles object params and exact one-element positional params, but does not reject malformed positional shapes at the policy boundary:

fn extract_raw_tx_bytes(req: &Request<'_>) -> Option<Bytes> {
    #[derive(serde::Deserialize)]
    struct SendRawTransactionParams {
        bytes: Bytes,
    }
    if req.params().is_object() {
        req.params()
            .parse::<SendRawTransactionParams>()
            .ok()
            .map(|p| p.bytes)
    } else {
        req.params().parse::<(Bytes,)>().ok().map(|(bytes,)| bytes)
    }
}

When the tuple parse fails, error_if_unprotected_send_raw_tx returns Ok(()), which allows the request to continue to the inner service.

Steps to Reproduce

1. Check out current upstream main:

git clone https://github.com/circlefin/arc-node arc-node-triage
cd arc-node-triage
git checkout de76122a1c4756e747accc27db35ffc8ec8981a8

2. Add this focused regression test inside the existing #[cfg(test)] mod tests in crates/evm-node/src/rpc_middleware.rs:

#[tokio::test]
async fn poc_extra_positional_param_bypasses_pre_eip155_rejection() {
    let middleware = RejectUnprotectedTxsMiddleware::new(MockRpcService);
    let raw_hex = encode_legacy_raw(None);
    let request = send_raw_tx_request_with_params(format!(r#"["{raw_hex}", "ignored"]"#), 999);
    let response = middleware.call(request).await;

    assert!(
        response.as_error_code().is_none(),
        "extra positional parameter makes middleware forward an unprotected raw tx"
    );
    let json: serde_json::Value = serde_json::from_str(response.into_json().get()).unwrap();
    assert_eq!(json["result"], "success");
}

3. Run the focused test:

RUSTUP_TOOLCHAIN=1.94.0 cargo test -p arc-evm-node poc_extra_positional_param_bypasses_pre_eip155_rejection -- --nocapture

Actual Behavior

A pre-EIP-155 raw transaction with an extra positional parameter is forwarded by the middleware instead of being rejected by Arc's replay-protection policy.

Example request shape:

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "eth_sendRawTransaction",
  "params": [
    "0x<valid legacy raw transaction signed without EIP-155 chain_id>",
    "ignored"
  ]
}

Expected Behavior

RejectUnprotectedTxsMiddleware should not silently allow policy-sensitive malformed parameter shapes. It should either:

• extract and validate the first raw transaction argument consistently with the downstream handler, or
• reject raw transaction submission calls whose params are not one of the explicitly supported safe shapes.

In all cases, pre-EIP-155 raw transactions should be rejected when allow_unprotected_txs is false, regardless of trailing ignored params.

Impact

This can bypass Arc's default replay-protection policy for public RPC raw transaction submission paths. A public RPC client may submit replay-unprotected legacy transactions by adding an ignored second positional parameter, undermining the node operator's expectation that pre-EIP-155 raw transactions are blocked unless explicitly allowed.

Duplicate Check

Searched public issues and PRs in circlefin/arc-node for:

• sendRawTransaction extra positional
• unprotected transaction extra params
• pre-EIP-155 raw transaction
• extract_raw_tx_bytes
• allow_unprotected_txs
• trailing raw transaction
• RPC replay-protection

No matching issue or PR for this root cause was found. The visible matches were unrelated docs/consensus items, not this middleware bypass.

Environment

• Repository: circlefin/arc-node
• Commit tested: de76122a1c4756e747accc27db35ffc8ec8981a8
• Package: arc-evm-node
• Component: crates/evm-node/src/rpc_middleware.rs

[osr21]

Disclosure: I’m an external community contributor, not affiliated with Circle, not a maintainer, and I have no write access to this repository.

This is advisory review only.\n\n## Assessment: the bypass is real\n\nI checked the reported path against the pinned source rather than treating this as only a middleware parsing discrepancy.\n\n1. extract_raw_tx_bytes uses req.params().parse::<(Bytes,)>() for positional params. A request shaped as [raw_tx, ignored] therefore returns None because the tuple parse requires exactly one element.\n2. error_if_unprotected_send_raw_tx treats None as Ok(()), so it forwards the request instead of rejecting it.\n3. The inner Reth methods are declared with exactly one Bytes argument for both eth_sendRawTransaction and eth_sendRawTransactionSync.\n4. The pinned jsonrpsee server macro decodes positional arguments through ParamsSequence::next() once per declared argument and does not check that the sequence is exhausted. The downstream handler therefore consumes the first raw transaction and ignores the trailing value.\n\nThat makes this a genuine policy bypass, not merely a difference in error wording. With allow_unprotected_txs at its default false, a valid pre-EIP-155 transaction can reach the inner handler by adding a second positional parameter. The same helper is used by the batch path, and the rejection middleware is outside the relay layer, so the bypass also applies when raw transactions are forwarded to configured relays. It does not create a new signature forgery primitive; it bypasses the node operator’s explicit replay-protection submission policy.\n\n## Suggested fix shape\n\nThe smallest behavior-preserving fix is to extract the first positional value the same way the downstream server does, rather than requiring an exact one-element tuple, for example using the params sequence and next::<Bytes>(). That causes [raw_tx, ignored] to be inspected and the legacy transaction to receive the existing -32000 rejection. Protected transactions can continue through to the inner handler, which already ignores the extra value.\n\nA stricter alternative is to reject any positional shape other than exactly one element at this policy boundary. If that route is chosen, it should return an invalid-params error rather than silently forwarding the shape; otherwise the current “malformed input is handled by the inner service” convention recreates the same gap.\n\n## Regression coverage\n\nThe focused test should assert the existing UNPROTECTED_TX_ERROR_CODE rather than success, and should cover both method names. A batch case is also worthwhile because the middleware has a separate batch loop but calls the same extractor. Keep a control showing that a protected transaction with a trailing value is not incorrectly classified as unprotected.\n\nThe issue is therefore actionable and correctly scoped to RejectUnprotectedTxsMiddleware; it is not dependent on public gateway behavior. I could not execute the Rust test in this environment because cargo is not available on the shell PATH, but the parser behavior is confirmed from the pinned Reth/jsonrpsee source and the described control flow.