Logistics Company Admin Panel Compromise

A logistics company handling shipping for thousands of businesses, with a support system where customers submit inquiries and staff review them somewhere on the backend. Same Nagli-hosted Bug Bounty Masterclass series as the last couple of these, and this one's actually listed on Wiz's own page with a real number attached, eighteen thousand dollars, which puts it a fair bit above the airline and cookie-switching ones in terms of what the original finding actually paid out.

The brief itself says the mission is to reach the admin panel and grab the flag, so clicked the admin panel link on the page expecting some kind of login wall first.

There wasn't one. Clicking straight through landed inside the admin panel immediately, fully populated, no credentials asked for anywhere, and the flag was already sitting right there on one of the listed issues before I'd actually done anything resembling hacking.

Technically done at that point, except that's not actually the bug this challenge is built around, the admin route itself having zero auth on it is its own separate finding worth remembering, but the real lesson here was clearly meant to be how customer-submitted data gets shown to staff without anyone sanitizing it first. So set the flag aside and went looking for the actual stored XSS properly instead.

The submit-issue form only gave a dropdown for category, no free text there, so typing a payload straight into the form wasn't going to reach that field at all.

Intercepting the request instead let me edit any field directly in the raw JSON body regardless of what the form's own UI restricted, dropdown or not.

Tried a payload through the description field first.

Rendered without any sanitization at all, executing the moment the admin side loaded that issue. Tried the title field next.

Same result there too. Category, the one field the UI wouldn't even let you type into normally, was worth testing specifically because of that.

That one didn't execute, so out of the three fields touched, two were genuinely vulnerable and one wasn't, which is worth remembering on its own, a form restricting what you can type through its UI doesn't mean the backend applies the same restriction once you're editing the request directly. With stored XSS confirmed on two separate fields, cookie exfiltration was the obvious next thing to actually prove rather than just assume, since executing an alert box and actually stealing a session are two different claims entirely.

Pointed a payload at an interactsh listener instead of a plain alert, and the callback came back , confirming the exfil path actually worked end to end rather than just popping harmlessly in a browser tab.

One more thing worth mentioning that wasn't really part of the technical chain at all. Scrolling through the existing issues, the admin panel was absolutely flooded, hundreds of leftover payloads and flags left sitting there by everyone else who'd already run through this same challenge before me, which rather defeats the point of a practice target meant for people to find this themselves. Cleared all of it out and left one clean marked issue behind with a note asking whoever finds it next to do the same once they're done, which is a small thing, but a shared practice range only stays useful for learning if people actually treat it that way instead of leaving the answer sitting in plain sight for the next person.

Genuinely the kind of bug that looks almost too simple once you've found it, an admin panel with no authentication at all sitting right next to a support form that renders whatever gets typed into it, no sanitization, no cookie flags stopping exfiltration either. Eighteen thousand dollars for something that came down to, open dev tools, intercept a request, and type a script tag into a field the UI didn't want to let you touch, is exactly the kind of lesson worth sitting with, the business impact of a bug has very little to do with how technically impressive it looks to find.

Happy hunting, see you in the next scope.