Bypass Frontend ACLs and Reach Internal Endpoints via Request Smuggling

Bypass Frontend ACLs and Reach Internal Endpoints via Request Smuggling

Many architectures enforce path restrictions at the edge. The proxy blocks /admin, strips internal headers, and forwards ordinary traffic to an origin that assumes the proxy already made the authorization decision. Smuggle a second request past that check and the origin may see an internal path the edge never inspected.

This is not a generic “try X-Original-URL” trick. The bypass exists because the two hops disagree about request boundaries.

Find the split in responsibility

Request a likely restricted route directly. Useful evidence is a branded CDN 403, a proxy-specific server header, or a response arriving much faster than normal application pages. Compare it with a nonexistent route that reaches the app. Different error templates often reveal where the decision happened.

Then map harmless internal candidates from JavaScript, API documentation, source maps, or redirects:

• /admin/health
• /internal/version
• /api/admin/me
• /management/info
• A route exposed only to a support role

Prefer metadata over endpoints that mutate state. Reading a version string is enough to prove the edge was bypassed.

The smuggled route

Start from a confirmed CL.TE, TE.CL, or HTTP/2 downgrade desync. The visible outer request uses an allowed path such as POST /search. Bytes left in the backend connection begin a second request:

GET /internal/version HTTP/1.1
Host: target.example

Depending on the technique, your follow-up request may receive the internal response, or the smuggled response may be paired with another request on the same connection. Keep all traffic under your control. Use a unique header or query marker where the backend reflects one.

Direct 403 plus smuggled 200 is the clean comparison. Capture response headers and bodies from both. If the internal route itself has application authorization and still says 403, the frontend bypass exists but impact may be low. Do not call it admin takeover.

Header trust makes it sharper

Origins often trust headers inserted by the edge: X-User-Role, X-Forwarded-For, X-Original-URL, or a signed identity context. A smuggled request may preserve attacker-supplied copies that the proxy would normally strip from a top-level request.

Test one header at a time and stay conservative. X-Forwarded-For: 127.0.0.1 reaching a health endpoint is a useful signal; invoking a dangerous admin job is not. If a signature is required, do not pretend an unsigned header bypassed it.

Avoid the connection-pool lottery

Response queue behavior can send the internal response to another client. Repeat only with techniques that keep the poisoned and follow-up requests tied to your own connection, or ask for a staging host. Pause-based and client-side desync variants need the same care.

A bounty-ready report shows the architecture as evidence, not guesswork:

1. Direct request blocked by the front end.
2. Normal allowed request accepted.
3. Smuggled internal request reaches the origin.
4. Low-risk internal data returns to your client.
5. Exact framing and protocol needed for reproduction.

Recommend enforcing authorization at the origin on every route, stripping trusted headers at the last hop, rejecting ambiguous framing, and blocking the origin from direct exposure. Frontend ACLs can reduce attack surface, but they should never be the only lock on an admin API.

PortSwigger's lab on bypassing front-end security controls demonstrates the core chain. Adapt the proof to the target's policy and stop before any state-changing internal action.