الوصف الكامل

rust-openssl provides OpenSSL bindings for the Rust programming language. From 0.9.24 to before 0.10.78, the FFI trampolines behind SslContextBuilder::set_psk_client_callback, set_psk_server_callback, set_cookie_generate_cb, and set_stateless_cookie_generate_cb forwarded the user closure's returned usize directly to OpenSSL without checking it against the &mut [u8] that was handed to the closure. This can lead to buffer overflows and other unintended consequences. This vulnerability is fixed in 0.10.78.

الإصدارات المتأثرة

>= 0.9.24, < 0.10.78

نوع الثغرة

CWE-126 — CWE-126

CVSS Vector

CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:N/VA:L/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

المراجع

الوصف الكامل

rust-openssl provides OpenSSL bindings for the Rust programming language. From 0.9.27 to before 0.10.78, Deriver::derive (and PkeyCtxRef::derive) sets len = buf.len() and passes it as the in/out length to EVP_PKEY_derive, relying on OpenSSL to honor it. On OpenSSL 1.1.x, X25519, X448, DH and HKDF-extract ignore the incoming *keylen, unconditionally writing the full shared secret (32/56/prime-size bytes). A caller passing a short slice gets a heap/stack overflow from safe code. OpenSSL 3.x providers do check, so this only impacts older OpenSSL. This vulnerability is fixed in 0.10.78.

الإصدارات المتأثرة

>= 0.9.27, < 0.10.78

نوع الثغرة

CWE-131 — CWE-131

CVSS Vector

CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:U

المراجع

الوصف الكامل

rust-openssl provides OpenSSL bindings for the Rust programming language. From 0.9.0 to before 0.10.78, the *_from_pem_callback APIs did not validate the length returned by the user's callback. A password callback that returns a value larger than the buffer it was given can cause some versions of OpenSSL to over-read this buffer. OpenSSL 3.x is not affected by this. This vulnerability is fixed in 0.10.78.

الإصدارات المتأثرة

>= 0.9.0, < 0.10.78

نوع الثغرة

CWE-125 — Out-of-bounds Read

CVSS Vector

CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:N/VA:L/SC:N/SI:N/SA:N/E:U

المراجع

الوصف الكامل

### Summary ``aes::unwrap_key()`` has an incorrect bounds assertion on the out buffer size, which can lead to out-of-bounds write. ### Details ``aes::unwrap_key()`` contains an incorrect assertion: it checks that `out.len() + 8 <= in_.len()`, but this condition is reversed. The intended invariant is `out.len() >= in_.len() - 8`, ensuring the output buffer is large enough. Because of the inverted check, the function only accepts buffers at or below the minimum required size and rejects larger ones. If a smaller buffer is provided the function will write past the end of `out` by `in_.len() - 8 - out.len()` bytes, causing an out-of-bounds write from a safe public function. ### Impact Vulnerable applications using AES keywrap and allowing attacker controlled buffer sizes could have an attacker trigger an out-of-bounds write.

الإصدارات المتأثرة

>= 0.10.24, < 0.10.78

نوع الثغرة

CWE-787 — Out-of-bounds Write

CVSS Vector

CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:U

المراجع

الوصف الكامل

rust-openssl provides OpenSSL bindings for the Rust programming language. From 0.10.39 to before 0.10.78, EVP_DigestFinal() always writes EVP_MD_CTX_size(ctx) to the out buffer. If out is smaller than that, MdCtxRef::digest_final() writes past its end, usually corrupting the stack. This is reachable from safe Rust. This vulnerability is fixed in 0.10.78.

الإصدارات المتأثرة

>= 0.10.39, < 0.10.78

نوع الثغرة

CWE-121 — Stack Overflow

CVSS Vector

CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:U

المراجع

الوصف الكامل

# Missing Admin Auth on Notification Target Endpoints in RustFS ### Finding Summary All four notification target admin API endpoints in `rustfs/src/admin/handlers/event.rs` use a `check_permissions` helper that validates authentication only (access key + session token), without performing any admin-action authorization via `validate_admin_request`. Every other admin handler in the codebase correctly calls `validate_admin_request` with a specific `AdminAction`. This is the only admin handler file that skips authorization. A non-admin user can overwrite a shared admin-defined notification target by name, causing subsequent bucket events to be delivered to an attacker-controlled endpoint. This enables cross-user event interception and audit evasion. ### What Was Proven Live 1. **Authorization bypass on all four endpoints** (03_readonly_user_bypass.py) - PUT, GET list, GET arns, DELETE all return 200 for readonly-user - Control routes (list-users, kms/status) correctly return 403 - Unauthenticated requests correctly rejected (403 Signature required) 2. **SSRF via health probe** (04_ssrf_listener_landing.py) - HEAD request from rustfs container to attacker-controlled listener - No host validation: only scheme check (http/https) 3. **Target hijacking and event exfiltration** (05_target_hijacking.py, 06_full_event_exfil.py) - Readonly-user overwrites admin-configured target URL by name - Subsequent S3 events delivered to attacker-controlled endpoint - Captured event body includes object keys, bucket names, user identities, and request metadata 4. **Audit evasion** (05_target_hijacking.py) - Readonly-user can delete unbound targets - Readonly-user can overwrite bound targets (silently redirecting events) ### Escalation Vectors Tested But Not Viable 1. **Self-referencing webhook to admin API** (13_self_referencing_test.py) - Webhook sends unsigned POST with event JSON body - Admin endpoints require SigV4 auth -- unsigned request rejected - "Confused deputy" via self-referencing does NOT work 2. **Protocol smuggling via non-HTTP targets** - Only 2 target types implemented: webhook and MQTT (`event.rs:613` enforces this) - No Redis, Kafka, AMQP, or other protocol targets exist - CRLF injection in webhook config fields sanitized by reqwest - MQTT uses rumqttc (pure Rust binary protocol client), no raw TCP injection 3. **MQTT target for RCE** - No unsafe code in MQTT handler - rumqttc 0.29.0 has no known public CVEs - No Command::new, template engines, or deserialization of broker responses 4. **Unauth access** - Endpoints correctly reject unauthenticated requests (403) - Endpoints correctly reject invalid credentials (403) ### Prior Art No existing advisory covers notification target endpoints. 11 published GHSAs on rustfs/rustfs cover different handlers. Closest: - CVE-2026-22042 (ImportIam wrong action constant) -- same bug class, different file - CVE-2026-22043 (deny_only short-circuit) -- different bug class ### Recommendation Submit via GitHub PVR. The finding is well-supported with live PoC, code references, and clear root cause. The fix is straightforward (add `validate_admin_request` calls to event.rs handlers). Core submission should reference 2-3 focused PoC scripts (readonly bypass, target hijack, event exfil), not the full set of 13 exploratory scripts. Koda Reef ### Patch This issue has been patched in version https://github.com/rustfs/rustfs/releases/tag/1.0.0-alpha.94.

