What it is
Gateways and routers accept headers or fields that choose a target pod, rewrite a model name, hint a backend or set a cache routing key. If these are not stripped at the boundary, a caller steers internal traffic.
Say which of two things you have. If the header only selects among legitimate backends, it is internal routing manipulation. It is server-side request forgery only when it makes the service open a connection to an attacker-chosen destination, typically the outbound artifact or media fetch path.
Variants and records
Outbound fetch
The service fetches a URL to load a model or config. If the destination is not checked, a third party can make it download from, and write to, places it should not reach.
TorchServe 0.1.0 to 0.8.1, CVE-2023-43654, published 2023-09-28. Its default configuration accepted model downloads from any URL. Release 0.8.2 adds a warning when the default allowlist is used.
Documented trust model
Some projects write down which protections they assume you already have, and which you must add yourself.
vLLM's security documentation covers trusted-network assumptions, media URL allowlisting and redirect handling.
One rule. Strip by default at ingress with an allowlist, and validate outbound fetch targets after redirects resolve.
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.
Internal headers from outside
- Do
- Send each internal routing header from an external client.
- Pass
- Routing is unchanged and the header is dropped.
- Must fail when
- The sanitizer is removed.
Redirect to internal
- Do
- Point a fetch at a public URL that redirects to an internal address.
- Pass
- The fetch is refused after resolution.
- Must fail when
- A validator that checks only the first URL.
Header allowlist drift
- Do
- Diff the ingress allowlist against headers read by components in CI.
- Pass
- No unlisted header is read.
- Must fail when
- A new component reading a header is added.
Mapping to AISVS, ATLAS and CWE
| Framework | Mapping |
|---|---|
| OWASP AISVS 1.01 | No requirement found for trust of routing headers or outbound fetch destinations, by keyword search of 1.01. Chapter 2 (input validation) covers prompt content, not routing metadata. |
| MITRE ATLAS 5.6.0 | No technique fits well. |
| CWE | CWE-918 Server-Side Request Forgery for the outbound case, and CWE-807 Reliance on Untrusted Inputs in a Security Decision for routing headers (Hedgerow proposals). |
Controls
- Strip by default at ingress with an explicit allowlist.
- Reconcile the allowlist in CI against every header a component reads.
- Validate outbound fetch targets after redirect resolution, not before.
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.