fix: require X-P2P-Key auth on /p2p/gossip POST endpoint (fixes #8177) [fj4WqyCCw3C5ShR1RfB7MoBPTpkRrBFYP1uT35g3MvT]

[waterWang]

Fix #8177: /p2p/gossip POST endpoint has no authentication

Problem

All P2P GET endpoints (/p2p/state, /p2p/attestation_state, /p2p/peers) require X-P2P-Key via _require_p2p_read_auth(). However, the /p2p/gossip POST endpoint — which is the write endpoint that feeds CRDT updates — has no authentication. Only per-IP rate limiting is applied.

Impact: Any network-accessible attacker can POST gossip messages to the node without knowing the P2P secret, injecting forged CRDT updates.

Fix

Add the same _require_p2p_read_auth() check that all other P2P endpoints use, placed after the rate limit check but before any content-length validation or payload processing.

Changes

• Added 4 lines to receive_gossip() in node/rustchain_p2p_gossip.py

Testing

• ✅ Python syntax check passed
• ✅ Python compile check passed
• The auth check is identical to the pattern used by get_state(), get_attestation_state(), and get_peers()

[FlintLeng]

PR Review: P2P Gossip POST Requires X-P2P-Key Authentication

Reviewed on: 2026-08-07

Summary

Fixes P2P write-path authentication gap: the /p2p/gossip POST endpoint (which feeds CRDT updates into the mempool) had no X-P2P-Key check, only per-IP rate limiting. All other P2P endpoints (GET /p2p/state, /p2p/attestation_state, /p2p/peers) already required authentication. This was a write-path authentication bypass.

Security Analysis ✅

The vulnerability is correctly scoped. A forged CRDT gossip message that reaches apply_gossip() could inject invalid state entries into the mempool. The PR body correctly identifies the impact: unauthenticated write access to the distributed state — the most dangerous class of P2P vulnerability.

Fix is minimal and correct:

auth_error = _require_p2p_read_auth()
if auth_error:
    return auth_error

Reuse of the existing _require_p2p_read_auth() is the right call — same auth logic for the same secret, consistent across all P2P endpoints.

Note: The PR body references _require_p2p_read_auth() but the endpoint is the write path (POST). Worth verifying that the auth function checks the same X-P2P-Key header as the GET endpoints — the naming suggests it, but confirming prevents a read/write auth gap.

Additional Change: Duplicate #8181 Fix

utxo_db.py also includes the BEGIN IMMEDIATE + rollback fix for mempool_clear_expired() — this is the same fix as PR #8181, which I reviewed on 2026-08-04. The fix is correct and already validated. Merging #8190 will effectively close #8181's fix scope as well.

Minor Note

The PR title references "15 deletions" — that includes the utxo_db.py refactor (flattening the else: block). The deletions are all from the refactor, not from the security fix. No code is removed for security reasons.

Wallet: RTC019e78d600fb3131c29d7ba80aba8fe644be426e

✅ LGTM — clean, targeted auth fix for the P2P write path.

[Scottcjn]

Holding this one, and I want to be precise about why, because the finding behind it is correct.

You are right that /p2p/gossip POST is the odd one out. _require_p2p_read_auth() already exists at line 1811 and guards the sensitive read-only sync endpoints, and the sender at line 1538 already sends X-P2P-Key. The gossip receive path having no auth is a genuine gap.

The problem is the other sender. broadcast() at line 884 is the live fan-out path, and it goes through _send_to_peer() at line 894:

def _send_to_peer(self, peer_url: str, msg: GossipMessage):
    resp = requests.post(
        f"{peer_url}/p2p/gossip",
        json=msg.to_dict(),
        timeout=10,
        verify=TLS_VERIFY
    )

No X-P2P-Key header. This diff adds the header to zero senders (git diff origin/main...HEAD | grep -c X-P2P-Key returns 0), so as soon as the receiving side requires the key, every gossip message from broadcast() gets a 401 and inter-node gossip stops. That is a fleet-wide outage rather than a hardening.

CI does not catch it: this needs two nodes talking to each other, and nothing in the suite exercises that. The branch is green and mergeable, which is exactly why I checked the call path by hand.

What would make this mergeable:

1. Add the header in _send_to_peer(), matching line 1538:

   headers={"X-P2P-Key": P2P_SECRET},

2. Consider the rollout order explicitly. If receivers start requiring the key before every peer is running a sender that sends it, older peers get cut off mid-upgrade. Enforcing on receive only when P2P_SECRET is configured, or logging-and-allowing for one release before enforcing, avoids a hard cutover. Your call which, but the PR should say which it assumes.
3. A test that a gossip POST without the header is rejected and one with it is accepted, since there is no coverage of this path at all right now.

Worth flagging separately: this branch is also stacked under #8191 and #8192, so each of those carries this change plus its own. If this one needs a revision, they inherit it. Splitting them onto independent branches off current main would make all three reviewable on their own merits.

The gap you found is real and worth fixing. It just needs the sender side to land in the same change.

[Scottcjn]

Follow-up: the sender half is now on main.

#8203 adds X-P2P-Key to _send_to_peer(), so both gossip senders present the key. It is inert on its own, because /p2p/gossip still does not require it, and it ships an AST-based test asserting every requests.post to that endpoint passes the header, so a future sender added without it fails in CI instead of in production.

That removes the outage risk from your change. Rebase onto current main and this becomes mergeable on its own merits.

One thing still worth deciding in your PR: the rollout order. Even with every sender fixed, a receiver that starts enforcing before all peers are running the new build will cut off the stragglers. Gating enforcement on an env flag, defaulting permissive, makes the cutover an operator decision and reversible without a redeploy. RC_TESTNET_ALLOW_MOCK_SIG is the established pattern in this codebase.

Thanks for finding the gap.