الإصدارات المتأثرة

<= 0.0.2

نوع الثغرة

CWE-862 — Missing Authorization

CVSS Vector

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:L

المراجع

الوصف الكامل

### Impact `HistoryStore::put_historic_txns` uses an `assert!` to enforce invariants about `HistoricTransaction.block_number` (must be within the macro block being pushed and within the same epoch). During history sync, a peer can influence the `history: &[HistoricTransaction]` input passed into `Blockchain::push_history_sync`, and a malformed history list can violate these invariants and trigger a panic. `extend_history_sync` calls `this.history_store.add_to_history(..)` before comparing the computed history root against the macro block header (`block.history_root()`), so the panic can happen before later rejection checks run. ### Patches [The patch for this vulnerability](https://github.com/nimiq/core-rs-albatross/commit/6f5511309c199d84b012fe6b9aba7e5582892c50) is included as part of [v1.3.0](https://github.com/nimiq/core-rs-albatross/releases/tag/v1.3.0). ### Workarounds No known workarounds.

الإصدارات المتأثرة

<= 0.2.0

نوع الثغرة

CWE-20 — Input Validation

CVSS Vector

CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:N/I:N/A:H

المراجع

الوصف الكامل

### Impact The staking contract accepts `UpdateValidator` transactions that set `new_voting_key=Some(...)` while omitting `new_proof_of_knowledge`. this skips the proof-of-knowledge requirement that is needed to prevent BLS rogue-key attacks when public keys are aggregated. Because tendermint macro block justification verification aggregates validator voting keys and verifies a single aggregated BLS signature against that aggregate public key, a rogue-key voting key in the validator set can allow an attacker to forge a quorum-looking justification while only producing a single signature. While the impact is critical, the exploitability is low: The voting keys are fixed for the epoch, so the attacker would need to know the next epoch validator set (chosen through VRF), which is unlikely. ### Patches [The patch for this vulnerability](https://github.com/nimiq/core-rs-albatross/commit/e7f0ab7d2115e17d6e5548ddc60f10df1a5d645f) is included as part of [v1.3.0](https://github.com/nimiq/core-rs-albatross/releases/tag/v1.3.0). ### Workarounds No known workarounds.

الإصدارات المتأثرة

<= 0.2.0

نوع الثغرة

CWE-347 — CWE-347

CVSS Vector

CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:N/I:H/A:N

المراجع

الوصف الكامل

### Impact `HistoryTreeProof::verify` panics on a malformed proof where `history.len() != positions.len()` due to `assert_eq!(history.len(), positions.len())`. The proof object is derived from untrusted p2p responses (`ResponseTransactionsProof.proof`) and is therefore attacker-controlled at the network boundary until validated. A malicious peer could trigger a crash by returning a crafted inclusion proof with a length mismatch. ### Patches [The patch for this vulnerability](https://github.com/nimiq/core-rs-albatross/commit/6ff0800e8e031363e787c827d8d033e5694e4e6a) is included as part of [v1.3.0](https://github.com/nimiq/core-rs-albatross/releases/tag/v1.3.0). ### Workarounds No known workarounds know.

الإصدارات المتأثرة

<= 0.2.0

نوع الثغرة

CWE-617 — CWE-617

CVSS Vector

CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:N/I:N/A:L

المراجع

الوصف الكامل

### Impact An untrusted p2p peer can cause a node to panic by announcing an election macro block whose `validators` set contains an invalid compressed BLS voting key. Hashing an election macro header hashes `validators` and reaches `Validators::voting_keys()`, which calls `validator.voting_key.uncompress().unwrap()` and panics on invalid bytes. ### Patches [The patch for this vulnerability](https://github.com/nimiq/core-rs-albatross/commit/e10eaebcd7774e5da6d0ff5e88ed13503474f0ff) is included as part of [v1.3.0](https://github.com/nimiq/core-rs-albatross/releases/tag/v1.3.0). ### Workarounds No known workarounds.

الإصدارات المتأثرة

<= 0.2.0

نوع الثغرة

CWE-252 — CWE-252

CVSS Vector

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

المراجع

الوصف الكامل

### Impact `VestingContract::can_change_balance` returns `AccountError::InsufficientFunds` when `new_balance < min_cap`, but it constructs the error using `balance: self.balance - min_cap`. `Coin::sub` panics on underflow, so if an attacker can reach a state where `min_cap > balance`, the node crashes while trying to return an error. The `min_cap > balance` precondition is attacker-reachable because the vesting contract creation data (32-byte format) allows encoding `total_amount` without validating `total_amount <= transaction.value` (the real contract balance). After creating such a vesting contract, the attacker can broadcast an outgoing transaction to trigger the panic during mempool admission and block processing. ### Patches [The patch for this vulnerability](https://github.com/nimiq/core-rs-albatross/commit/4d01946f0b3d6c6e31786f91cdfb3eb902908da0) is included as part of [v1.3.0](https://github.com/nimiq/core-rs-albatross/releases/tag/v1.3.0). ### Workarounds No known workarounds.

الإصدارات المتأثرة

<= 0.2.0

نوع الثغرة

CWE-191 — CWE-191

CVSS Vector

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N

المراجع

الوصف الكامل

