Why your SSRF report gets closed as informational

A blind server-side request forgery is one of the more satisfying things to find and one of the harder things to get paid for. The report arrives with a screenshot of a collaborator hit, the triager reads it, and it is closed as informational within the day. The pattern is consistent enough to be worth writing down, and the three reasons behind it are all fixable before you press submit.

A callback is not impact

An out-of-band callback proves exactly one thing: the server issued a request to a destination you chose. That is the vulnerability, and it is not the finding. The finding is what the server can reach that you cannot, and a report that stops at the callback is asking the triager to do that work on your behalf against a system they also have to keep running.

The fix is to answer the reachability question yourself, within scope, and write the answer down. Time the difference between a destination that is filtered, one that is closed, and one that is open. Compare error messages. Compare status codes. None of that requires touching an internal service; it requires reading the differences the application already hands you.

The DNS-only result is the most useful thing you will see

When the collaborator records a DNS lookup for your hostname and no HTTP connection follows, most people conclude the vulnerability is not exploitable and move on. It is the opposite. Something on the path resolved the name and then declined to connect, which means the request path exists and a control interrupted it somewhere specific. Finding out which hop declined tells you whether you are looking at an application allow-list, an egress proxy, or a network policy, and each of those has a different bypass surface and a different severity.

Write the severity in the triager language

Triage is a queue with a service level, and the person reading your report is deciding how far up it goes. The sentence that moves a report is a statement of the reachable set with the evidence attached, and the sentence that does not is a description of the technique. Compare these two, which describe the same finding:

• Weak: "The endpoint is vulnerable to blind SSRF. See the collaborator screenshot."
• Strong: "The rendering endpoint fetches an attacker-supplied URL from inside the network boundary. Timing differences confirm that at least one internal HTTP service on the same subnet is reachable and responds; two unreachable control addresses time out consistently at 5 seconds while the reachable one returns in 40 milliseconds. I did not interact further. Attached: the request, both timing sets, and the collaborator log."

The second version is not longer because it says more about the technique. It is longer because it names what was reached, states how that was established, and says explicitly where the tester stopped. That last part matters more than people expect: it is what tells a triager they can reproduce your work without discovering that you already went further than the programme allowed.

Knowing where to stop

The one thing that will lose a report faster than a weak impact statement is an impact demonstration that crosses a line. Retrieving a credential from an instance metadata endpoint proves impact conclusively and it also means you have retrieved a live credential belonging to someone else, which is a different conversation and occasionally a legal one. Programmes that want that demonstration say so in the scope. Programmes that do not want it will not thank you for the initiative.

The safe pattern is to demonstrate reachability rather than retrieval, state in the report exactly what you did not do, and offer to go further if the programme confirms in writing that it wants you to. That sentence costs you nothing and it has closed more severity disputes in my experience than any amount of extra evidence.

Practising this without a target

All of the above is easier to say than to do on a live programme where the cost of a mistake is your account. The blind SSRF lab reproduces the whole loop, including the DNS-only result and the timing comparison, against a sandboxed target with a simulated metadata service that reaches nothing real. That is the right place to build the habit.