A trust manipulation technique in which an attacker registers or wins ownership of an RPC endpoint before the legitimate service does. The result is that clients connect to the attacker-controlled endpoint and may authenticate to the wrong server.
What RPC endpoint poisoning is
RPC endpoint poisoning is a trust manipulation technique, not a transport flaw. The attacker gets a client to resolve or discover an RPC target that they control, so the client connects to the wrong server and may treat the attacker as a legitimate peer.
How the attack works
The core failure is endpoint ownership, because the client trusts the first or most convincing registration it sees. In practice, the attacker may pre-register a name, claim a service address, exploit weak discovery controls, or create a lookalike endpoint that wins the client’s lookup process.
Once the client connects, the attacker can intercept requests, return forged responses, capture authentication material, or relay traffic onward. The technique is especially dangerous when the RPC layer is used as a control plane for internal services, because a compromised endpoint can become a trusted entry point rather than just a noisy interception point.
That is why endpoint discovery, service registration, and trust validation need to be treated as part of the security boundary. In NIST Cybersecurity Framework 2.0 terms, this is a governance, protection, and detection problem at the boundary between known assets and trusted communications.
Security implications
RPC endpoint poisoning can turn a normal client-server exchange into an authentication failure, a data exposure event, or a command-routing problem. If the client assumes the endpoint is genuine, then certificates, tokens, session cookies, or other credentials can be sent to an attacker-controlled server, and the resulting compromise can be hard to distinguish from legitimate service behavior.
The impact is broader than credential theft. An attacker who controls the endpoint can influence configuration data, API-style requests, remote procedure calls, or operational actions that the client performs against the service. If the poisoned endpoint sits in a distributed system, the blast radius can include multiple services that inherit trust from the same discovery path.
For API-facing RPC patterns, the security concern aligns closely with the authorization and authentication failures described in the OWASP API Security Top 10, especially where clients trust a route or object identity that should have been verified more rigorously.
Defensive controls and validation patterns
Strong defenses combine authenticated service registration, verified name-to-endpoint binding, and cryptographic trust checks that are bound to the expected service identity rather than to a generic network location. The practical aim is to make it difficult for an attacker to win ownership of a service name, namespace, or discovery record without also defeating a separate trust control.
Least-privilege access to discovery systems, short-lived and audited registrations, and strict segmentation of control-plane components all reduce the chance that a poisoned endpoint becomes durable. When the service model depends on machine-to-machine trust, the underlying identity and authorization model should be explicit rather than assumed.
Where clients authenticate to RPC endpoints, the connection should fail closed if the endpoint identity does not match the expected trust anchor. That is often paired with hardening guidance from NIST Privacy Framework for limiting unnecessary disclosure, and with NIST AI Risk Management Framework only where the RPC path is part of an AI or agentic system that relies on remote tool or service calls.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.SC-01 — Cybersecurity Supply Chain Risk Management Strategy | RPC endpoint poisoning exploits trust in service discovery and remote endpoints. |
| PR.AA-05 — Identity and Access Credentials Are Protected | Clients may present credentials to a poisoned endpoint if trust is weak. | |
| Recommendation — Bind service discovery and endpoint trust to a formal supply-chain risk strategy. Require endpoint identity validation before any credential-bearing RPC session begins. | ||
| NIST SP 800-53 Rev 5 | IA-9 — Identification and Authentication of Organizations | The attack succeeds when a client cannot verify the remote service it reached. |
| Recommendation — Authenticate RPC peers so clients can verify the intended service endpoint. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | Clients may authenticate to the attacker-controlled endpoint instead of the real service. |
| API5 — Broken Function Level Authorization | A poisoned RPC endpoint can receive and act on privileged remote operations. | |
| Recommendation — Harden service discovery and endpoint verification to prevent authentication to the wrong server. Verify that every privileged RPC action is authorized against the intended service identity. | ||