### Impact `SkipBlockProof::verify` computes its quorum check using `BitSet.len()`, then iterates `BitSet` indices and casts each `usize` index to `u16` (`slot as u16`) for slot lookup. If an attacker can get a `SkipBlockProof` verified where `MultiSignature.signers` contains out-of-range indices spaced by 65536, these indices inflate `len()` but collide onto the same in-range `u16` slot during aggregation. This makes it possible for a malicious validator with far fewer than `2f+1` real signer slots to pass skip block proof verification by multiplying a single BLS signature by the same factor. ### Patches [The patch for this vulnerability](https://github.com/nimiq/core-rs-albatross/pull/3657) is included as part of [v1.3.0](https://github.com/nimiq/core-rs-albatross/releases/tag/v1.3.0). ### Workarounds No known workarounds.

الإصدارات المتأثرة

<= 0.2.0

نوع الثغرة

CWE-190 — Integer Overflow

CVSS Vector

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:H

المراجع

الوصف الكامل

## Description Noir programs can invoke external functions through foreign calls. When compiling to Brillig bytecode, the SSA instructions are processed block-by-block in `BrilligBlock::compile_block()`. When the compiler encounters an `Instruction::Call` with a `Value::ForeignFunction` target, it invokes `codegen_call()` in `brillig_call/code_gen_call.rs`, which dispatches to `convert_ssa_foreign_call()`. Before emitting the foreign call opcode, the compiler must pre-allocate memory for any array results the call will return. This happens through `allocate_external_call_results()`, which iterates over the result types. For `Type::Array` results, it delegates to `allocate_foreign_call_result_array()` to recursively allocate memory on the heap for nested arrays. The `BrilligArray` struct is the internal representation of a Noir array in Brillig IR. Its `size` field represents the **semi-flattened size**, the total number of memory slots the array occupies, accounting for the fact that composite types like tuples consume multiple slots per element. This size is computed by `compute_array_length()` in `brillig_block_variables.rs`: ```rust pub(crate) fn compute_array_length(item_typ: &CompositeType, elem_count: usize) -> usize { item_typ.len() * elem_count } ``` For the **outer** array, `allocate_external_call_results()` correctly uses `define_variable()`, which internally calls `allocate_value_with_type()`. This function applies the formula above, producing the correct semi-flattened size. However, for **nested** arrays, `allocate_foreign_call_result_array()` contains a bug. When it encounters a nested `Type::Array(types, nested_size)`, it calls: ```rust Type::Array(_, nested_size) => { let inner_array = self.brillig_context.allocate_brillig_array(*nested_size as usize); // .... } ``` The pattern `Type::Array(_, nested_size)` discards the inner types with `_` and uses only `nested_size`, the **semantic length** of the nested array (the number of logical elements), not the semi-flattened size. For simple element types this works correctly, but for composite element types it under-allocates. Consider a nested array of type `[(u32, u32); 3]`: - Semantic length: 3 (three tuples) - Element size: 2 (each tuple has two fields) - Required semi-flattened size: 6 memory slots The current code passes `3` to `allocate_brillig_array()`, which then calls `codegen_initialize_array()`. This function allocates `array.size + ARRAY_META_COUNT` slots, only 4 slots instead of the required 7 (6 data + 1 metadata). When the VM executes the foreign call and writes 6 values plus metadata, it overwrites adjacent heap memory. ## Impact Foreign calls returning nested arrays of tuples or other composite types corrupt the Brillig VM heap. ## Recommendation Multiply the semantic length by the number of element types when allocating nested arrays. Extract the inner types from the pattern and replace the `nested_size` argument to `allocate_brillig_array()` with `types.len() * nested_size` to compute the semi-flattened size. Alternatively, reuse the existing `compute_array_length()` helper function to maintain consistency with outer array allocation.

الإصدارات المتأثرة

<= 1.0.0-beta.18

نوع الثغرة

CWE-131 — CWE-131

CVSS Vector

CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

المراجع

الوصف الكامل

# CVE-2026-40881: addr/addrv2 Deserialization Resource Exhaustion ## Summary When deserializing `addr` or `addrv2` messages, which contain vectors of addresses, Zebra would fully deserialize them up to a maximum length (over 233,000) that was derived from the 2 MiB message size limit. This is much larger than the actual limit of 1,000 messages from the specification. Zebra would eventually check that limit but, at that point, the memory for the larger vector was already allocated. An attacker could cause out-of-memory aborts in Zebra by sending multiple such messages over different connections. ## Severity **Moderate** - This is a Denial of Service Vulnerability that could allow an attacker to crash a Zebra node. ## Affected Versions All Zebra versions prior to **version 4.3.1**. ## Description The vulnerability exists in the `read_addr/addrv2` functions in `codec.rs`. It deserializes a vector of addresses with the `zcash_deserialize()` trait method, which uses as a upper bound the result of `T::max_allocation()`. For theses types, it was derived from dividing the max message size (2 MiB) by the minimum serialized size of one entry. For AddrV1: 2_097_152 / 30 = 69,904. For AddrV2: 2_097_152 / 9 = 233,016. Only after deserialization was the `MAX_ADDRS_IN_MESSAGE = 1000` limit checked. An attacker could exploit this by: 1. Creating `addr` or `addrv2` messages with a large number of entries. 2. Submitting them to a Zebra node, possibly through multiple connections, to attempt to get Zebra into an out-of-memory state. ## Impact **Denial of Service** * **Attack Vector:** Network. * **Effect:** Zebra node crash. * **Scope:** Any impacted Zebra node. ## Fixed Versions This issue is fixed in **Zebra 4.3.1**. The fix changes the `max_allocation()` method for the relevant types to return 1,000, thus blocking larger values prior to deserialization. ## Mitigation Users should upgrade to **Zebra 4.3.1** or later immediately. There are no known workarounds for this issue. Immediate upgrade is the only way to ensure the node remains not vulnerable to the denial of service attack. ## Credits Thanks @Zk-nd3r for finding and reporting the issue, and suggesting the fix.

الإصدارات المتأثرة

< 4.3.1, < 5.0.1

نوع الثغرة

CWE-770 — Resource Exhaustion

CVSS Vector

CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:L

المراجع

الوصف الكامل

