RUSTSEC-2026-0232

The processed events received from a relay through admission-policy and database paths before verifying that the serialized fields matched the claimed event ID and signature. In particular, a database result for the claimed ID could cause verification to be skipped. The verification cache also keyed successful checks by a 64-bit hash instead of the complete event ID.

A malicious relay could send an event whose claimed ID referred to a known database entry while its content, tags, author, or signature differed from that ID. The forged event could then reach policy callbacks or other SDK processing as if it were authentic. A cache-key collision provided a second path for an unverified event to be treated as previously verified. This undermines event integrity but does not reveal private keys or enable the attacker to produce a valid signature for the altered event.

The SDK now verifies each event before policy evaluation, database lookup, or propagation decisions, and the verification cache stores the complete `EventId` so a truncated hash collision cannot stand in for successful verification.