Just got a reward for a high vulnerability submitted on @yeswehack -- Cleartext Storage of Sensitive Information (CWE-312). https://t.co/wAKPXV10cr #YesWeRHackers
Just got a reward for a vulnerability submitted on @yeswehack -- Use of Unmaintained Third Party Components (CWE-1104). https://t.co/wAKPXV10cr #YesWeRHackers
Woke up this morning thinking "It's Thursday — no XSS reported this week...
... what will I do for PAYLOAD OF THE WEEK?"
Started on a new target last night. Woke up VERY early and found this:
Confirmed DOM XSS → theoretical ATO (still working on that!). Cloudflare WAF bypassed.
The bypass is the interesting part:
onerror=alert(1) → 403
onerror%0c=alert(1) → 200
Note: one character: %0c is a form feed.
Cloudflare matches onerror= literally. The HTML spec treats form feed as whitespace — so onerror\x0c= is a valid event handler that CF never sees.
Once past the WAF, the XSS chain was wide open:
- URLSearchParams → Vuex store → v-html / innerHTML
- No sanitisation at any step.
- CSP was report-only — never enforced, so nothing blocked execution.
- Confirmed in all browsers. No auth required.
- Single link from the browser.
Sanitised explanation in the image - plus time-stamped ALERT from just moments ago. You're watching XSS live!! Report to h1 almost drafted but on hold as I look to escalate to full ATO.
Things worth adding to your methodology:
1. When a WAF blocks your event handler, try whitespace variants before moving on. Form feed, vertical tab, null byte. CF won't always catch them.
2. Vue apps using v-html are worth tracing. It compiles straight to innerHTML. Follow the data into the store.
3. If you see Content-Security-Policy: ... report-only — that's not protection. That's a log file 😄
I have an endpoint where I can inject malicious content into a QR code. Inject and pre-fill messages to numbers which is a toll rate number I can set up. Also I can redirect to a malicious site, make the user call a number etc.
Impactful?! @intigriti Triage says no. LOL