JSON-RPC ID Collisions

How JSON-RPC ID Collisions Affect Request Correlation

JSON-RPC depends on request identifiers to pair each response with the correct call. When identifiers collide, a client, broker, or agent tool layer can match a result to the wrong request, which is especially dangerous when several calls are in flight at once.

The problem is not limited to a simple parsing bug. In asynchronous systems, request IDs are part of the trust boundary for correlation, so a collision can blur which action was actually approved, which response belongs to which caller, and which state transition should follow.

Why ID Collisions Create Security and Reliability Failure Modes

A collision can cause stale data, wrong-side effects, or state corruption if a response is processed as though it came from a different invocation. In an API or agent environment, that can turn an ordinary race condition into a control failure because the wrong tool output may be trusted as the intended one.

Where responses drive authorization decisions, workflow steps, or downstream automation, a collision can also create confused deputy behaviour. A component may inadvertently apply one caller’s response to another caller’s context, which increases the chance of privilege misuse or unintended action.

• Blockchain and Distributed Ledger Security Guide is useful here because it covers node and RPC hardening, which is relevant when JSON-RPC is part of the exposed control plane.

Where JSON-RPC ID Collisions Usually Come From

Collisions are most likely when identifiers are generated from a weak counter, a short namespace, a reused session context, or a shared client library that was never designed for concurrent use. They also appear when multiple components generate IDs independently without coordination.

The risk rises when IDs are predictable or reused across retries, reconnects, worker pools, or multiplexed sessions. Even if the transport is reliable, the application layer can still mis-associate messages when it treats ID uniqueness as optional instead of mandatory.

In agent tool layers, the same failure mode can show up when one orchestrator manages many parallel calls and assumes the response order will preserve intent. JSON-RPC does not guarantee that, so the identifier itself must remain unique within the relevant correlation scope.

How to Prevent and Detect Collision-Driven Corruption

Prevention starts with making request IDs unambiguous within the full concurrency scope of the client or orchestrator. Use an ID generation strategy that is resistant to reuse across parallel requests, retries, and process restarts, and validate that correlation state cannot be overwritten by a late response.

Detection should focus on mismatched request-response pairs, duplicate IDs observed in logs, and responses that arrive after their originating context has expired. If a collision is suspected, review whether the system ever allowed one identifier to map to more than one outstanding request, because that is the condition that enables confusion.

For exposed JSON-RPC endpoints, hardening should also include strict input validation, correlation logging, and careful handling of out-of-order replies so that the application can fail closed rather than silently continue with the wrong result.

Risk and Threat Considerations

JSON-RPC ID collisions matter because they can create a low-friction path to misbinding, where a legitimate response is attached to the wrong request and the wrong action follows. In an API or agent tool chain, that can corrupt state, hide the true source of a result, or let an attacker exploit timing and concurrency to influence which request appears to have succeeded.

Failure mechanism: A collision or reused identifier causes the response handler to select the wrong pending request, so application logic consumes valid data in the wrong context.

Impact: The result can be incorrect state transitions, unintended tool execution, authorization confusion, or loss of trust in the integrity of the API workflow.

Practitioner Guidance

Why practitioners should care: Treat request IDs as security-relevant correlation material, not just plumbing. If multiple concurrent calls can share a namespace, the system needs a design that prevents reuse across in-flight operations and across lifecycle events such as retries or reconnects.

What to watch for: Repeated IDs, late-arriving responses, retry loops that reuse the same identifier, and any code path that assumes response order is enough to preserve request identity. These are the conditions that usually expose the bug before it becomes a visible incident.

Practitioner takeaway: If the platform cannot prove one-to-one request correlation under concurrency, it cannot reliably trust the response.

Related resources from NHI Mgmt Group

• How should security teams implement method-level authorization in JSON-RPC APIs?
• Why do JSON-RPC APIs complicate traditional WAF and rate-limiting controls?
• What breaks when JSON-RPC input is not schema validated and parameterized?
• How do organisations reduce method enumeration and information leakage in JSON-RPC error handling?