One Payload, a Whole Dealer Network

Old enterprise portals have a particular smell: one template, deployed across dozens of subdomains and parameters, reflecting user input the way everyone did fifteen years ago. This automaker's dealer portal was exactly that, with a WAF bolted on to compensate. (Kept defanged — the proof was a harmless origin check.)

The spark

Several URL parameters were reflected into the page unsafely. The plain payloads all bounced off a WAF, so the interesting question wasn't "is there XSS" — clearly there was — but "what shape of payload does the filter fail to recognise?"

Digging in

The filter matched on the obvious things: script keywords and parentheses. So I built the payload out of what it wasn't watching: reach a function via the [][constructor][constructor] pattern, invoke it with backticks instead of parentheses, and assemble the sensitive substrings by concatenation so no blocked keyword appears intact. The filter had nothing to match.

The part that made it a real finding rather than a curiosity: the same payload worked across many parameters and across the whole family of dealer subdomains, because they all rendered from the same vulnerable template.

One bug in a shared template isn't one bug. It's the same bug, wearing every hostname the template was ever deployed under.

The exploit (defanged)

I proved execution with a harmless origin check rather than anything weaponised. In an authenticated dealer's browser, that same execution reaches their session and the PII the portal handles — which is what makes reflected XSS on a logged-in enterprise app a high-severity issue, not a pop-up.

Impact

Reflected XSS reachable across an entire dealer network, against authenticated users, through a WAF that only looked like a control.

The fix

Fix the reflection in the shared template with proper context-aware output encoding, and demote the WAF to defence-in-depth. A filter you can rewrite your way around was never the thing keeping you safe.