# CVE-2026-40880: Cached Mempool Verification Bypasses Consensus Rules for Ahead-of-Tip Blocks ## Summary A logic error in Zebra's transaction verification cache could allow a malicious miner to induce a consensus split. By carefully submitting a transaction that is valid for height `H+1` but invalid for `H+2` and then mining that transaction in a block at height `H+2`, a miner could cause vulnerable Zebra nodes to accept an invalid block, leading to a consensus split from the rest of the Zcash network. ## Severity High - This is a Consensus Vulnerability that could allow a malicious miner to induce network partitioning, service disruption, and potential double-spend attacks against affected nodes. ## Affected Versions All Zebra versions prior to version 4.3.1. (Some older versions are not affected but are no longer supported by the network) ## Description The vulnerability exists due to a performance optimization whose goal is to improve performance of transaction validation if the transaction was previously accepted into the mempool (and thus was verified as valid). That however did not take into account that a transaction can be valid for a specific height, but invalid at higher heights; for example, it can contain an expiry height, a lock time, and it is always bound to a network upgrade, all of which are height-dependant. An attacker (specifically a malicious miner) could exploit this by (e.g. in the expiry height case): - Submitting a transaction with expiry height `H+1` (where `H` is the height of the current tip) - Mining a block `H+1`, and a block `H+2` that contains that same transaction, and submitting block `H+2` before `H+1` - Zebra nodes would accept `H+2` as valid (pending contextual verification) and wait for block `H+1`; when it arrives, Zebra would commit both blocks even if `H+2` contains an expired transaction - Other nodes (like `zcashd` or `zebrad` nodes without that transaction in their mempool) reject the block, resulting in a chain fork where the poisoned Zebra node is isolated. ## Impact **Consensus Failure** **Attack Vector**: Network (specifically via a malicious miner). **Effect**: Network partition/consensus split. **Scope**: Any Zebra node utilizing the transaction verification cache optimization for V5 transactions. ## Fixed Versions This issue is fixed in **Zebra 4.3.1**. We removed the performance optimization altogether, since we deemed it too risky. The fix ensures that verification is only skipped if the transaction's full integrity—including authorization data—is validated against the mempool entry. ## Mitigation Users should upgrade to Zebra 4.3.0 or later immediately. There are no known workarounds for this issue. Immediate upgrade is the only way to ensure the node remains on the correct consensus path and is protected against malicious chain forks. ## Credits Thanks to @sangsoo-osec for a thorough advisory submission that noticed the lock time issue, and to @shieldedonly with an also thorough advisory (that was submitted while we were working on the first one) who noticed that the issue applied to other aspects of the transaction validation.

الإصدارات المتأثرة

< 5.0.2, < 4.3.1

نوع الثغرة

CWE-1025 — CWE-1025

CVSS Vector

CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:N/VI:H/VA:H/SC:N/SI:H/SA:H

المراجع

الوصف الكامل

## Summary A soundness vulnerability in the SP1 V6 recursive shard verifier allows a malicious prover to construct a recursive proof from a shard proof that the native verifier would reject. - **Affected versions:** `>= 6.0.0, <= 6.0.2` - **Not affected:** SP1 V5 (all versions) - **Severity:** High ## Details ### Background The recursive shard verifier circuit verifies shard proofs inside a recursive proof. Each shard proof includes a jagged PCS opening, which binds trace-shape metadata into a modified commitment and uses that same shape to evaluate the committed polynomials. These two operations must agree on the committed table heights. ### The Bug In the V6 recursion circuit's jagged verifier, the two checks above are served by separate witnesses: a vector of row counts hashed into the modified commitment (commitment side), and a separate witness of prefix sums derived from row and column counts that drives the jagged polynomial evaluator (evaluation side). The prefix sums are observed within the shard verifier. The consistency check between these two witnesses was missing in the recursion sub-circuit describing the jagged PCS verifier. A malicious prover can therefore supply one trace shape for commitment binding and a different shape for polynomial evaluation. ### Potential Impact The vulnerability applies to both main trace and preprocessed trace metadata. Because preprocessed traces encode circuit structure (selectors, fixed columns, permutation layout), the potential impact extends beyond data forgery to misrepresentation of the circuit itself. While a demonstration of a full exploit proving arbitrary statements has not been created — since modifying one table's layout incidentally constrains changes to related tables — this barrier is not by design and should not be relied upon. This is considered a soundness violation that is unacceptable regardless of current exploitability. ### Why the Native Verifier Is Not Affected The native shard verifier uses a single jagged PCS verifier object where row counts and evaluation layout are derived from the same data, so the split-witness divergence cannot occur. The recursion circuit's shard-level checks (prefix-sum and total-area assertions) only constrain the evaluation-side parameters, not the commitment-side row counts, so they do not catch the gap. ## Mitigation The fix adds a post-evaluation consistency constraint in the recursive jagged verifier. After the jagged evaluation returns the prefix-sum values derived from the evaluation layout, the circuit reconstructs expected prefix sums from the commitment-side row counts (repeating each row count by its corresponding column count and accumulating). It then asserts element-wise equality between the reconstructed and returned prefix sums, and verifies that the final accumulated area matches the total area from the evaluation parameters. This forces both witnesses to describe the same trace geometry. Any divergence is now a constraint failure. ## Credit This vulnerability was identified through the SP1 bug bounty program on Code4rena.

الإصدارات المتأثرة

<= 6.0.2, <= 6.0.2, <= 6.0.2

نوع الثغرة

CWE-345 — CWE-345

CVSS Vector

CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:H/SA:N

المراجع

الوصف الكامل

### Impact An unauthenticated p2p peer can cause the `RequestMacroChain` message handler task to panic by sending a `RequestMacroChain` message where the first locator hash that is on the victim’s main chain is a micro block hash (not a macro block hash). In `RequestMacroChain::handle`, the handler selects the locator based only on "is on main chain", then calls `get_macro_blocks()` and panics via `.unwrap()` when the selected hash is not a macro block (`BlockchainError::BlockIsNotMacro`). ### Patches The patch for this vulnerability](https://github.com/nimiq/core-rs-albatross/pull/3660) is formally released as part of [v1.3.0](https://github.com/nimiq/core-rs-albatross/releases/tag/v1.3.0). ### Workarounds No known workarounds.

