Skip to content

audit F15 [security]: replay on_event allocates ServerData keyed on attacker-chosen server_id #582

@intendednull

Description

@intendednull

File: crates/replay/src/role.rs:243-271, crates/replay/src/role.rs:91-130
Severity: security
Obvious? no

on_event derives server_id from incoming events. For a CreateServer kind it stringifies the event hash; otherwise it falls back to "default" or matches against existing servers. ingest_event then unconditionally does self.servers.entry(server_id.to_string()).or_insert_with(...). The DAG's EventDag::insert validates signatures, but ingest_event doesn't gate by signature: any peer can sign a CreateServer event with arbitrary content and trigger creation of a new ServerData slot (each carries an EventDag, ServerState, PendingBuffer). MAX_SERVERS=1000 provides a final cap with LRU eviction, but eviction is invoked inside the same call that populates the slot (line 98-100), so the cap is honored — however, churning this LRU lets an attacker repeatedly evict legitimate servers' state by signing a stream of distinct CreateServer events. Combined with rebuild cost via re-sync, this is a state-corruption + memory-pressure vector.

Fix: gate CreateServer ingestion via a signer/permissions allowlist, and/or rate-limit per-signer server creation.


Filed by /general-audit @ 6404719 (2026-05-03). master: #567.

Metadata

Metadata

Assignees

No one assigned

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions