POST Replay / Cache Turning into Internal GET SSRF

Replay systems and scheduled fetchers are hidden SSRF surfaces. A harmless external POST can later become a privileged internal GET when replayed by another component.

Why It Matters

• The replay worker may run with different trust assumptions than the submit path, and may transform method/URL/body.

Vulnerable Pattern

• Meeting schedulers, webhook replayers, or audit systems that store request specs and re-execute them later.

Exploit Flow

1. Figure out what exact request state is stored and how it is replayed.
2. See whether method, URL, or body are transformed during replay (especially POST → GET).
3. Target internal admin routes or metadata endpoints with the replayed request.

Common Blockers

• Strict allowlists at replay time, or replay workers that drop unsafe hosts even if the submit path did not.

PoC Sketch

# submit a POST recording http://127.0.0.1/admin as a replay target
# trigger the replay endpoint and inspect whether the backend follows it as an internal GET

Good Situations To Use It

• The app stores and later re-executes requests.
• The replay path trusts more than the submit path.
• Internal-only routes exist worth reaching.

Sources

• hackday2026/web/lets_meet