Monad

Description

Note: This issue was known internally by the protocol team and fixed in a later commit after the issue had been submitted. However, it is still kept in the report for completeness.

(Issue found in commit hash 4cbb1742cd31ee30a0d2c6edb698400d9d70f9d8)

The staking precompile does not enforce that the EVMC message kind passed to the precompile is not DELEGATECALL. This has very severe implications since the staking precompile works by getting the user to transfer native MON via msg.value to the precompile.

Result<byte_string> StakingContract::precompile_delegate(    byte_string_view const input, evmc_address const &msg_sender,    evmc_uint256be const &msg_value){

Since DELEGATECALL preserves msg.value and msg.sender from the previous caller context, a user can setup a malicious contract that delegatecalls precompile_delegate for instance, the native MON will be transferred to malicious contract but the msg.value will be reused in precompile_delegate without actually transferring the funds to the staking precompile.

State updates will then occur in the staking contract recording the user's stake without the staking precompile actually having received the funds (this is because the state variables in the precompile contract are defined for the precompile address resulting in state_.set_storage(STAKING_CONTRACT_ADDRESS... being called).

The user can then withdraw their funds from the staking precompile and the malicious contract resulting in the theft of all staked MON.

Also related to this issue is a user can call state-changing precompile functions using STATICCALL which should not be allowed as STATICCALL should not allow state changes.

Recommendation

Enforce that EVMC message kind is CALL for all state-changing staking precompile functions (precompile_get_delegator, precompile_add_validator, precompile_delegate, precompile_undelegate, precompile_compound, precompile_withdraw, precompile_claim_rewards) and CALL and STATICCALL for non state-changing precompile functions (precompile_get_validator)

Category Labs: We were planning to ban everything except EVMC_CALL (including on get_validator even though static call is fine) before anything gets dispatched. Fixed in 215721ad.

Spearbit: STATICCALL is still allowed to state-changing precompiles as the msg.flags is not checked to be EVMC_STATIC

Category Labs: Fixed in fc820c9

Description

Currently there are two mempools in Monad. a tracked mempool and a pending mempool. The problem is both mempool perform insufficient limit checks to prevent unbounded memory consumption which can lead to an OOM crash scenario. For example,

• As discussed in https://github.com/category-labs/monad-bft/issues/1557, for both pools there is no maximum limit on the transaction size which can lead to a single transaction consuming unbounded amounts of memory.

• Furthermore, there is no limit on the number of transactions for any address in the tracked pool, meaning that a single address that has been promoted to the tracked pool can flood the tracked pool with many spam transactions to exhaust memory and cause an OOM.

Recommendation

It is recommended to enforce more checks on the transaction size and count limits. For instance, here is how Geth implements their strategy to manage transaction limits in the mempool, which can be referenced here.

• Enforce 512kB size limit (> max initcodesize) on individual transactions.

• Track transactions using the amount of 32kB slots they occupy (this is similar to Geth implementation here), enforce a 4096+1024=5120 slots on the mempool (so that the maximum memory consumed by the mempool is 5120 * 32kB = 163.84MB). This maximum slot size can be incremented if the expected minimum hardware requirements for Monad are stronger.

Category Labs: The issue is partially fixed here which enforces a 384kB size limit on individual transactions. The tracked pool transaction count limit is currently being worked on in this open issue.

Description

Below is a rough diagram of the current transaction pool architecture implemented in Monad.

Currently there are two mempools in Monad. a tracked pool and a pending pool.

• All addresses are by default untracked.
• Any transaction for an untracked address will first fall into the pending pool while transactions for tracked addresses will fall into the tracked pool.
• During create_proposal or updated_committed_block, addresses are promoted to the tracked pool, up to the MAX_ADDRESSES capacity.
• During create_proposal, only transactions from the tracked pool will be selected via standard priority fee mechanism.
• Time-based expiration per transaction exists only for the tracked pool
• An address is evicted from the tracked pool when it no longer has any transactions in the TrackedTxList

The way the transaction pool is architected allows for a denial-of-service vector by hogging MAX_ADDRESSES limit via multiple spam accounts. There are two main issues here:

1. In both the tracked and pending mempool, priority fee replacement only works for transactions of the same address, if MAX_ADDRESSES is reached we simply drop the transaction. The pool lacks an eviction strategy to evict lower fee transactions across address which allows consuming space in MAX_ADDRESSES to prevent others from submitting transactions to the mempool. This differs from Geth where if the transaction limit is reached the lowest fee transaction from any address, not just the address that submitted the transaction, is evicted. This implementation can be seen here.

2. A tracked address can periodically submit nonce-gapped transactions to the tracked pool, such transactions will never be executed in a committed block (as they are nonce-gapped). Consequently, this prevents tracked address from being evicted from the TrackedTxMap since they always have a single nonce-gapped transaction in their TrackedTxList, thereby consuming space in the MAX_ADDRESSES and preventing untracked addresses from being promoted.

Recommendation

It is recommended to come up with better eviction strategies to better handle transactions in the mempool. Here are some recommendations to take into account:

• Lower fee transactions should be evicted from the mempool if a higher fee transaction comes in and eviction should also take into account whether the transaction is currently executable with the correct account nonce and priority fee.

• Address with ONLY non-executable transactions such as nonce-gapped transactions should not be allowed into the tracked mempool or demoted if it no longer has any executable transactions of the next nonce. This is to prevent hogging MAX_ADDRESSES for the tracked pool.

Category Labs: We are tracking it in this open issue.

Description

The consensus code present in monad-eth-block-policy is missing transaction static validation of EIP-7623: Data Floor Gas, which changes calldata pricing for transactions with large calldata. This is a problem because the execution code does implement EIP-7623 as part of the Prague fork during static validation of the transaction.

validate_transaction.cpp#L97-L102

// EIP-7623    if constexpr (rev >= EVMC_PRAGUE) {        if (MONAD_UNLIKELY(floor_data_gas(tx) > tx.gas_limit)) {            return TransactionError::IntrinsicGasGreaterThanLimit;        }    }

So a transaction that passes static validation in consensus will be rejected during static validation in execution. During execution, this transaction is considered an invalid transaction, which note is different from a reverting transaction and the function execute will return early and return an error via BOOST_OUTCOME_TRY

execute_transaction.cpp#L220-L232

Result<ExecutionResult> execute(    Chain const &chain, uint64_t const i, Transaction const &tx,    Address const &sender, BlockHeader const &hdr,    BlockHashBuffer const &block_hash_buffer, BlockState &block_state,    BlockMetrics &block_metrics, boost::fibers::promise<void> &prev)    ...    BOOST_OUTCOME_TRY(static_validate_transaction<rev>(        tx,        hdr.base_fee_per_gas,        chain.get_chain_id(),        chain.get_max_code_size(hdr.number, hdr.timestamp)));

execute_block.cpp#L213-L224

for (unsigned i = 0; i < block.transactions.size(); ++i) {        MONAD_ASSERT(results[i].has_value());        if (MONAD_UNLIKELY(results[i].value().has_error())) {            LOG_ERROR(                "tx {} {} validation failed: {}",                i,                block.transactions[i],                results[i].value().assume_error().message().c_str());        }        BOOST_OUTCOME_TRY(auto retval, std::move(results[i].value()));        retvals.push_back(std::move(retval));    }

What makes this a problem is the transaction is invalid (different from a revert), returns an error, but no gas is actually charged for it since execute will exit early. In Monad, nodes agree on the transactions to execute before actually executing them, this means that an attacker can set a transaction with a large gas limit, but does not obey EIP-7623. This passes static validation in consensus code but fails static validation in execution code, as a result this transaction can occupy space in a proposal without the attacker needing to pay any gas for it, leading to a reliable denial-of-service vector

Recommendation

Validate EIP-7623 in the consensus code in monad-eth-block-policy as well.

Description

Deserialization of a (small) crafted input to Raptorcast's deserialization function can incur a high computational cost; approximately 0.5-1 second of processing time per 27 bytes of payload on modern hardware.

Proof of Concept

diff --git a/monad-raptorcast/src/message.rs b/monad-raptorcast/src/message.rsindex 205c0a49..24b3906c 100644--- a/monad-raptorcast/src/message.rs+++ b/monad-raptorcast/src/message.rs@@ -256,6 +256,7 @@ impl<M: Decodable, ST: CertificateSignatureRecoverable> InboundRouterMessage<M, mod tests {     use bytes::BytesMut;     use monad_secp::SecpSignature;+    use std::time::{Duration, Instant};     use rstest::*;      use super::*;@@ -443,4 +444,20 @@ mod tests {             _ => panic!("expected AppMessage variant"),         }     }++    #[test]+    fn test_deserialization_decompression_bomb() {+        let serialized = Bytes::from(&[+          0xda, 0xc2, 0x5d, 0x02, 0x01, 0x23, 0x94, 0x28, 0xb5, 0x2f, 0xfd, 0x14,+          0x88, 0x5d, 0x00, 0x00, 0xdd, 0xf9, 0x1f, 0x06, 0xfd, 0x40, 0x14, 0x02,+          0x30, 0x07, 0x4f+        ][..]);++        let start = Instant::now();+        for _i in 1..100 {+            let _ = InboundRouterMessage::<TestMessage, SecpSignature>::try_deserialize(&serialized);+        }+        let duration = start.elapsed();+        assert!(duration < Duration::from_secs(1), "Operation took too long: {:?}", duration);+    } }

Output:

running 1 testtest message::tests::test_deserialization_decompression_bomb ... FAILED
failures:
---- message::tests::test_deserialization_decompression_bomb stdout ----
thread 'message::tests::test_deserialization_decompression_bomb' panicked at monad-raptorcast/src/message.rs:461:9:Operation took too long: 23.343895969snote: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

failures:    message::tests::test_deserialization_decompression_bomb
test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured; 41 filtered out; finished in 23.34s

Tested on "AMD EPYC 9454P 48-Core Processor".

Recommendation

The zstd decompressor uses streaming decompression. Use bulk decompression instead, as this mode has a much lower worst case complexity.

Category Labs: Acknowledged. ZSTD was intentionally disabled for mainnet launch to avoid running into this issue in PR 2184, and there is an internal issue to track this.

Description

(Issue found in commit hash 1a7f9476081abc734fc6fa359698c3b8f9806576)

In syscall_epoch_change, we attempt to update all the accumulators of validators present in the snapshot view at the beginning of a new epoch. This is meant to store the accumulator at the beginning for the epoch to calculate rewards for delta_stake

uint64_t const num_active_vals = vars._valset_snapshot().length();    for (uint64_t i = 0; i < num_active_vals; i += 1) {        auto const val_id = vars.valset_execution.get(i).load();        auto val = vars.val_execution(val_id);
        // TODO: once Maged's speculative execution is merged, move this        // into a separate loop.        {            auto acc_storage = vars.acc(next_epoch, val_id);            auto acc = acc_storage.load_checked();            if (acc.has_value()) {                acc->value = val.acc().load(); // this is the realtime val.acc                acc_storage.store(*acc); // store in the next_epoch            }        }        ...    }

The problem with the above code is that we fetch the validators to update by index from valset_execution. However, this may not actually correspond to the actual snapshot validators as valset_execution may still contain non-snapshot validators. A concrete scenario where this could happen would be the following:

1. Initially, there are 201 validators ordered from index [0, 1, 2 ... 200] in valset_execution where valset_execution[i+1].stake > valset_execution[i].stake for all i (stakes are in ascending order).

2. During syscall_snapshot, we place the top 200 validators into the consensus view. Thus the valset_consensus will contain the validator [1, 2 ... 200] by index from valset_execution. Importantly, validator index 0 in valset_execution is not removed as it is not added to the removals array (since flags == ValidatorFlagsOk), so valset_execution still remains [0, 1, 2 ... 200].

uint64_t const num_validators = vars.valset_execution.length();    for (uint64_t i = 0; i < num_validators; i += 1) {        auto const val_id = vars.valset_execution.get(i).load();        auto const val_execution = vars.val_execution(val_id);        // TODO: once Maged's speculative execution is merged, move this        // into a separate loop.        auto const flags = val_execution.get_flags();        if (MONAD_LIKELY(flags == ValidatorFlagsOk)) {            uint256_t const stake = val_execution.stake().load().native();            heap.emplace(val_id, stake);            if (heap.size() > ACTIVE_VALSET_SIZE) {                heap.pop(); // smallest element removed            }        }        else {            removals.push_back(i);        }    }

3. On the next next epoch change, where valset_consensus will become valset_snapshot after the boundary block, and thus the new accumulators for each validator in the snapshot validator set that has passed through the epoch will need to be computed.

• However, referring to the first code snippet, the first 200 active validators of valset_execution will have their accumulators updated meaning to say [0, 1, 2 ... 199] present in valset_execution will be updated. However, in actual fact valset_snapshot consists of [1, 2 ... 199, 200] present in valset_execution, thus not all snapshot validators will have their accumulators updated.

Another scenario would be that if a validator auth address withdraws all its stake while it is active in the current valset_consensus. When syscall_snapshot is called, this validator would be removed from valset_execution. However since it is currently in valset_consensus it must be retained in valset_snapshot after the boundary block. When iterating through valset_execution during syscall_epoch_change, the validator present in valset_snapshot will not be accessible in valset_execution and thus its accumulator will not be updated.

Recommendation

It should not be assumed that the first N validators in valset_execution are present in valset_snapshot. You need to iterate through each item in valset_snapshot to obtain the correct val_id

Description

(Issue found in commit hash 4cbb1742cd31ee30a0d2c6edb698400d9d70f9d8)

StakingContract::precompile_add_validator interprets 48 bytes of input as bls_pubkey_serialized:

auto const bls_pubkey_serialized =        unaligned_load<byte_string_fixed<48>>(consume_bytes(reader, 48).data());

It deserializes this into a Bls_Pubkey:

Bls_Pubkey bls_pubkey(bls_pubkey_serialized);

Bls_Pubkey(byte_string_fixed<48> const &serialized)    {        parse_result_ = blst_p1_deserialize(&pubkey_, serialized.data());    }

blst_p1_deserialize calls POINTonE1_Deserialize_Z, which, based on bit flags in the first byte of the input, decides whether to interpret it as a uncompressed (calls POINTonE1_Deserialize_BE which reads 96 bytes) or compressed (calls POINTonE1_Uncompress_Z which reads 48 bytes) point:

unsigned char in0 = in[0];
    if ((in0 & 0xe0) == 0)        return POINTonE1_Deserialize_BE(out, in);
    if (in0 & 0x80)             /* compressed bit */        return POINTonE1_Uncompress_Z(out, in);

(Reference: https://github.com/supranational/blst/blob/6d960cd05d6fe2b5bc9ba161edf0c1a131b87c4c/src/e1.c#L331-L337)

If a user manipulates the first byte of bls_pubkey_serialized so that blst interprets it as an uncompressed key, blst will overread bls_pubkey_serialized by 48 bytes.

By the same token, a crafted bls_signature_serialized can cause a 96 byte overread in equivalent logic in blst_p2_deserialize.

Minimal proof of concept:

$ cat x.cpp && $CXX $CFLAGS -I bindings/ x.cpp libblst.a && ./a.out #include <blst.h>#include <array>#include <cstdint>
int main(void) {    std::array<uint8_t, 48> bls_pubkey_serialized = {};    blst_p1_affine p;    blst_p1_deserialize(&p, bls_pubkey_serialized.data());    return 0;}===================================================================2365033==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ba040ede050 at pc 0x5632af688f52 bp 0x7ffe10f28f50 sp 0x7ffe10f28f48READ of size 1 at 0x7ba040ede050 thread T0    #0 0x5632af688f51 in limbs_from_be_bytes /home/jhg/staking-blst-bug/blst/./src/bytes.h:24:17    #1 0x5632af688f51 in POINTonE1_Deserialize_BE /home/jhg/staking-blst-bug/blst/./src/e1.c:303:5    #2 0x5632af688f51 in POINTonE1_Deserialize_Z /home/jhg/staking-blst-bug/blst/./src/e1.c:334:16    #3 0x5632af683cef in main /home/jhg/staking-blst-bug/blst/x.cpp:8:5

Memory exfiltration

Because the bug provides a read primitive it seems reasonable to use this as an memory exfiltration mechanism, where unrelated process memory is reflected back to the attacker. unaligned_load<byte_string_fixed<48>> causes the program to make a copy of the input data on the local stack, so any bytes adjacent to may be unrelated or uninitialized data.

However, no memory contents is reflected back directly. The deserialization functions will only succeed if the out-of-bounds bytes represent an Y coordinate corresponding to the attacker-specified X coordinate. precompile_add_validator reverting or not is observable to the attacker. If the attacker specifies a sets of inputs that would normally make precompile_add_validator succeed, they can adjust that input such that the first byte of the bls public key so that an overread occurs. precompile_add_validator will then succeed if and only if the 48 bytes adjacent to bls_pubkey_serialized constitute a valid Y coordinate. This setup can act as a binary oracle which divulges whether or not the out-of-bounds bytes have some specific value.

The attacker would hypothesize that the out-of-bounds memory region comprises a specific set of 48 bytes. In order to make the oracle work, they'd have to find the X coordinate that matches this Y coordinate. They would then invoke the oracle which confirms or rejects the hypothesis.

With many cryptographic elliptic curves it is infeasible to compute the affine X coordinate from a given affine Y coordinate, such that the point (X,Y) is on the curve. However, this is possible with BLS12-381:

Sagemath:

p = 0x1a0111ea397fe69a4b1ba7b6434bacd764774b84f38512bf6730d2a0f6b0f6241eabfffeb153ffffb9feffffffffaaabFp = GF(p)
def deduce_x(y):    y = Fp(y)    k = y**2 - 4    if k == 0:        return [Fp(0)]    else:        return k.nth_root(3, all=True)

However, the code requires that public keys (and signatures) are not only on the curve, but they are also in the prime-order subgroup:

class Bls_Pubkey {    ...    ...    bool is_valid() const noexcept    {        // NOTE: deserializing already checks the point is on the curve        return parse_result_ == BLST_SUCCESS &&               blst_p1_affine_in_g1(&pubkey_) &&               !blst_p1_affine_is_inf(&pubkey_);    }

class Bls_Signature {    ....    ....    bool is_valid() const noexcept    {        // NOTE: deserializing already checks the point is on the curve        return parse_result_ == BLST_SUCCESS && blst_p2_affine_in_g2(&sig_) &&               !blst_p2_affine_is_inf(&sig_);    }

Prime-order subgroup points are a very sparse subset of curve points; only about 1 in 2^127 arbitrary Y coordinates will have subgroup membership.

Without this constraint, it might have been feasible to leverage the oracle to divulge memory layout details that could be meaningful for exploiting write primitives. The subgroup requirement significantly limits any exfiltration opportunities.

Stability

Small buffer overreads like these usually do not cause crashes, but it may happen with aggressive compiler optimization.

Consensus

It may be possible to groom the process stack contents such that a call to precompile_add_validator with a specific input and msg_value reverts sometimes, but not always. This would entail a consensus failure as nodes diverge in their chain state.

An attacker may compute the Y coordinate of a BLS public key that would ordinarily make the call to precompile_add_validator succeed. Instead of sending the public key in compressed form, they first make one or more calls to precompile_add_validator with the 48-byte Y coordinate stored somewhere in input.

Then, they'd call precompile_add_validator as one ordinarily would (with a valid BLS public key and other variables), except that they clear the compressed bit.

blst_p1_uncompress will now read both the X and Y coordinate, overreading the 48 bytes adjacent to the X coordinate. With some non-zero probability, the 48 bytes of out-of-bounds bytes equal the valid Y coordinate, and the call succeeds.

Ordinarily, the odds of interpreting an Y coordinate from unrelated stack memory would be miniscule, but grooming techniques could make this feasible.

Recommendation

Either reject uncompressed points immediately by testing the first byte of their serialized representation, or call compressed-only deserialization functions that will fail for any uncompressed representations.

Description

An RPC-based DoS vulnerability exists where malicious eth_call requests can trigger exception-based failures in balance overflow checks. The vulnerability occurs in /monad/category/execution/ethereum/state3/state.hpp:365-369 where balance overflow protection uses assertions that can disrupt RPC service availability.

Affected Code:

// state.hpp:365-369 - Balance overflow checkMONAD_ASSERT_THROW(    std::numeric_limits<uint256_t>::max() - delta >= account.value().balance,    "balance overflow");//  ↑ THROWS EXCEPTION if: delta + account.balance > UINT256_MAX
account.value().balance += delta;
// rpc/eth_call.cpp - RPC balance manipulationif (balance > intx::be::load<uint256_t>(state.get_balance(address))) {    state.add_to_balance(        address,        balance - intx::be::load<uint256_t>(state.get_balance(address)));}

The assertion triggers when delta + account.balance > UINT256_MAX during RPC call simulation, causing MonadException to be thrown, potentially disrupting RPC service.

Proof of Concept

RPC DoS Attack Scenario:

// Malicious eth_call request with state overrideeth_call({  "to": "0x742D35CC6AF93F4D2E1EDC04e1C77FD2FDbc4C09",  "data": "0x...", // Any contract call  "stateOverrides": {    "0x742D35CC6AF93F4D2E1EDC04e1C77FD2FDbc4C09": {      "balance": "0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFE"      // Balance set to UINT256_MAX - 1    }  }})

Attack Execution:

1. Attacker crafts eth_call with state override setting target account balance to near UINT256_MAX
2. RPC handler processes the call and applies balance changes via add_to_balance()
3. Any delta > 1 triggers the overflow condition: delta + (UINT256_MAX-1) > UINT256_MAX
4. MONAD_ASSERT_THROW fires, throwing MonadException
5. RPC call causes assertion to trigger and node crashes

Impact: RPC service disruption.

Recommendation

Implement overflow validation in RPC state override processing to prevent exception-based DoS:

// Safe balance override validation for RPC callsif (state_delta.balance.has_value()) {    auto const requested_balance = intx::be::unsafe::load<uint256_t>(        state_delta.balance.value().data());        // Validate balance is within reasonable limits for simulation    if (requested_balance > std::numeric_limits<uint256_t>::max() / 2) {        // Return error for unrealistic balance values instead of processing        return Error("Balance override value too large for simulation");    }        auto const current_balance = intx::be::load<uint256_t>(state.get_balance(address));    if (requested_balance > current_balance) {        auto const delta = requested_balance - current_balance;        // Check if addition would overflow before calling add_to_balance        if (delta > std::numeric_limits<uint256_t>::max() - current_balance) {            return Error("Balance overflow in state override");        }        state.add_to_balance(address, delta);    } else {        state.subtract_from_balance(address, current_balance - requested_balance);    }}

Alternative: Add input validation to reject state overrides with unrealistic balance values before they reach the balance manipulation code.

Description

A network participant can ping a node and be added to the peer list. However, there are a few issues:

• The node accepts whatever IP address the peer declares, regardless of the source of the packet.
• There is no restriction on the size of the peer list.
• Each ping triggers a signature check.

An attacker could spin up a single fake node implementation, or several, which only handles pings and pongs, and flood the network, filling up peer lists and overloading honest nodes.

Recommendation

Put a hard limit on the size of the peer list. It is separate from the dedicated full nodes and epoch validators list, and thus not critical to consensus. Keep validators and full nodes in the peer list and do not eject them, so that network discovery can reasonably be expected to function.

Description

The JSON-RPC server processes and parses JSON requests before applying rate limiting controls, creating potential for memory exhaustion attacks within configured payload limits. JSON payloads can be manipulated to be much larger in memory due to the underlying storage methods, allowing for 2MB JSON messages to consume 12-16MBs in memory. When batched these messages can consume significant amounts of memory.

Memory Amplification Mechanism: serde_json::from_slice() converts compact JSON into serde_json::Value enum structures:

• JSON strings → heap-allocated String objects (capacity overhead)
• JSON arrays → Vec<Value> with element boxing (24+ bytes per Value enum)
• JSON objects → HashMap<String, Value> with hash table overhead
• Numbers → enum variants with discriminant tags

Example: "key":[1,2,3] (12 bytes) → String(4) + Vec header + 3×Value enums ≈ 80+ bytes (6-8x amplification of message size into memory storage size)

Attack Impact:

• Single request: 2MB JSON → 12-16MB memory
• Double parsing penalty (lines 18 + 81)
• Batch: 5,000 × 16MB = 80GB potential per IP

Primary Vulnerability: Parsing Before Rate Limiting

Location: monad-bft/monad-rpc/src/handlers/mod.rs:65-89

pub async fn rpc_handler(body: bytes::Bytes, app_state: web::Data<MonadRpcResources>) -> HttpResponse {    // VULNERABLE: JSON parsing occurs BEFORE any rate limiting    let request: RequestWrapper<Value> = match serde_json::from_slice(&body) {        Ok(req) => req,        Err(e) => return HttpResponse::Ok().json(Response::from_error(JsonRpcError::parse_error())),    };        // VULNERABLE: Second JSON parsing - still before rate limiting      let Ok(request) = serde_json::from_value::<Request>(json_request.clone()) else {        return HttpResponse::Ok().json(Response::from_error(JsonRpcError::parse_error()));    };    // ... continues to method dispatch where rate limiting MAY be applied}

Rate Limiting Coverage Gap

Rate limiting only exists in 2 methods (eth_call, eth_estimateGas) out of 25+ available methods:

Protected Methods:

• eth_call
• eth_estimateGas

Unprotected Methods :

• debug_traceBlockByNumber
• debug_traceCall
• eth_sendRawTransaction
• eth_getLogs
• eth_getTransactionByHash
• eth_getBlockByHash
• eth_getBalance
• eth_getCode
• eth_getStorageAt
• eth_blockNumber
• eth_chainId

Current Protections

• HTTP payload limit: 2MB per request (configurable)
• Batch limit: 5,000 requests per batch (configurable)
• Global semaphore: 1,000 concurrent requests across ALL IPs
• No per-IP rate limiting

Proof-Of-Concept

Memory Amplification Attack

{  "jsonrpc": "2.0",  "method": "eth_getBalance", // Unprotected method  "params": ["0x1234567890123456789012345678901234567890", "latest"],  "id": 1,  "_attack_payload": {    "large_array": [/* ~200k elements approaching 2MB limit */],    "nested_objects": {/* complex nested structure */}  }}

Batch Amplification

[  {"jsonrpc": "2.0", "method": "eth_getBalance", "params": [...], "_payload": {...}},  {"jsonrpc": "2.0", "method": "eth_getCode", "params": [...], "_payload": {...}},  // ... up to 5,000 requests per batch  // Total: 5,000 × memory_amplification per 2MB HTTP request]

Attack Flow:

1. HTTP layer accepts 2MB payload
2. serde_json::from_slice() - Full JSON parsing
3. serde_json::from_value() - Second parsing

Recommendation

1. Pre-parsing IP rate limiting: Check IP limits before JSON parsing
2. Global parsing semaphore: Limit concurrent JSON parsing operations
3. Method coverage: Extend rate limiting beyond just eth_call/eth_estimateGas

Description

A memory exhaustion vulnerability exists by combining two separate RaptorCast weaknesses: an unbounded pending message cache and per-decoder memory allocation amplification. A malicious validator can leverage both vulnerabilities to achieve large memory consumption by flooding the system with incomplete messages that maximize per-decoder allocation while avoiding automatic cleanup mechanisms.

Attack Synopsis:

• Unbounded cache issue: Unlimited decoder instance creation via unbounded cache for incomplete messages
• Memory allocation amplification: Maximizes memory consumption per decoder instance
• Combined effect: Multiplicative memory exhaustion (Max per-decoder allocation × Unlimited incomplete decoder instances)
• Cleanup bypass: Incomplete messages never trigger successful decoding cleanup

Vulnerable Code Locations:

// udp.rs:135 - Unbounded cache enabling unlimited decoder instancespending_message_cache: LruCache::unbounded(),
// udp.rs:316-327 - Per-decoder memory allocation based on attacker-controlled app_message_lenlet num_source_symbols = app_message_len.div_ceil(symbol_len).max(SOURCE_SYMBOLS_MIN);let encoded_symbol_capacity = MAX_REDUNDANCY    .scale(num_source_symbols)    .expect("redundancy-scaled num_source_symbols doesn't fit in usize");ManagedDecoder::new(num_source_symbols, encoded_symbol_capacity, symbol_len)    .map(|decoder| DecoderState {        decoder,        recipient_chunks: BTreeMap::new(),        encoded_symbol_capacity,        seen_esis: bitvec![usize, Lsb0; 0; encoded_symbol_capacity], // Large per-decoder allocation    })
// udp.rs:386-389 - Automatic cleanup only occurs on successful decodinglet decoded_state = self    .pending_message_cache    .pop(&key)  // ← Cleanup only happens here, after successful decode    .expect("decoder exists");

Proof-Of-Concept

// PREREQUISITE: Attacker must be active validator with signature authoritylet validator_keypair = malicious_validator_keys; // Requires validator stake
// Maximize per-decoder memory allocationlet maximized_app_message_len = u32::MAX;        // 4,294,967,295 byteslet minimal_symbol_len = 960;                    // Small symbol size for max division result
// Create unlimited incomplete decoder instancesfor attack_iteration in 0..100_000 {    let unique_message_content = format!("incomplete_attack_{}", attack_iteration);    let unique_timestamp = base_timestamp + attack_iteration;        let malicious_incomplete_packet = create_incomplete_chunk(        &validator_keypair,                      // Valid validator signature        maximized_app_message_len,               // Memory amplification: Trigger max allocation        minimal_symbol_len,                      // Memory amplification: Maximize division result          unique_message_content,                  // Unbounded cache: Unique cache key        unique_timestamp,                        // Unbounded cache: Unique cache key component        current_epoch,                          // Must be active validator in epoch        incomplete_chunk_design,                 // CRITICAL: Ensure message can NEVER complete    );        send_udp_packet_to_target(malicious_incomplete_packet);}

Attack Impact

Memory Consumption:

• Per-decoder allocation: ~8MB per decoder instance (worst case)
• Attack scaling: 1,000 decoders = 8GB, 10,000 decoders = 80GB
• No automatic cleanup for incomplete messages
• Attack persists until manual intervention

Network Impact:

• Memory exhaustion leading to OOM conditions
• Node performance degradation and potential crashes
• Multi-node attack possible
• Consensus participation degradation

Attack Requirements:

• Active validator status (high barrier to entry)
• UDP message access

Recommendation

1. Implement bounded cache with limits: Max decoders per validator and global memory bounds
2. Add timeout-based cleanup: Automatically remove incomplete decoders after timeout period
3. Per-validator rate limiting: Limit decoder creation rate per validator
4. Memory monitoring: Alert on unusual memory allocation patterns
5. Input validation: Reasonable limits on app_message_len and related parameters

Description

(Issue found in commit hash fc820c9ee9ab310c4fdd5e1888f72164c0b871c8)

It is possible to cause a denial-of-service to RPC nodes via eth_call by using a state override on the staking contract.

The problem is that there exists a MONAD_ASSERT on the staking contract that checks if the current contract balance is >= the amount of the withdrawal request during precompile_withdraw.

Result<byte_string> StakingContract::precompile_withdraw(    byte_string_view const input, evmc_address const &msg_sender,    evmc_uint256be const &){    ...    auto withdrawal_request_storage =        vars.withdrawal_request(val_id, msg_sender, withdrawal_id);    auto withdrawal_request = withdrawal_request_storage.load_checked();    if (MONAD_UNLIKELY(!withdrawal_request.has_value())) {        return StakingError::UnknownWithdrawalId;    }    ...    auto const contract_balance =        intx::be::load<uint256_t>(state_.get_balance(STAKING_CA));    MONAD_ASSERT(contract_balance >= withdrawal_amount);    send_tokens(msg_sender, withdrawal_amount);    ...}

Hence, it is possible with eth_call state override feature, to set the staking contract balance to 0, or set the withdrawal_amount stored in the withdrawal_request to be greater than the staking contract balance. This will cause the MONAD_ASSERT to fail, therefore causing a denial-of-service of the RPC node.

Recommendation

Eitther use MONAD_ASSERT_THROW that throws a program exception that is handled in eth_call instead of MONAD_ASSERT which will abort

Or revert earlier if withdrawal_amount > contract_balance

Description

(Issue found in commit hash fc820c9ee9ab310c4fdd5e1888f72164c0b871c8)

The EIP-7702 spec notes the following:

A related issue is that an EOA’s nonce may be incremented more than once per transaction. Because clients already need to be robust in a worse scenario (described above), it isn’t a major concern. However, clients should be aware this behavior is possible and design their transaction propagation accordingly.

For Monad this is a more serious concern because of delayed execution. A preceding transaction can invalidate other transactions in a proposal by bumping the delegated EOA's nonce via CREATE / CREATE2. This invalid transaction will thus not be charged any gas as a result but will take up space in the proposal enabling virtually free block stuffing attacks.

Monad attempts to solve this by disabling CREATE and CREATE2 opcode when executing delegated code in evmc_host.cpp.

evmc_host.hpp#L129-L132

if (msg.kind == EVMC_CREATE || msg.kind == EVMC_CREATE2) {            if (!create_inside_delegated_ && (msg.flags & EVMC_DELEGATED)) {                return evmc::Result{EVMC_UNDEFINED_INSTRUCTION, msg.gas};            }

But there is a flaw with how it is handled here. Importantly, in the VM, the preceding CREATE / CREATE2 opcode implementation will pass in msg.flags = 0 when calling the EVMC Host.

create.hpp#L78-L94

auto message = evmc_message{            .kind = kind,            .flags = 0,            .depth = ctx->env.depth + 1,            .gas = gas,            .recipient = evmc::address{},            .sender = ctx->env.recipient,            .input_data = (*size > 0) ? ctx->memory.data + *offset : nullptr,            .input_size = *size,            .value = bytes32_from_uint256(value),            .create2_salt = bytes32_from_uint256(salt_word),            .code_address = evmc::address{},            .code = nullptr,            .code_size = 0,        };
        auto result = ctx->host->call(ctx->context, &message);

Thus msg.flags & EVMC_DELEGATED will always be 0, and the check will never work.

Recommendation

The check needs to be shifted into the VM layer.

Description

(Issue found in commit hash fc820c9ee9ab310c4fdd5e1888f72164c0b871c8)

The EIP-7702 spec notes the following:

A related issue is that an EOA’s nonce may be incremented more than once per transaction. Because clients already need to be robust in a worse scenario (described above), it isn’t a major concern. However, clients should be aware this behavior is possible and design their transaction propagation accordingly.

For Monad this is a more serious concern because of delayed execution. A preceding transaction can invalidate other transactions in a proposal by bumping the delegated EOA's nonce via CREATE / CREATE2. This invalid transaction will thus not be charged any gas as a result but will take up space in the proposal enabling virtually free block stuffing attacks.

Monad attempts to solve this by disabling CREATE and CREATE2 opcode when executing delegated code in evmc_host.cpp.

evmc_host.hpp#L129-L132

if (msg.kind == EVMC_CREATE || msg.kind == EVMC_CREATE2) {            if (!create_inside_delegated_ && (msg.flags & EVMC_DELEGATED)) {                return evmc::Result{EVMC_UNDEFINED_INSTRUCTION, msg.gas};            }

There is already a bug with the implementation in https://cantina.xyz/code/ed78120a-ad47-43bf-9d93-eb3863eb2a3b/findings/51 but this report will showcase another way to bypass the check.

The EVMC_DELEGATED flag is used to track whether the current call frame is currently within a context of a delegated EOA account. The problem is that for DELEGATECALL and CALLCODE opcode, the EVMC_DELEGATED flag will be lost when entering the DELEGATECALL and CALLCODE call frames.

When a DELEGATECALL and CALLCODE occurs, dest_address == code_address as DELEGATECALL or CALLCODE affects the msg.recipient, as such the EVMC_DELEGATED flag will be removed from the DELEGATECALL or CALLCODE call frame.

call.hpp#L92-L167

auto recipient = (call_kind == EVMC_CALL || static_call)                   ? dest_address                   : ctx->env.recipient;        ...        auto message = evmc_message{            ...            .flags = message_flags(                ctx->env.evmc_flags, static_call, dest_address != code_address),            ...        };

call.hpp#L26-L41

inline std::uint32_t message_flags(        std::uint32_t env_flags, bool static_call, bool delegation_indicator)    {        if (static_call) {            env_flags = static_cast<std::uint32_t>(EVMC_STATIC);        }
        if (delegation_indicator) {            env_flags |= static_cast<std::uint32_t>(EVMC_DELEGATED);        }        else {            env_flags &= ~static_cast<std::uint32_t>(EVMC_DELEGATED);        }
        return env_flags;    }

Since the call frame no longer contains the EVMC_DELEGATED flag, the call frame can execute a CREATE / CREATE2 opcode to bump its nonce.

The msg.sender of the CREATE / CREATE2 call frame will have its nonce bumped. Working backwards, the msg.sender of the CREATE / CREATE2 call frame is the msg.recipient of the DELEGATECALL and CALLCODE call frame which equal to the EOA delegated code which executed the DELEGATECALL / CALLCODE and thus the delegated EOA will have its nonce bumped.

create.hpp#L62-L78

auto message = evmc_message{            ...            .sender = ctx->env.recipient,            ...        };
        auto result = ctx->host->call(ctx->context, &message);

evm.cpp#L202-L209

auto const nonce = state.get_nonce(msg.sender);    if (nonce == std::numeric_limits<decltype(nonce)>::max()) {        // overflow        evmc::Result result{EVMC_ARGUMENT_OUT_OF_RANGE, msg.gas};        call_tracer.on_exit(result);        return result;    }    state.set_nonce(msg.sender, nonce + 1);

Recommendation

DELEGATECALL and CALLCODE should always retain the EVMC_DELEGATED flag if it does contain it.

Addendum: In the following discussion with evmone maintainers, it was confirmed that this flag was only meant for the no-op precompile logic when an EOA is delegated to the precompile. Hence, we recommend resolving the delegation instead of relying on the EVMC_DELEGATED flag.

Description

static_validate_system_transaction is missing chain ID validation.

The only validation for static_validate_system_transaction is present here:

validator.rs#L73-L97

fn static_validate_system_transaction(        txn: &Recovered<TxEnvelope>,    ) -> Result<(), SystemTransactionError> {        if !Self::is_system_sender(txn.signer()) {            return Err(SystemTransactionError::UnexpectedSenderAddress);        }
        if !txn.tx().is_legacy() {            return Err(SystemTransactionError::InvalidTxType);        }
        if txn.tx().gas_price() != Some(0) {            return Err(SystemTransactionError::NonZeroGasPrice);        }
        if txn.tx().gas_limit() != 0 {            return Err(SystemTransactionError::NonZeroGasLimit);        }
        if !matches!(txn.tx().kind(), TxKind::Call(_)) {            return Err(SystemTransactionError::InvalidTxKind);        }
        Ok(())    }

This can allow a malicious block proposer to include an invalid system transaction which will fail during transaction validation in the execution layer which can lead to failed epoch / snapshot changes breaking validator set accounting.

execute_system_transaction.cpp#L59-L75

Result<Receipt> ExecuteSystemTransaction<rev>::operator()(){    ...    {        Transaction tx = tx_;        tx.gas_limit =            2'000'000; // required to pass intrinsic gas validation check        BOOST_OUTCOME_TRY(static_validate_transaction<rev>(            tx,            std::nullopt /* 0 base fee to pass validation */,            std::nullopt /* 0 blob fee to pass validation */,            chain_.get_chain_id(),            chain_.get_max_code_size(header_.number, header_.timestamp)));    }

validate_transaction.cpp#L55-L68

// EIP-155    if (MONAD_LIKELY(tx.sc.chain_id.has_value())) {        if constexpr (rev < EVMC_SPURIOUS_DRAGON) {            return TransactionError::TypeNotSupported;        }        if (MONAD_UNLIKELY(tx.sc.chain_id.value() != chain_id)) {            return TransactionError::WrongChainId;        }    }

Recommendation

Validate in monad-bft that the staking syscall has the correct chain ID.

Description

static_validate_system_transaction is missing malleable signature validation.

The only validation for static_validate_system_transaction is present here:

validator.rs#L73-L97

fn static_validate_system_transaction(        txn: &Recovered<TxEnvelope>,    ) -> Result<(), SystemTransactionError> {        if !Self::is_system_sender(txn.signer()) {            return Err(SystemTransactionError::UnexpectedSenderAddress);        }
        if !txn.tx().is_legacy() {            return Err(SystemTransactionError::InvalidTxType);        }
        if txn.tx().gas_price() != Some(0) {            return Err(SystemTransactionError::NonZeroGasPrice);        }
        if txn.tx().gas_limit() != 0 {            return Err(SystemTransactionError::NonZeroGasLimit);        }
        if !matches!(txn.tx().kind(), TxKind::Call(_)) {            return Err(SystemTransactionError::InvalidTxKind);        }
        Ok(())    }

This can allow a malicious block proposer to include an invalid system transaction by flipping the s value of the system transaction to upper-half of the curve.

This will fail during transaction validation in the execution layer which can lead to failed epoch / snapshot changes breaking validator set accounting.

execute_system_transaction.cpp#L59-L75

Result<Receipt> ExecuteSystemTransaction<rev>::operator()(){    ...    {        Transaction tx = tx_;        tx.gas_limit =            2'000'000; // required to pass intrinsic gas validation check        BOOST_OUTCOME_TRY(static_validate_transaction<rev>(            tx,            std::nullopt /* 0 base fee to pass validation */,            std::nullopt /* 0 blob fee to pass validation */,            chain_.get_chain_id(),            chain_.get_max_code_size(header_.number, header_.timestamp)));    }

validate_transaction.cpp#L55-L68

// EIP-2    if (MONAD_UNLIKELY(!silkpre::is_valid_signature(            tx.sc.r, tx.sc.s, rev >= EVMC_HOMESTEAD))) {        return TransactionError::InvalidSignature;    }

Recommendation

Validate that the s value of the system transaction signature is in the lower-half of the curve. Example:

validation.rs#L100-L106

fn eip_2(tx: &TxEnvelope) -> Result<(), TransactionError> {        // verify that s is in the lower half of the curve        if tx.signature().normalize_s().is_some() {            return Err(TransactionError::UnsupportedTransactionType);        }        Ok(())    }

Description

In Monad VM, the CREATE / CREATE2 opcode implementation does a max initcode size check and rejects initcode that is above 0xC000 = 49152 bytes.

create.hpp#L42

if constexpr (Rev >= EVMC_SHANGHAI) {            if (MONAD_VM_UNLIKELY(*size > 0xC000)) {                ctx->exit(StatusCode::OutOfGas);            }        }

This matches Ethereum mainnet's parameters, where max_init_code_size = 2 * max_code_size, where max_code_size = 24576.

However, Monad Chain defines a different parameter for max_code_size, which we can see:

monad_chain.cpp#L62-L64

if (MONAD_LIKELY(monad_rev >= MONAD_TWO)) {        return 128 * 1024;    }

As seen above, the max_code_size for Monad revision 2 and above is 128 * 1024 = 131072.

That means the actual max_init_code_size should be 2 * max_code_size = 262144, however as seen above, the CREATE / CREATE2 opcode implementation will reject any initcode above 49152 bytes.

This means that while Monad attempts to allow creation of contracts up to a max_code_size of 128kB, in actual fact, it only allows the creation of contracts up to 48kB, since the initcode which should consist of both the constructor code and the contract code only allows 48kB for both. This might cause certain factory contracts to be bricked, for instance.

Recommendation

Instead of hardcoding the value to 0xC000 = 49152 bytes, the check needs to be changed to use 2 * max_code_size fetched from the Monad chain config.

Description

mod.rs#L370-L376

let tx_size = tx.size();            if total_size                .checked_add(tx_size)                .is_none_or(|new_total_size| new_total_size > proposal_byte_limit)            {                return TrackedTxHeapDrainAction::Skip;            }

MonadBFT enforces a maximum size for block proposals when constructing a proposal from the mempool.

As per the the latest CHAIN_PARAMS_V_0_8_0 revision, the relevant parameters are:

const CHAIN_PARAMS_V_0_8_0: ChainParams = ChainParams {    tx_limit: 5_000,    proposal_gas_limit: 150_000_000,    proposal_byte_limit: 2_000_000,    vote_pace: Duration::from_millis(500),};

Currently it is possible to occupy the full block space while paying only ~5% of the maximum 150_000_000 gas limit by including a transaction with only zero bytes. The minimum gas consumed by the transaction would be 21_000 + 2_000_000 * 4 = 8_021_000 (21_000 + 2_000_000 * 10 = 20_021_000 (= ~13%) if Prague data floor gas is enabled), enabling cheaper block stuffing attacks.

Additionally, when dynamic EIP-1559 block base fee is implemented, the gas consumed will be significantly lower than the target gas limit (assuming target gas limit = 50% of maximum gas limit = 75_000_000), resulting in decreasing base fee over time.

Recommendation

This requires either rethinking the proposal_gas_limit versus the proposal_byte_limit to constrain the amount of calldata that can fit within the proposal_byte_limit or changing the calldata gas cost to ensure that the maximum calldata sent is less than proposal_byte_limit.

Category Labs: This is expected behaviour currently. We're aware the current proposal construction algorithm is suboptimal (ignores the fact that it is now a multi-dimensional knapsack problem). Improving it is on our roadmap. We have a relatively simple modified sorting algo that could help mitigate worst-cases, but we'll likely explore better options.

Description

In the pending pool, the number of transactions present in the pending pool if tracked by self.num_txs and is used for a variety of checks, for example to determine whether to drop a transaction if self.num_txs >= MAX_TXS.

The problem is that on remove(), which is called when an address is promoted from the pending pool, the num_txs is decreased by 1 instead of the actual number of transactions an address has in the pending pool.

mod.rs#L84-L92

pub fn remove(&mut self, address: &Address) -> Option<PendingTxList> {        if let Some(tx) = self.txs.swap_remove(address) {            self.num_txs = self                .num_txs                .checked_sub(1)                .expect("num txs does not underflow");
            return Some(tx);        }

As such the self.num_txs will be tracked incorrectly by the pending pool, and this could result in transactions incorrectly being dropped even though MAX_TXS has not been reached in the pending pool.

Recommendation

Decrement self.num.txs by the actual number of transactions and address has in the pending pool during remove()

Description

In the pending pool, the number of transactions present in the pending pool if tracked by self.num_txs and is used for a variety of checks, for example to determine whether to drop a transaction if self.num_txs >= MAX_TXS.

The problem is that on try_insert_tx, num_txs is incorrectly incremented by 1, even during transaction replacement.

mod.rs#L64-L69

indexmap::map::Entry::Occupied(tx_list) => {                let tx = tx_list.into_mut().try_insert_tx(event_tracker, tx)?;
                self.num_txs += 1;                Some(tx)            }

list.rs#L58-L69

Entry::Occupied(mut entry) => {                let existing_tx = entry.get();
                if &tx <= existing_tx {                    event_tracker.drop(tx.hash(), EthTxPoolDropReason::ExistingHigherPriority);                    return None;                }
                event_tracker.replace_pending(existing_tx.hash(), tx.hash(), tx.is_owned());                entry.insert(tx);                Some(entry.into_mut())            }

Here, we see that in the pending pool, if a nonce in the transaction pool is already occupied, if a transaction is better than the currently existing transaction, the transaction will be replaced and Some(entry.into_mut()) will be returned.

This causes the self.num.txs to be incorrectly incremented, self.num_txs += 1;. When in actual fact, the total number of transactions in the pending pool has not changed since the transaction has been replaced by another better one.

As such the self.num_txs will be tracked incorrectly by the pending pool, and this could result in transactions incorrectly being dropped even though MAX_TXS has not been reached in the pending pool.

Recommendation

Only increment the self.num_txs counter if the current nonce entry is vacant.

Summary

The RaptorCast design calls for sending an excess of blocks to validators to guarantee sufficient redundancy. The algorithm as implemented produces too few blocks, leading to insufficient redundancy.

Finding Description

The raptorcast broadcast algorithm differs from the one in the documentation as described in "3: Broadcast Strategy":

The design of RaptorCast dictates that redundancy is achieved through producing $M' = K \times r + n$ chunks, with $K$ being the smallest number of chunks that could fit the message, $r$ being a redundancy factor (hard-coded), and $n$ being the number of validators. The number of chunks send to each validator is a fraction of $M$ corresponding to the validator's proportion of the total stake.

The algorithm in udp.rs, however, produces $M = K \times r$ blocks and rounds down the number of chunks to send each validator. Validators with small stakes may receive no blocks, and instead have their blocks grouped in with the next validator being in the iteration. The discrepancy is thus greater for $K$ (small message sizes) and large $n$ (large validator sets).

The redundancy design "guarantees that each honest validator receives sufficient chunks to decode, even with one-third Byzantine nodes". Without it, there is a risk of consensus failure in case the number of Byzantine nodes grows past what $r$ accounts for, the network failure is unusually high, or simply when the messages size leads to an unfortunate level of rounding down when calculating the number of chunks to send to each validator.

Impact Explanation

With fewer distinct first‑hop re‑broadcasters per message, any outage or byzantine behavior by the (few) assigned recipients disproportionately harms overall symbol fan‑out. Because only the original recipient re‑broadcasts validators assigned zero chunks also contribute zero second‑hop bandwidth for that chunk.

There is also higher latency to reach sufficient validators, especially under moderate packet loss.

Likelihood Explanation

A validator gets 0 chunks if the total stake as a multiple of their individual stake is larger than the number of packets: total_stake / stake_i > num_packets. It is virtually guaranteed that some validators will receive less than their allotted amount.

Proof of Concept

For example, as a degenerate case, when num_packets == 1 the continue on line 754 will be hit in every iteration. If it's 2, then it will be hit at every iteration unless some validator has more than half of the total stake, etc.

Regardless, this will undercount the packages to be sent out and possibly not send all chunks, if the last end_idx is less than chunk_datas.len().

Recommendation

When calculating the number of packets, make the following addition, after line 603 in udp.rs:

udp.rs starting at line 599:

if let BuildTarget::Broadcast(epoch_validators) = &build_target {    num_packets = num_packets        .checked_mul(epoch_validators.view().len())        .expect("num_packets doesn't fit in usize")} else if let BuildTarget::Raptorcast((epoch_validators, full_nodes_view)) = &build_target {    let n = epoch_validators.view().len();    let extra = n.min((MAX_NUM_PACKETS as usize).saturating_sub(num_packets));    num_packets = num_packets + extra;}

This does not exactly match the number of packages described in the design, but overallocates reasonably.

Another approach to adding redundancy more robustly without too much extra complexity:

• calculate $M'$ as above, including $n$.
• before running the loop assigning stake, subtract $n$ from $M'$ to get $M$.
• create a variable $i$ to track of which loop iteration you are in.
• for every validator
  • assign m * running_stake / total_stake + i the to start_idx.
  • increment $i$ by $1$.
  • assign m * running_stake / total_stake + i the toend_idx
  • proceed as before

udp.rs starting at line 739:

let mut running_stake = 0;let mut chunk_idx = 0_u16;let mut nodes: Vec<_> = epoch_validators.view().iter().collect();let mut m = num_packets - epoch_validators.view().len();// Group shuffling so chunks for small proposals aren't always assigned// to the same nodes, until researchers come up with something better.nodes.shuffle(&mut rand::thread_rng());let  mut i = 0;for (node_id, validator) in &nodes {    let start_idx: usize = i +        (m as u64 * running_stake / total_stake) as usize;    i += 1;    running_stake += validator.stake.0;    let end_idx: usize = i +        (m as u64 * running_stake / total_stake) as usize;
    if let Some(addr) = known_addresses.get(node_id) {

This results in an identical algorithm to the existing implementation except each validator gets exactly one more chunk than they would have otherwise. The difference between this and the algorithm in the design is only that those validators for which $S_T$ divides $M \times S_i$. i.e. $S_T | M \times S_i$, will get one more package than they would otherwise. In realistic scenarios with large $S_T$ this will be rare.

Category Labs: We are aware of this issue and are working on a redesign that ensures at least probabilistic Byzantine Fault-Tolerance for Raptorcast, and scales well in the number of validators. That solution might not be ready for mainnet, and we are evaluating more short-term fixes.

Description

void pop_accept()    {        MONAD_ASSERT(version_);
        for (auto it = current_.begin(); it != current_.end(); ++it) {            it->second.pop_accept(version_);        }
        logs_.pop_accept(version_);
        --version_;    }

The current_ map tracks all the addresses that were accessed / touched / modified in the current transaction. This for loop is inefficient because it can iterate through addresses in current_ that have been accessed in the transaction, but have NOT been modified in the current call frame.

For example, an attacker could potentially access many addresses at the start of a transaction (via access list for example). This will result in access_account being called which will cause these addresses to be added to the current_ map, paying only 2400 gas for the access cost. As an example, an attacker can purchase 30000 addresses in the access list for 72M gas

evmc_access_status access_account(Address const &address)    {        auto &account_state = current_account_state(address); // address added to 'current_' map here        return account_state.access();    }

Then the attacker makes multiple precompile calls, each call is considered warm paying only 100 gas, at the end of each call, pop_accept will be called. However, the for loop will iterate through all 30000 addresses in the current_ even though these addresses were not modified at all in the precompile call. As an example an attacker can make 700000 calls using 70M gas. All in all, this results in 21 billion for loop iterations per block.

Recommendation

While it is unknown how viable is this attack vector. In the best case, the code is unoptimized as it is looping through the global current_ map which also includes addresses that do not contain the current version at the top of their version stack, and an optimization can be made to track ONLY the modified addresses to loop through for a given version via a Map<Version, std::vector<Address>> / std::stack<std::vector<Address>> variable to prevent iterating over unnecessary items in the current_ map

Category Labs: Local benchmarks confirm that this appears to be valid. We will be tracking it in this open issue

Description

The code reserves sufficient elements in temp but does not resize temp. It then writes to all the elements it reserved.

Reserving grows the memory capacity underlying the vector abstraction, but does not change the number of vector elements, and accessing any element beyond the vector's size is undefined behavior.

Proof of Concept

Minimal proof of concept demonstrating the general issue:

#include <vector>int main(void){    std::vector<int> x;    x.reserve(1000);    x[100] = 1;    return 0;}

If compiled with -D_GLIBCXX_DEBUG:

/usr/lib/gcc/x86_64-linux-gnu/14/../../../../include/c++/14/debug/vector:508:In function:    reference std::vector<int>::operator[](size_type) [_Tp = int, _Allocator     = std::allocator<int>]
Error: attempt to subscript container with out-of-bounds index 100, but container only holds 0 elements.
Objects involved in the operation:    sequence "this" @ 0x7fffffffdff0 {      type = std::debug::vector<int, std::allocator<int> >;    }Aborted (core dumped)

Recommendation

Either:

• Change temp.reserve(buffers_.size()); to temp.resize(buffers_.size());.
• Use emplace_back to add elements to temp, rather than accessing elements directly via temp[n] = ....

Description

Monad's networking layer lacks a comprehensive peer reputation and rate limiting system, which enables sustained resource consumption style DoS attacks. Due to the computational cost of ECDSA signature verification, Merkle proof verification, decompression, and RaptorCast's error correction decoding, a system to gate these flows is needed. Without proper rate limiting and reputation tracking, malicious peers can repeatedly abuse computational resources without consequences.

Proof-Of-Concept

Example Attack Vector 1: Merkle Proof CPU Exhaustion

// Attack via maximum depth Merkle proof verificationlet attack_message = craft_udp_message_with_merkle_proof(    tree_depth: 9,              // Maximum allowed depth    chunk_data: minimal_data,   // Small payload for efficiency    signature: valid_signature, // Authenticated attacker);
// Each message forces expensive operations:// 1. ECDSA signature recovery: ~50μs (well-resourced server)// 2. Merkle proof computation: ~4μs (SHA256 × depth, optimized)// 3. Message processing overhead: ~6μs// Total: ~60μs per attack message
// Sustained attack calculation:let attack_rate = 1000; // messages per secondlet cpu_consumption = attack_rate * 60; // 60ms per second = 6% CPU corelet daily_messages = 86_400_000; // 86.4 million verification operations per day
// No rate limiting enables unlimited sustained CPU consumption

Example Attack Vector 2: UDP/TCP Decompression CPU Exhaustion

Note: This attack works via both UDP (RaptorCast) and TCP message channels.

// Attack via computationally expensive compressed message payloadslet compression_attack = create_expensive_compressed_message(    compressed_size: 100_000,        // 100KB compressed payload    decompressed_size: 10_000_000,   // 10MB decompressed content    compression_complexity: HIGH,     // Computationally expensive to decompress);
// Attack flow (works for both UDP and TCP):// 1. Message passes signature verification (~50μs)// 2. ZSTD decompression operation (~20ms for complex payload on well-resourced server)// 3. Additional RLP parsing overhead (~5ms)// Total: ~25ms CPU time per attack message
// UDP-specific flow:// 1. UDP chunks received and decoded via RaptorCast → reconstructed message// 2. Reconstructed message goes through InboundRouterMessage::try_deserialize()// 3. Same decompression logic as TCP messages
// TCP-specific flow:// 1. TCP message received directly// 2. Goes through InboundRouterMessage::try_deserialize()// 3. Decompression logic applied
// UDP decompression attacklet udp_decompression_attack = UdpRaptorCastMessage {    signature: valid_signature,           // Pass authentication    compressed_app_message: compression_attack,    compression_version: DefaultZSTDVersion, // Force expensive decompression};
// TCP decompression attack  let tcp_decompression_attack = TcpMessage {    signature: valid_signature,           // Pass authentication    compressed_payload: compression_attack,    compression_level: MAXIMUM,           // Force expensive decompression};
// Sustained attack calculation:let attack_rate = 40; // messages per second (limited by decompression cost)let cpu_consumption = attack_rate * 25; // 1.0 seconds per second = 100% CPU corelet daily_cpu_hours = 24 * 1.0; // 24 CPU hours consumed per day
// No rate limiting enables sustained decompression CPU exhaustion via UDP or TCP// Multiple concurrent attackers can saturate all available CPU cores// UDP attacks have advantage: no TCP connection overhead, higher message throughput// TCP attacks have advantage: larger message size limits, direct connection