الإصدارات المتأثرة

<= 1.2.2

نوع الثغرة

CWE-617 — CWE-617

CVSS Vector

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L

المراجع

الوصف الكامل

nimiq-blockchain provides persistent block storage for Nimiq's Rust implementation. In 1.3.0 and earlier, block timestamp validation enforces that timestamp >= parent.timestamp for non-skip blocks and timestamp == parent.timestamp + MIN_PRODUCER_TIMEOUT for skip blocks, but there is no visible upper bound check against the wall clock. A malicious block-producing validator can set block timestamps arbitrarily far in the future. This directly affects reward calculations via Policy::supply_at() and batch_delay() in blockchain/src/reward.rs, inflating the monetary supply beyond the intended emission schedule.

الإصدارات المتأثرة

<= 1.3.0

نوع الثغرة

CWE-20 — Input Validation

CVSS Vector

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H

المراجع

الوصف الكامل

### Impact Wasmtime's implementation of transcoding strings between components contains a bug where the return value of a guest component's `realloc` is not validated before the host attempts to write through the pointer. This enables a guest to cause the host to write arbitrary transcoded string bytes to an arbitrary location up to 4GiB away from the base of linear memory. These writes on the host could hit unmapped memory or could corrupt host data structures depending on Wasmtime's configuration. Wasmtime by default reserves 4GiB of virtual memory for a guest's linear memory meaning that this bug will by default on hosts cause the host to hit unmapped memory and abort the process due to an unhandled fault. Wasmtime can be configured, however, to reserve less memory for a guest and to remove all guard pages, so some configurations of Wasmtime may lead to corruption of data outside of a guest's linear memory, such as host data structures or other guests's linear memories. ### Patches Wasmtime 24.0.7, 36.0.7, 42.0.2, and 43.0.1 have been issued to fix this bug. Users are recommended to update to these patched versions of Wasmtime. ### Workarounds There is no known workaround for this issue and affected hosts/embeddings are recommended to upgrade.

الإصدارات المتأثرة

< 24.0.7, >= 25.0.0, < 36.0.7, >= 37.0.0, < 42.0.2, = 43.0.0

نوع الثغرة

CWE-787 — Out-of-bounds Write

CVSS Vector

CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:L/VI:L/VA:H/SC:N/SI:N/SA:N

المراجع

الوصف الكامل

### Impact Wasmtime's implementation of its pooling allocator contains a bug where in certain configurations the contents of linear memory can be leaked from one instance to the next. The implementation of resetting the virtual memory permissions for linear memory used the wrong predicate to determine if resetting was necessary, where the compilation process used a different predicate. This divergence meant that the pooling allocator incorrectly deduced at runtime that resetting virtual memory permissions was not necessary while compile-time determine that virtual memory could be relied upon. Exposing this bug requires specific configuration values to be used. If any of these configurations are not applicable then this bug does not happen: * The pooling allocator must be in use. * The `Config::memory_guard_size` configuration option must be 0. * The `Config::memory_reservation` configuration must be less than 4GiB. * The pooling allocator must be configured with `max_memory_size` the same as the `memory_reservation` value. If all of these conditions are applicable then when a linear memory is reused the VM permissions of the previous iteration are not reset. This means that the compiled code, which is assuming out-of-bounds loads will segfault, will not actually segfault and can read the previous contents of linear memory if it was previously mapped. This represents a data leakage vulnerability between guest WebAssembly instances which breaks WebAssembly's semantics and additionally breaks the sandbox that Wasmtime provides. Wasmtime is not vulnerable to this issue with its default settings, nor with the default settings of the pooling allocator, but embeddings are still allowed to configure these values to cause this vulnerability. ### Patches Wasmtime 36.0.7, 42.0.2, and 43.0.1 have been issued to fix this bug. Users are recommended to update to these patched versions of Wasmtime. ### Workarounds All four conditions above must be met to be vulnerable to this bug, and users can work around this bug by adjusting any of the above conditions. For example it is strongly recommended that guard pages are configured for linear memories which would make this bug not applicable.

الإصدارات المتأثرة

>= 28.0.0, < 36.0.7, >= 37.0.0, < 42.0.2, = 43.0.0

نوع الثغرة

CWE-119 — Buffer Overflow

CVSS Vector

CVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:N/VC:L/VI:N/VA:N/SC:L/SI:N/SA:N

المراجع

الوصف الكامل

### Impact In version 43.0.0 of the `wasmtime` crate, cloning a `wasmtime::Linker` is unsound and can result in use-after-free bugs. This bug is not controllable by guest Wasm programs. It can only be triggered by a specific sequence of embedder API calls made by the host. The typical symptom of this use-after-free bug is a segfault. It does not enable heap corruption or data leakage. If you are using the `wasmtime` CLI, rather than the embedding API, you are not affected. If you are using the embedding API but are not calling `wasmtime::Linker`'s `Clone` implementation, you are not affected. Specifically, the following steps must occur to trigger the bug: * Clone a `wasmtime::Linker` * Drop the original linker instance * Use the new, cloned linker instance, resulting in a use-after-free ### Patches This bug has been patched in Wasmtime version 43.0.1 ### Workarounds Wasmtime embedders are highly encouraged to upgrade their `wasmtime` crate dependency. If upgrading is not an option, or as a temporary workaround before upgrading, you can avoid this bug by not cloning `wasmtime::Linker` and instead creating a new, empty `wasmtime::Linker` and manually reregistering the host APIs from the original linker: ```rust use wasmtime::{Linker, Result, Store}; fn clone_linker<T>(linker: &Linker<T>, store: &mut Store<T>) -> Result<Linker<T>> { let mut cloned = Linker::new(); for (module, name, item) in linker.iter(store) { cloned.define(module, name, item)?; } Ok(cloned) } ``` ### References This bug was introduced during an internal refactoring that was part of our efforts to [robustly handle allocation failure in Wasmtime](https://github.com/bytecodealliance/wasmtime/issues/12069). This refactoring introduced an string-interning pool which had an unsound `TryClone`[^try-clone] implementation. [^try-clone]: [The `TryClone` trait](https://github.com/bytecodealliance/wasmtime/blob/33e8b3d955697587b23cf39d87fbcbdb4d26b0c9/crates/core/src/alloc/try_clone.rs#L5-L17) is our version of the Rust standard library's `Clone` trait that allows for returning `OutOfMemory` errors. * The `StringPool` was introduced in https://github.com/bytecodealliance/wasmtime/pull/12536, at which time the bug in `TryClone for StringPool` was already present, although this code path was not yet used anywhere. * `wasmtime::Linker` was refactored to internally use `StringPool` in https://github.com/bytecodealliance/wasmtime/pull/12537, at which time the buggy code path became accessible. * This bug was originally reported to the Wasmtime maintainers as https://github.com/bytecodealliance/wasmtime/pull/12906

