The first scan found an SSRF. The second one didn't.
I wouldn't close the finding just yet.
The endpoint accepts a URL, fetches the resource, and returns its response. During the first scan, the agent managed to follow a redirect and reach an internal service. It reported the issue with a successful response as evidence.
Then it ran the test again. Same endpoint, same application. No SSRF.
One thing I'd check before looking at the model's reasoning is the actual network traffic.
Suppose the agent tests a hostname that resolves to a public IP. The application checks the address and allows the request. But there's a gap between that check and the connection itself. If another DNS resolution returns a private IP, the application could end up connecting somewhere the original validation was supposed to block.
That's the DNS rebinding problem.
The details depend on the HTTP client, DNS caching, connection reuse, and whether a proxy is involved. A second lookup isn't guaranteed. But if the component making the connection doesn't enforce the destination restrictions, checking the hostname at the beginning isn't enough.
Redirects make this more interesting. The first URL can point to a public host and return a redirect to another hostname. If the application validates only the original destination, the next request may escape the intended boundary. OWASP recommends disabling automatic redirect following in the HTTP client to avoid this validation bypass. If redirects are required, each destination needs to be checked before the next request is made.
I'd want to see the actual destination IP at connection time, not just the hostname supplied by the agent. I'd also check whether outbound network rules prevent access to internal address ranges.
There's a second problem here, and it has less to do with SSRF itself.
Even if the agent sends exactly the same request twice, the network path might not be identical. DNS can return a different address, a redirect target can change, or the HTTP client can reuse an existing connection in one run and establish a new one in the next.
Looking at the final model response won't tell us which of these happened.
For this kind of test, I'd keep the raw request, DNS answers, redirect history, destination IP, response status, and target build identifier for each run. Not just the agent's summary. Without that information, a failed second scan doesn't tell us whether the vulnerability disappeared or the request simply took another route.
There's also a difference between replaying a previous execution and reproducing the vulnerability. Replaying saved tool calls can reconstruct what the agent did before. It doesn't prove that the current application is still vulnerable.
That's why I'd avoid treating a second scan that returns nothing as evidence that the issue is gone.
Before closing the finding, I'd want to know one thing:
Did the application stop accepting the request, or did the request stop reaching the same destination?
Reference
Top comments (0)