Hello readers, Sometimes the most interesting vulnerabilities are not hiding in login forms, password reset flows, or API endpoints — they hide in the background. This story started with a feature that most testers completely ignore: an error logging endpoint. While testing target.com, I noticed a request being sent to an endpoint called:
POST /tunnel/At first glance, it looked harmless. Just telemetry. Just logging. Just Sentry doing its thing. But security testing has taught me one important rule: If the server makes a request based on something I control — I look closer. And that's exactly what happened here.
Before We Dive In — What Is SSRF?
Server-Side Request Forgery (SSRF) happens when an application allows user-controlled input to influence a server-side HTTP request.
In simple terms:
Instead of sending requests directly to a system, I trick the server into sending them on my behalf.
Why does that matter?
Because servers can access internal services, reach private infrastructure, are trusted within the network, and sometimes can access cloud metadata endpoints.
SSRF turns the backend into an HTTP client controlled by the attacker.
And when that happens, things get interesting.
Where SSRF Usually Hides
In my experience, SSRF often appears in:
- Webhook integrations
- File import features
- URL preview generators
- PDF converters
- API proxies
- Image fetchers
- Analytics relays
- Telemetry forwarding endpoints
Notice something?
Most of these are not "core" features. They're integrations.
That's important.
The Small Detail That Changed Everything
During testing, one request caught my attention. While analyzing requests in an authenticated session, I intercepted:
POST /tunnel/Inside the request body, I saw something that made me pause.
A DSN parameter.
For those unfamiliar, a DSN (Data Source Name) tells Sentry where to send telemetry data. It usually contains a host.
And here's the part that mattered:
- The DSN was coming from the client.
- It wasn't hardcoded server-side.
- That means I could modify it.
So I did.
The Test
To confirm exploitation:
- The DSN host was replaced with an attacker-controlled domain.
- The modified request was sent to
/tunnel/. - A server-side HTTP POST request was observed on Burp Collaborator.
- The source IP corresponded to the target's backend infrastructure.
This confirmed that the application was accepting user-controlled input and using it to perform arbitrary outbound HTTP requests — a clear Server-Side Request Forgery vulnerability.
What Actually Happened
The backend processed the attacker-controlled DSN value, extracted the host component, and used it to initiate a server-side HTTP POST request. At no point was the destination validated or restricted through an allowlist. As a result, the application effectively behaved as an arbitrary outbound HTTP client. While my proof of concept demonstrated interaction with an external domain, the underlying issue is broader — if external hosts are permitted without validation, the same logic could potentially be applied to internal or sensitive network resources.
Why This Is Dangerous
When an application performs outbound HTTP requests without validation, it opens the door to:
- Arbitrary outbound HTTP interactions
- Infrastructure abuse
- Telemetry data exfiltration
- Potential access to internal services
- Trust boundary violations
Even if internal network access is restricted, the mere ability to control outbound requests is a serious issue, because the attacker now dictates where the server communicates.
The Root Cause
The root cause of this issue was the application's reliance on client-supplied configuration. The DSN value was accepted without proper validation and used directly to determine the destination of server-side requests. This represents a clear trust boundary violation, as user-controlled input was allowed to influence backend routing logic. Telemetry endpoints are intended to forward data to predefined, trusted services — not function as unrestricted HTTP relays
How It Was Fixed
The proper mitigation was straightforward:
- Enforce a strict allowlist (only trusted Sentry domains)
- Reject arbitrary DSN values
- Ensure the tunnel endpoint cannot act as a proxy
- Monitor unexpected outbound destinations
After applying validation, attacker-controlled domains were no longer reachable.
Why This Finding Stood Out
What makes this case stand out is less the SSRF itself than its context. The vulnerable endpoint was not part of a standard data-processing workflow or a typical API integration; it was a telemetry tunnel used for logging and error reporting. This demonstrates that critical security issues can exist in overlooked components, highlighting the importance of reviewing all paths where user-controlled input might influence backend operations.
Conclusion
This case reinforced something I've learned repeatedly in bug bounty: Never ignore "boring" endpoints. Logging systems, analytics, monitoring integrations, and third-party relays often sit outside the main business logic — and that's exactly why they are overlooked. SSRF may seem simple, but context matters. A single misconfiguration can turn a helper endpoint into a powerful attack primitive. I hope you enjoyed this walkthrough and found it insightful. If you like reading real-world vulnerability discoveries explained step by step, follow me for more security research and breakdowns. More findings are coming soon — stay safe, and keep testing.