الإصدارات المتأثرة

= 43.0.0

نوع الثغرة

CWE-416 — Use After Free

CVSS Vector

CVSS:4.0/AV:P/AC:H/AT:P/PR:H/UI:A/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N

المراجع

الوصف الكامل

### Impact Wasmtime's Cranelift compilation backend contains a bug on aarch64 when performing a certain shape of heap accesses which means that the wrong address is accessed. When combined with explicit bounds checks a guest WebAssembly module this can create a situation where there are two diverging computations for the same address: one for the address to bounds-check and one for the address to load. This difference in address being operated on means that a guest module can pass a bounds check but then load a different address. Combined together this enables an arbitrary read/write primitive for guest WebAssembly when accesssing host memory. This is a sandbox escape as guests are able to read/write arbitrary host memory. This vulnerability has a few ingredients, all of which must be met, for this situation to occur and bypass the sandbox restrictions: * This miscompiled shape of load only occurs on 64-bit WebAssembly linear memories, or when `Config::wasm_memory64` is enabled. 32-bit WebAssembly is not affected. * Spectre mitigations or signals-based-traps must be disabled. When spectre mitigations are enabled then the offending shape of load is not generated. When signals-based-traps are disabled then spectre mitigations are also automatically disabled. The specific bug in Cranelift is a miscompile of a load of the shape `load(iadd(base, ishl(index, amt)))` where `amt` is a constant. The `amt` value is masked incorrectly to test if it's a certain value, and this incorrect mask means that Cranelift can pattern-match this lowering rule during instruction selection erroneously, diverging from WebAssembly's and Cranelift's semantics. This incorrect lowering would, for example, load an address much further away than intended as the correct address's computation would have wrapped around to a smaller value insetad. ### Patches Wasmtime 36.0.7, 42.0.2, and 43.0.1 have been issued to fix this bug. Users are recommended to update to these patched versions of Wasmtime. ### Workarounds This bug only affects users of Cranelift on aarch64. Cranelift on other platforms is not affected. Additionally this only affects 64-bit WebAssembly linear memories, so if `Config::wasm_memory64` is disabled then hosts are not affected. Note that `Config::wasm_memory64` is enabled by default. If spectre mitigations are enabled, which are enabled by default, then hosts are not affected by this issue.

الإصدارات المتأثرة

>= 32.0.0, < 36.0.7, >= 37.0.0, < 42.0.2, = 43.0.0

نوع الثغرة

CWE-125 — Out-of-bounds Read

CVSS Vector

CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H

المراجع

الوصف الكامل

### Impact Wasmtime's Winch compiler contains a vulnerability where the compilation of the `table.fill` instruction can result in a host panic. This means that a valid guest can be compiled with Winch, on any architecture, and cause the host to panic. This represents a denial-of-service vulnerability in Wasmtime due to guests being able to trigger a panic. The specific issue is that a historical refactoring, #11254, changed how compiled code referenced tables within the `table.*` instructions. This refactoring forgot to update the Winch code paths associated as well, meaning that Winch was using the wrong indexing scheme. Due to the feature support of Winch the only problem that can result is tables being mixed up or nonexistent tables being used, meaning that the guest is limited to panicking the host (using a nonexistent table), or executing spec-incorrect behavior and modifying the wrong table. ### Patches Wasmtime 36.0.7, 42.0.2, and 43.0.1 have been issued to fix this bug. Users are recommended to update to these patched versions of Wasmtime. ### Workarounds Users of Cranelift are not affected by this issue, but for users of Winch there is no workaround for this bug. Hosts are recommended to updated to a patched version of Wasmtime.

الإصدارات المتأثرة

>= 25.0.0, < 36.0.7, >= 37.0.0, < 42.0.2, = 43.0.0

نوع الثغرة

CWE-248 — CWE-248

CVSS Vector

CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:P/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N

المراجع

الوصف الكامل

### Impact Wasmtime's Winch compiler contains a bug where a 64-bit table, part of the memory64 proposal of WebAssembly, incorrectly translated the `table.size` instruction. This bug could lead to disclosing data on the host's stack to WebAssembly guests. The host's stack can possibly contain sensitive data related to other host-originating operations which is not intended to be disclosed to guests. This bug specifically arose from a mistake where the return value of `table.size` was statically typed as a 32-bit integer, as opposed to consulting the table's index type to see how large the returned register could be. When combined with details about Wnich's ABI, such as multi-value returns, this can be combined to read stack data from the host, within a guest. This information disclosure should not be possible in WebAssembly, violates spec semantics, and is a vulnerability in Wasmtime. ### Patches Wasmtime 36.0.7, 42.0.2, and 43.0.1 have been issued to fix this bug. Users are recommended to update to these patched versions of Wasmtime. ### Workarounds Users of Cranelift are not affected by this issue, but users of Winch have no workarounds other than disabling the `Config::wasm_memory64` proposal.

الإصدارات المتأثرة

>= 25.0.0, < 36.0.7, >= 37.0.0, < 42.0.2, = 43.0.0

نوع الثغرة

CWE-200 — Info Disclosure

CVSS Vector

CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:L/VI:N/VA:N/SC:L/SI:N/SA:N

المراجع

الوصف الكامل

