Track vulnerabilities like this one.
Sign up free to get alerted when software you use is affected.
7.5
WordPress: Unverified Relay Events Can Cause Data Tampering
published 3 months ago
Summary
A security issue in WordPress allows an attacker to send fake events that can be treated as real by the system. This could potentially lead to data tampering. The issue has been fixed, and WordPress now verifies events before processing them.
What to do
- Update yukibtc nostr-relay-pool to version 0.44.3.
Affected software
| Ecosystem | Vendor | Product | Affected versions |
|---|---|---|---|
| crates.io | yukibtc | nostr-relay-pool |
>= 0.0.0-0, < 0.44.3 Fix: upgrade to 0.44.3
|
Original advisory text
Processing of unverified relay events
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.
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.
Internet-facing
14 days
Internal
60 days
- Not known to be exploited
- Can be exploited automatically (estimated)
- Gives an attacker partial control (estimated)
Timeline
Published1 Aug 2026
Updated2 Aug 2026
First seen2 Aug 2026
Sources
RUSTSEC-2026-0232 · OSV
Track software like this
Free during beta