What it is
A request or peer supplies the value used to decide who it is or where its data comes from: a peer address for a cache transfer, an engine or instance identifier, a tenant field in an RPC. The receiver checks the shape of the value and treats it as authorization.
In a disaggregated system, components do need to say where things are. The design error is using one field for both routing and authorization.
Variants and records
Often cited, but not evidence for this
Remote-code advisories on cache-transfer services are often cited here. Their cause is that the service is reachable and unsafely decodes data, which belongs to INF02 and INF07. They do not show a service trusting a peer's claimed identity, so this category has no direct public record yet.
No direct public record.
One rule. Make peers prove what they are, and never let a request nominate its own data source.
Check your stack
Tests
Each test has a positive control: a condition under which it must fail. A test that cannot fail proves nothing. These are procedures. Hedgerow has not run them.
Borrowed namespace
- Do
- As tenant A, send a request naming tenant B's namespace or engine identifier.
- Pass
- The request is refused or ignored.
- Must fail when
- A stack that keys on the client-supplied value is included.
Rogue peer
- Do
- Register an unlisted peer with a plausible identifier.
- Pass
- Registration is refused.
- Must fail when
- The allowlist is replaced by dynamic self-registration.
Routing field as authorization
- Do
- Change only the routing field in a valid request.
- Pass
- Authorization outcome does not change.
- Must fail when
- A component known to use one field for both.
Mapping to AISVS, ATLAS and CWE
| Framework | Mapping |
|---|---|
| OWASP AISVS 1.01 | Nothing matches directly. Related but weaker: 5.1.2 (short-lived signed tokens for agents) and 5.2.1 (default-deny access control). A keyword search of 1.01 found no requirement on peer identity between serving components. |
| MITRE ATLAS 5.6.0 | No technique fits well. |
| CWE | CWE-290 Authentication Bypass by Spoofing and CWE-807 Reliance on Untrusted Inputs in a Security Decision (Hedgerow proposals). |
Controls
- Use cryptographic workload identity, so a peer proves what it is rather than naming it.
- Use declarative peer allowlists derived from cluster topology instead of dynamic self-registration.
- Never let a request nominate its own data source.
What this page does not claim
- The tests have not been run by Hedgerow.
- Standards mappings reflect the versions named and may change as they do.
- A cited record shows the mechanism occurred in at least one implementation. It does not say any given system is affected.