I felt the need to join in with this conversation and say that I was making a widget on a wiki site-wide that uses an iframe and unintentionally didn't escape some of the user input which could have led to easy XSS exploitation... it's fixed now and the safe revision is live but point being Wikia are not 100% perfect with code reviews as at the time the vulnerable code was approved. I don't think Fandom regard me as a suspicious user so they probably leaned towards approving the code rather than checking it properly in the first place.
Yes, that was exactly my point. Even if they had a army of Javascript security expert reviewers, things are bound to get through because it is very hard to verify all possible interactions between several scripts and new exploits come out every so often. My example above was an easier way to get through, by simply adding that variable in an unrelated script, and only later using ImportJS to bring in the script to exploit.
Another good example was a user whose script was failing because they couldn't fix the bugs. The code seemed oddly designed until I realized that this code was deliberately obsfucated (and copied from elsewhere), and staff had "once" again approved it in good faith. Perhaps there was no security risk there, and perhaps there was. Impossible to say without unobsfucating it.
Anyway, this is my last post on that topic as we've gone a quite off-topic (better to discuss this in dev.wiki or another thread) as the issue here is resolved, my point is:
For dev.wiki, there is a need for a better way to let either the script author or an experienced code-editor disable a live script as admins aren't always available. While cache may mean that a user keeps getting an old version, at least there wouldn't be new victims.