On x86-64 platforms with SSE3 disabled Wasmtime's compilation of the `f64x2.splat` WebAssembly instruction with Cranelift may load 8 more bytes than is necessary. When [signals-based-traps](https://docs.rs/wasmtime/latest/wasmtime/struct.Config.html#method.signals_based_traps) are disabled this can result in a uncaught segfault due to loading from unmapped guard pages. With guard pages disabled it's possible for out-of-sandbox data to be loaded, but this data is not visible to WebAssembly guests. ### Details The `f64x2.splat` operator, when operating on a value loaded from a memory (for example with f64.load), compiles with Cranelift to code on x86-64 without SSE3 that loads 128 bits (16 bytes) rather than the expected 64 bits (8 bytes) from memory. When the address is in-bounds for a (correct) 8-byte load but not an (incorrect) 16-byte load, this can load beyond memory by up to 8 bytes. This can result in three different behaviors depending on Wasmtime's configuration: 1. If guard pages are disabled then this extra data will be loaded. The extra data is present in the upper bits of a register, but the upper bits are not visible to WebAssembly guests. Actually witnessing this data would require a different bug in Cranelift, of which none are known. Thus in this situation while it's something we're patching in Cranelift it's not a security issue. 2. If guard pages are enabled, and [signals-based-traps](https://docs.rs/wasmtime/latest/wasmtime/struct.Config.html#method.signals_based_traps) are enabled, then this operation will result in a safe WebAssembly trap. The trap is incorrect because the load is not out-of-bounds as defined by WebAssembly, but this mistakenly widened load will load bytes from an unmapped guard page, causing a segfault which is caught and handled as a Wasm trap. In this situation this is not a security issue, but we're patching Cranelift to fix the WebAssembly behavior. 3. If guard pages are enabled, and [signals-based-traps](https://docs.rs/wasmtime/latest/wasmtime/struct.Config.html#method.signals_based_traps) are disabled, then this operation results in an uncaught segfault. Like the previous case with guard pages enabled this will load from an unmapped guard page. Unlike before, however, signals-based-traps are disabled meaning that signal handlers aren't configured. The resulting segfault will, by default, terminate the process. This is a security issue from a DoS perspective, but does not represent an arbitrary read or write from WebAssembly, for example. Wasmtime's default configuration is case (2) in this case. That means that Wasmtime, by default, incorrectly executes this WebAssembly instruction but does not have insecure behavior. ### Impact If [signals-based-traps](https://docs.rs/wasmtime/latest/wasmtime/struct.Config.html#method.signals_based_traps) are disabled and guard pages are enabled then guests can trigger an uncaught segfault in the host, likely aborting the host process. This represents, for example, a DoS vector for WebAssembly guests. This bug does not affect Wasmtime's default configuration and requires [signals-based-traps](https://docs.rs/wasmtime/latest/wasmtime/struct.Config.html#method.signals_based_traps) to be disabled. This bug only affects the x86-64 target with the SSE3 feature disabled and the Cranelift backend (Wasmtime's default backend). ### Patches Wasmtime 24.0.7, 36.0.7, 42.0.2, and 43.0.1 have been issued to fix this bug. Users are recommended to update to these patched versions of Wasmtime. ### Workarounds This bug only affects x86-64 hosts where SSE3 is disabled. If SSE3 is enabled or if a non-x86-64 host is used then hosts are not affect. Otherwise there are no known workarounds to this issue.

الإصدارات المتأثرة

< 24.0.7, >= 25.0.0, < 36.0.7, >= 37.0.0, < 42.0.2, = 43.0.0

نوع الثغرة

CWE-248 — CWE-248

CVSS Vector

CVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:A/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N

المراجع

الوصف الكامل

### Impact Wasmtime contains a possible panic which can happen when a `flags`-typed component model value is lifted with the `Val` type. If bits are set outside of the set of flags the component model specifies that these bits should be ignored but Wasmtime will panic when this value is lifted. This panic only affects wasmtime's implementation of lifting into `Val`, not when using the `flags!` macro. This additionally only affects `flags`-typed values which are part of a WIT interface. This has the risk of being a guest-controlled panic within the host which Wasmtime considers a DoS vector. ### Patches Wasmtime 24.0.7, 36.0.7, 42.0.2, and 43.0.1 have been issued to fix this bug. Users are recommended to update to these patched versions of Wasmtime. ### Workarounds There is no workaround for this bug if a host meets the criteria to be affected. To be affected a host must be using `wasmtime::component::Val` and possibly work with a `flags` type in the component model.

الإصدارات المتأثرة

< 24.0.7, >= 25.0.0, < 36.0.7, >= 37.0.0, < 42.0.2, = 43.0.0

نوع الثغرة

CWE-248 — CWE-248

CVSS Vector

CVSS:4.0/AV:N/AC:H/AT:P/PR:H/UI:A/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N

المراجع

الوصف الكامل

### Impact Wasmtime's implementation of transcoding strings into the Component Model's `utf16` or `latin1+utf16` encodings improperly verified the alignment of reallocated strings. This meant that unaligned pointers could be passed to the host for transcoding which would trigger a host panic. This panic is possible to trigger from malicious guests which transfer very specific strings across components with specific addresses. Host panics are considered a DoS vector in Wasmtime as the panic conditions are controlled by the guest in this situation. ### Patches Wasmtime 24.0.7, 36.0.7, 42.0.2, and 43.0.1 have been issued to fix this bug. Users are recommended to update to these patched versions of Wasmtime. ### Workarounds There is no workaround for this bug. Hosts are recommended to updated to a patched version of Wasmtime.

الإصدارات المتأثرة

< 24.0.7, >= 25.0.0, < 36.0.7, >= 37.0.0, < 42.0.2, = 43.0.0

نوع الثغرة

CWE-119 — Buffer Overflow

CVSS Vector

CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:P/VC:N/VI:N/VA:H/SC:N/SI:N/SA:L

المراجع

الوصف الكامل

