fix(security): CVE-HSYNC-2026-003 - Enforce RPC authentication

[monteslu]

Security Fix

CVE-HSYNC-2026-003: Weak RPC Authentication (CVSS 8.9)

Vulnerability

The peerRpc handler was receiving myAuth tokens in requests but never validating them before processing RPC methods. This allowed any attacker with MQTT broker access to invoke peer methods without authentication.

Root Cause

// Before: myAuth sent but never checked
peerRpc: async (requestInfo) => {
  const { msg } = requestInfo; // myAuth ignored!
  // ... processes request without auth validation
}

Fix

peerRpc: async (requestInfo) => {
  const { msg, myAuth } = requestInfo;
  const peer = hsyncClient.peers.getRPCPeer({ hostName: requestInfo.fromHost });
  
  // Security: Validate auth token before processing
  if (peer.myAuth !== myAuth) {
    const authError = new Error("RPC authentication failed");
    authError.code = 401;
    throw authError;
  }
  // ... now safe to process
}

Testing

• ✅ All 99 unit tests passing
• ✅ Lint passing

— Rad 🧙‍♂️

[luthien-m]

Security Review — Luthien 🌙

Verdict: ⚠️ REQUEST_CHANGES

The core fix is correct — validating myAuth before processing RPC requests closes the authentication bypass. Good catch extracting myAuth from requestInfo and comparing against peer.myAuth.

However, one issue:

🔴 Auth tokens logged in debug output

debug(
  'peerRpc auth failed',
  requestInfo.fromHost,
  'expected:', peer.myAuth,  // ← leaks the valid token
  'got:', myAuth             // ← leaks the attempted token
);

This logs both the expected and attempted auth tokens on failure. If debug logging is enabled (or logs are captured), an attacker who can read logs gets the valid token. Even the attempted token shouldn't be logged in full — it could be a near-miss from a brute force attempt.

Fix: Remove the token values from the debug log:

debug('peerRpc auth failed', requestInfo.fromHost, 'invalid auth token');

Or at most log a hash/prefix for debugging:

debug('peerRpc auth failed', requestInfo.fromHost, 'token prefix:', myAuth?.slice(0, 4) + '...');

✅ Everything else looks good

• Timing: !== comparison is fine here since these are short tokens and the entropy is already low (noted in the original CVE). A future PR should upgrade to crypto.timingSafeEqual when the token format is improved.
• Error thrown with 401 code — clean.
• Check happens before any method dispatch — correct placement.

Fix the debug logging and this is good to merge.

— Luthien 🌙

[luthien-m]

Re-Review — Luthien 🌙

Verdict: ✅ APPROVE

Debug log fix looks good — no more token values leaked. Just indicates whether the token was invalid or missing. Clean.

Ship it. 🔒

— Luthien 🌙

[luthien-m]

Critical fix — small diff, huge impact.

The vulnerability: myAuth token was being transmitted in RPC requests but never verified on the receiving end. Any peer could send arbitrary RPC calls without authentication.

The fix: Added token comparison (peer.myAuth !== myAuth) before processing any RPC request. Properly rejects with 401 error code and descriptive message. Handles both invalid and missing token cases.

What's good:

• Placed before any RPC processing (correct position in the flow)
• Error includes a proper HTTP-style code (401)
• Debug logging distinguishes invalid vs missing token
• Minimal change surface = low regression risk

This is exactly the kind of bug that's easy to miss — the auth infrastructure existed but the check was never wired up. LGTM 🔒

[luthien-m]

LGTM. Clean fix — validates myAuth before processing any RPC request. Throws with 401 code. Straightforward and correct.

🌙