### Summary Wasmtime contains a vulnerability where when transcoding a UTF-16 string to the latin1+utf16 component-model encoding it would incorrectly validate the byte length of the input string when performing a bounds check. Specifically the number of code units were checked instead of the byte length, which is twice the size of the code units. This vulnerability can cause the host to read beyond the end of a WebAssembly's linear memory in an attempt to transcode nonexistent bytes. In Wasmtime's default configuration this will read unmapped memory on a guard page, terminating the process with a segfault. Wasmtime can be configured, however, without guard pages which would mean that host memory beyond the end of linear memory may be read and interpreted as UTF-16. A host segfault is a denial-of-service vulnerability in Wasmtime, and possibly being able to read beyond the end of linear memory is additionally a vulnerability. Note that reading beyond the end of linear memory requires nonstandard configuration of Wasmtime, specifically with guard pages disabled. ### Impact This is an out-of-bounds memory access. Any user running untrusted wasm components that use cross-component string passing (with UTF-16 source and latin1+utf16 destination encodings) is affected. - With guard pages: Denial of service. The host process crashes with SIGBUS/SIGSEGV. - Without guard pages: Potential information disclosure. The guest can read host memory beyond its linear memory allocation. Patches Wasmtime 24.0.7, 36.0.7, 42.0.2, and 43.0.1 have been issued to fix this bug. Users are recommended to update to these patched versions of Wasmtime. Workarounds There is no workaround for this bug. Hosts are recommended to updated to a patched version of Wasmtime.

الإصدارات المتأثرة

< 24.0.7, >= 25.0.0, < 36.0.7, >= 37.0.0, < 42.0.2, = 43.0.0

نوع الثغرة

CWE-125 — Out-of-bounds Read

CVSS Vector

CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:P/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N

المراجع

الوصف الكامل

### Summary The rendezvous server stores pagination cookies without bounds. An unauthenticated peer can repeatedly issue `DISCOVER` requests and force unbounded memory growth. ### Details Pagination state is stored in: ```rs HashMap<Cookie, HashSet<RegistrationId>> ``` On `Message::Discover`: ``` remote peer → DISCOVER → handle_request → registrations.get(...) → new cookie generated → cookie inserted into Registrations::cookies ``` There is **no upper bound or eviction policy**, so repeated DISCOVER requests grow this map indefinitely. ### PoC A reproduction test and minimal harness will be provided in a private fork in a follow-up comment. ### Impact **Remote state amplification leading to memory exhaustion.** Properties: - etwork reachable - no authentication required - low attack complexity - protocol-compliant traffic Impacts rendezvous nodes exposed to untrusted peers. --- ### Possible Fixes 1. **Global cap + eviction** Bound cookie storage (`MAX_COOKIES_TRACKED`) with FIFO/expiry aware eviction. Tradeoff: attacker can churn cookies and evict legitimate pagination state. 2. **Stateless cookies** Encode pagination state in authenticated cookies instead of storing server-side state. Tradeoff: more complex implementation. 3. **Rate limiting / per-peer quotas** Limit cookie creation per peer. Tradeoff: requires peer tracking.

الإصدارات المتأثرة

< 0.17.1

نوع الثغرة

CWE-770 — Resource Exhaustion

CVSS Vector

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:H

المراجع

الوصف الكامل

### Summary The`libp2p-rendezvous` server has no limit on how many namespaces a single peer can register. A malicious peer can repeatedly register unique namespaces in a loop, and the server accepts the requests, allocating memory for each registration without pushback. If an attacker continues submitting malicous requests for long enough, (or with multiple sybil peers) the server process crashes due to OOM. No auth is required; therefore, any peer on the network can do this. ### Details the bug is in `Registrations::add()` inside `protocols/rendezvous/src/server.rs`. the store uses a BiMap keyed on `(PeerId, Namespace)` so yes, a peer can't register the *same* namespace twice. but there's nothing stopping it from registering 10,000 *different* namespaces. each unique one gets its own entry in: - `registrations_for_peer` (BiMap) - `registrations` (HashMap) - `next_expiry` (FuturesUnordered a new heap-allocated BoxFuture per registration) namespace strings are only validated for length (`MAX_NAMESPACE = 255`), not count. there's no `max_registrations_per_peer` anywhere in `Config` or the rest of the codebase. making it worse `MAX_TTL = 72 hours`. so every registration just sits there for up to 3 days. disconnecting doesn't clean anything up either, entries only go away when the TTL fires. ``` protocols/rendezvous/src/server.rs └── Registrations::add() ← no per-peer count check anywhere protocols/rendezvous/src/lib.rs ├── MAX_NAMESPACE = 255 ← length capped, count is not └── MAX_TTL = 72h ← entries persist a long time ``` fix would be adding something like `max_registrations_per_peer` to `Config` and checking it at the top of `add()` before inserting anything. ### PoC tested on `libp2p v0.56.1`, built from source. **step 1** - start the rendezvous server (uses the example from the repo): ```bash cargo run --manifest-path examples/rendezvous/Cargo.toml --bin rendezvous-example ``` **step 2** - run the flood client (attached as `rzv-flood.rs`): ```bash cargo run --manifest-path examples/rendezvous/Cargo.toml --bin rzv-flood ``` it connects as a single peer and registers 10,000 unique namespaces (`flood-00000000` through `flood-00009999`), chaining each registration on the confirmed `Registered` event from the previous one. server accepted every single one. not one rejection. memory on the server side (via `ps aux` RSS column): ``` baseline: ~18 MB mid flood: ~26 MB after 10k regs: ~28 MB ``` that's from one peer. scale to 100 sybil peers doing the same thing and you're looking at ~1GB. 1000 peers and the server is dead. <img width="1032" height="124" alt="image" src="https://github.com/user-attachments/assets/f778f179-2aa1-4485-940c-25e218733fa8" /> *server RSS climbing during the flood* <img width="553" height="760" alt="image" src="https://github.com/user-attachments/assets/691b0f52-dda0-443f-a3c2-98c8c6336f2f" /> *10,000 registrations confirmed, zero rejected* ### Impact any node running libp2p-rendezvous server-side is affected. rendezvous servers are typically well-known, publicly reachable nodes taking one down disrupts peer discovery for all clients depending on it. any rust-libp2p based project that deploys a rendezvous point is at risk. no special position on the network needed. no crypto work. just open a connection and send REGISTER in a loop.

الإصدارات المتأثرة

< 0.17.1

نوع الثغرة

CWE-770 — Resource Exhaustion

CVSS Vector

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

المراجع